Prepare issues for implementation

Turn an unready issue or external pull request into a verified tracker outcome. prepare-issue 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

1. Read repository instructions and tracker documentation before interpreting labels or mutating the tracker.
2. If the repository has no contract, use the contract exposed by work-github-issue when it is installed.
3. Keep category and state separate. With the default vocabulary, use an existing Korean category (유형: 버그 or 유형: 개선) and state label when available. Otherwise store <!-- work-github-issue:state role=<role-key> --> in the issue body and report category in the brief without creating labels. Read bug/enhancement and English state labels as legacy aliases. Never add both aliases for one role; conflicting recognized categories, labels, or markers require maintainer direction. Repository mappings override these names.
4. Resolve the human-facing language from repository instructions, then the user's request, and otherwise use Korean. Under the fallback contract, write titles, briefs, questions, and tracker comments in clear Korean while preserving quoted reporter text, code identifiers, machine markers, and links.
5. Do not acquire an implementation lease while preparing an issue. 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.
6. 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.

Before applying a label, confirm it already exists. Ordinary issue-preparation authority does not create repository-wide labels. A missing optional label does not block preparation: use the state body marker and continue. Label descriptions and colors are catalog documentation, not runtime identity.

Find work needing attention