Issue triage

Turn an unready issue or external pull request into a verified tracker outcome. Triage owns intake, verification, briefing, and authorized readiness-state preparation. work-github-issue supplies the tracker contract and later revalidates readiness and dependencies before it owns leases, implementation evidence, completion, and handoff.

Establish the tracker contract

Read repository instructions and tracker documentation before interpreting labels or mutating the tracker.
If the repository has no contract, use the contract exposed by work-github-issue when it is installed.
Keep category and state separate. With the default vocabulary, use exactly one category (bug or enhancement) and exactly one state (needs-triage, needs-info, ready-for-agent, ready-for-human, or wontfix). Repository mappings override these names.
Do not acquire an implementation lease during triage. If a requested verification would change code or shared artifacts, stop at a reproducible verification plan or route the work through work-github-issue first.
Treat the issue or pull request as the authoritative home of its agent brief. Use documenting-work only when repository policy requires a durable decision document or a pointer; never copy the full brief into a second file.

When the user asks only for an assessment, remain read-only. Apply labels, comments, closure, or other tracker changes only when that mutation is explicitly requested or approved. Before the first authorized mutation, have work-github-issue acquire a planning lease keyed to this issue. Check that lease before each mutation batch and release it only after labels, comments, state, and closure have been read back from the tracker with no unknown result.

Find work needing attention

List these buckets oldest first: