/build-it

name: build-it
description: '[Adam''s Skills] Build a piece of work, from wherever it is written down — a ticket number or URL, a plan or spec file, the plan agreed in the conversation above, or a description typed straight after the command. Reads whatever source it is given plus the code it names, then asks whatever the source and the code left unanswered — the why above all — before pinning in writing exactly which files will change and which will not. That scope note goes to disk, so it survives compaction and gives a later review something concrete to check against. Then it builds to that scope and stops, handing off rather than chaining. Where the ask turns out to be large and still foggy it says so and points at a planning pass first, rather than building into the fog. No issue tracker is required. Trigger ONLY on a direct instruction to build one specific, already-decided piece of work: "/build-it 412", "build it", "build this", "build that ticket", "build what we just planned", "implement this ticket", "go ahead and build it". Do NOT trigger on talk ABOUT building: planning, estimating, weighing options, or asking how something would be built ("what would it take to build X", "we should build X at some point", "how would you build this"), nor on any sentence where the word is incidental ("the build is failing", "build a list of the files"). If it is not an instruction to start work right now on something already settled, do not trigger; the user can always type /build-it.'
allowed-tools: Read, Write, Edit, Bash, Glob, Grep, AskUserQuestion

Build It

However the work reached you, it arrived compressed. A ticket records *what* somebody decided and almost never *why*; a plan written an hour ago leans on a conversation that is about to be compacted; a one-line request carries the whole reason in the requester's head and none of it on the page. Building straight from any of those means building from the compression artefact.

This skill decompresses before it writes any code: read whatever the work is written down in, read the code it names, ask whatever those two left unanswered, and write down what is in scope and what is not. Then build that, and only that.

The two failure modes it exists for are **building the wrong thing confidently** and **scope creep**. The first is answered by the interview, the second by the scope note.

**No issue tracker is required.** A ticket is the tidiest input, not the only one.

/build-it 412                        # a ticket number
/build-it #412 · /build-it <url>     # the same, or an issue URL
/build-it docs/plan-auth.md          # a plan or spec file
/build-it add rate limiting to the export endpoint   # a description, typed straight in
/build-it                            # takes the plan agreed in the conversation above
/build-it 412 --scope-only           # stop after the scope note; write no code
/build-it 412 --commit               # commit at logical points (default: no commits)

1. Work out what you are building

Four sources, in this order. Use the first that yields something concrete, and say which one you took so the user can correct you before any time is spent.

1. **A ticket reference** — a number, `#number`, or a URL. Needs a tracker: find it the way `/raise-issue` does, stopping at the first hit — `docs/agents/issue-tracker.md`, then `git remote -v` plus the matching CLI, then repo evidence (`.github/ISSUE_TEMPLATE/`, `CONTRIBUTING.md`, tracker URLs in docs, configured MCP servers). Check the CLI is authenticated **now**, before the interview — discovering `gh` is logged out after ten minutes of questions is the avoidable failure. Then read the **whole** thing: body, every comment, linked and blocking issues, any attached spec. Comments are where the why usually hides, and where a decision has most often been reversed without the body being updated. If the body and a later comment disagree, the comment wins and you say so. 2. **A file path** — a plan, spec, ADR, or design note. Read it in full, and read what it links to. 3. **A description typed after the command** — treat the user's words as the brief. There is no written record behind it, so the interview in step 3 carries the whole load. 4. **The conversation above** — with no argument, derive the work from what this session has already agreed, plus any plan, spec or notes written during it. State the derived goal back in one sentence and get a yes before going further. Do not guess a goal into existence to keep moving: if the conversation does not add up to something concrete, say what is missing and ask.

**Then check the size of what you just picked up.** This gate exists because sources 3 and 4 have no author who already did the thinking, so a two-line request can be hiding a fortnight of work. If the ask is large *and* still foggy — the destination is not clear, or the route to it is not, or it plainly spans many sessions — do not start building. Say so plainly, in a line or two, and point at the right first step:

• **Big, and the decisions are not made yet** → `/wayfinder` if installed: it charts the work as

decision tickets on the tracker and resolves them one at a time. Come back here with a ticket number afterwards.

• **Not huge, but under-specified or built on shaky reasoning** → `/grilling` if installed, for a

proper adversarial pass over the idea before any code.

• **Neither installed** → run a longer version of step 3 yourself and say that is what you are

doing.

This is a recommendation, not a refusal. If the user says build it anyway, build it — record the fog in the scope note's *Assumptions* and carry on. A clear ask of any size goes straight through; size alone is never the trigger, only size together with fog.

If a named ticket cannot be reached, say exactly why and what would fix it, and offer to proceed from a description instead. Never invent the contents of a ticket you could not open.

#