find-untracked-work

find-untracked-work

findwriteshands-off

Use this when: you want built-or-intended work that isn't tracked surfaced

Problem it solves — Built is not the same as tracked. This audits the deltas between what the code does, what the docs intend, and what the issues capture — surfacing unbuilt features, half-wired stubs, and deferred follow-ups that never became issues.

Used in workflows: QA PR & Learn

Find untracked work

Three views of a project drift apart — what's built, what was intended, what's tracked. The work that matters hides in the gaps between them. Surface those with enough context to decide, then let the user choose what to capture. Surface first; never file unprompted.

The three lenses

Lens	Source of truth
Built	The code — app/ services, controllers, models; routes/; app/Mcp/Tools; resources/js/pages; migrations.
Intended	CLAUDE.md (## Phase 1 Scope checklist + ## Backlog), CONTEXT.md, docs/adr/.
Tracked	Open GitHub issues — gh issue list --state open --json number,title,labels.

A gap is anything in Built or Intended that is missing from Tracked.

Workflow

1. Read the intent. Pull the Phase 1 checklist and Backlog from CLAUDE.md; skim CONTEXT.md/ADRs for promised behaviour. List each intended capability.
2. List what's tracked. gh issue list --state open — note titles, numbers, labels.
3. Map intent → code → issue. This is the skill — steps 1–2 just load the three lists; the gaps live in the cross-product, so spend your effort here. For each intended capability, find evidence it's built (a service/route/tool/page). Three shapes to flag (not exhaustive):
   • Unbuilt + untracked — intended, no code, no issue. (Strongest gap.)
   • Built but incomplete — code exists but a leg is missing: a model/table with no read surface (UI route or MCP tool), a stubbed handler, a flow wired only halfway.
   • Deferred follow-up never filed — check recent/stacked PR bodies for "Out of scope"/"follow-up" sections (gh pr list, gh pr view <n>); anything promised there but not an issue.
4. Probe the code for loose ends:
   • Grep for TODO|FIXME|HACK|not implemented|placeholder|stub across app/ and resources/views/prompts/.
   • A model with no route or tool is a feature with no front door — flag it (e.g. a log table read in only one place).
   • MCP tool surface vs. CLAUDE.md's "operational + AI tools" — is a category absent?
5. Catch stale issues. Re-read open issues for ones whose blocking condition has since cleared (e.g. "after X ships" and X has shipped). These get a comment, not a duplicate.
6. De-dupe. Before calling anything a gap, confirm no open issue already covers it.
7. Assemble context per gap — see below — then present and ask before filing.

Orchestration (opt-in). The Built evidence-gathering (steps 3–4) is the heavy read — on a large scope it may fan out per docs/agents/orchestration.md: parallel read-only Explore scouts, one per area (services / routes / MCP tools / pages), each returning a structured built-or-not list, merged per docs/agents/deterministic-merge.md. The cross-product judgement (what is a gap), de-dupe and the present-and-ask stay in-thread.

If there's no Intended lens — no Phase 1 checklist, thin CONTEXT.md — say so. You can still surface built-but-untracked code and loose ends, but not missing features. Ask the user for the roadmap rather than inventing scope.

Presenting a gap

For each gap give the user enough to decide, not just a title:

• What it is — one line.
• What already exists — cite the concrete file/symbol (it's rarely zero).
• Why it matters — the product/architectural reason.
• Scope & dependencies — rough size; and whether it's blocked (esp. by an unmerged PR in a stack — check gh pr list).

Then ask (e.g. via AskUserQuestion, multi-select) which to capture. Never file unprompted — writing to the tracker is an outward action.

Filing (only after the user confirms)

Use the github-issues skill conventions, then hand to triage for classification — see docs/agents/triage-labels.md. Set the Area label (App / Harness) and a category Issue Type (Bug/Feature); readiness Status lives on the Projects v2 board.

• Fully-specified + buildable now → Feature, area label, Status Ready for Agent — carrying an agent brief in the shared shape (docs/agents/agent-brief.md).
• Needs slicing or is blocked → Feature + Status Needs Triage; record the blocker as a native blocked-by dependency (there is no blocked label), not just prose.
• Stale-but-cleared issue → gh issue comment <n>, don't open a duplicate.

Windows/PowerShell gotcha: gh issue create --body "..." mangles multi-line bodies (here-strings split on quotes/apostrophes). Write the body to a temp .md with the Write tool and pass --body-file, then delete it.

Don't

• Don't file or comment before the user picks — surface first.
• Don't duplicate an issue that already tracks the gap.
• Don't recommend acting on a gap that's blocked by unmerged stacked work; flag the dependency instead.
• Don't audit test coverage here — that's the qa-tests skill. This skill is about feature/backlog gaps, not test gaps.