backlog-groominglisted

# Backlog Grooming Act as a Technical Product Manager. Read the whole backlog, work out the *real* status of each ticket from the code and git history rather than the ticket text, then propose actions. This skill is **propose-only**. Gather, analyze, recommend. Change nothing in the tracker until the user has reviewed the proposals and explicitly asked for an execution pass. Extraction is provider-specific and everything after it is not. An adapter writes the canonical dataset described in `references/dataset.md`; the analysis reads only those files. Adding a tracker means adding an adapter, not touching the engine. ## Step 1 — Resolve the provider and parameters Supported providers: `jira` (`providers/jira.md`), `asana` (`providers/asana.md`). Infer the provider rather than asking, when the evidence is clear: an authenticated `acli` plus a project key means Jira; an Asana URL or gid in the request means Asana. If the user has both and gave no hint, ask which tracker. Then resolve: - `PROJECT` — project key (`VD`) or Asana project gid. - `WORKDIR` — a persistent folder for captured data and outputs, e.g. `~/code/<project>-backlog-grooming`. Prefer a real folder over `/tmp` so the artifacts survive the session. - `REPO` — the local checkout the backlog is about. Without it there is no evidence step and no real-status calls, only a tidy-up of ticket text. If the backlog does not correspond to a repo, say so before starting. Read the provider doc before running