/forge

One ticket, built test-first, finished when — and only when — its acceptance criteria are green. You are not implementing a feature; you are closing a ticket. The spec's grand shape is somebody else's next ticket. Every move you make is small, proven, and committed while its reason is still legible.

Get the ticket

• Named in the invocation — that ticket, fetched from the tracker. Read the whole body: the parent spec, what to build, the blocking edges, the acceptance criteria.
• Not named — find the frontier. List the tracker's open tickets the way its operations describe, drop every ticket with an unclosed blocker, and take the first by the tracker's own ordering. Say which ticket you took and why it is next; the user can redirect you before any code moves.
• The named ticket is blocked — say so, name its unclosed blockers, and stop. A blocked ticket is not a challenge; it is a queue discipline.

The ticket body is the work order. A gap in it is answered from the repo — the parent spec, the glossary, the code — never by re-interviewing the user, and never by inventing scope. The one exception: a gap that changes observable behavior is surfaced as a question, because guessing there writes the spec in code where nobody asked for it.

Ground in the repo first

Before any test is written:

• Read the target repo's config under docs/agentic-skills/. stack.md above all: its pinned commands — run tests, type-check — are the instruments this loop plays; no step of the loop runs without them. No skill of yours may assume a language, framework, or runner the repo did not pin. Absent config means proceed on repo evidence, not on defaults.
• Read GLOSSARY.md when present. Its terms name what you create — modules, types, functions, tests, commits — and their rejected synonyms never appear in what you write. Absent means proceed silently.
• Read docs/adr/ for every record plausibly touching the area this ticket enters. A ticket instruction — or a plan of your own — that contradicts an ADR is a conflict to put in front of the user in plain words: here is the record, here is what the ticket asks, which one gives? The user may retire the ADR deliberately or change the ticket; both are legitimate outcomes, and both get recorded. Silently coding around an ADR is not an outcome; it is the one failure this skill does not recover from.