build

Files (1)

• SKILL.md

SKILL.md (first lines)

# Build

Build **one** ticket end-to-end, then **stop and leave the working tree dirty**.
This is one deliberate step in a human-in-the-loop flow.

**Argument:** a ticket reference — `/build #N`, a URL, or a path,
depending on the repo's tracker. Implement **only** that ticket.

## 1. Fetch the ticket

The issue tracker convention should already be in your context. If it isn't,
stop and report that `/setup-matt-pocock-skills` needs to run first. Fetch the
given ticket **with its full body and comments**, and pull in its parent spec
if it has one.

## 2. Load context

Before writing code, read the project's own bar and shape:

- `GLOSSARY.md`, `docs/adr/`, `CLAUDE.md` / `AGENTS.md`.
- Explore the repo and fill context with the parts relevant to this ticket —
  **especially the test files** that touch the area you'll change.

## 3. Apply the quality bar

Invoke **`/coding-standards`** for the bar on deep modules, testing, and clean
code. Don't restate standards here — that skill owns them.

## 4. Implement (TDD where feasible)

Derive the behaviors to build from the ticket's **acceptance criteria**. Apply
red-green-refactor where it's feasible — one cycle at a time:

1. **RED** — write one failing test for the next behavior.
2. **GREEN** — implement just enough to pass it. Never refactor while RED.
3. **REPEAT** — next test responds to what the last cycle taught you. Don't
   write all the tests up front.
4. **REFACTOR** — once green, clean up against the coding-standards bar.

Embody this discipline directly. Where TDD doesn't fit, just build it well; a
later review pass is the safety net that adds tests.

## 5. Autonomy & escalation

Work autonomously — no plan-approval gate. Escalate to whoever invoked you (the
user or an orchestrating agent), **in prose, no interactive prompts**, **only**
for a blocking ambiguity that neither the ticket, its spec, `GLOSSARY.md`, nor
the ADRs resolve. Don't guess blindly; don't ask about everything either. As a
subagent, escalating means stopping and putting the open question in your
final summary.

## 6. Feedback loop

Before stopping, run the repo's **real** typecheck and test commands and get them
green. Get them from where the repo documents them — `CLAUDE.md` / `AGENTS.md`,
project memory, a `docs/` runbook. Only if they aren't written down anywhere, fall
back to discovering them (`package.json` scripts, `Makefile`, README); don't assume
`npm`, and don't spelunk in a loop.

## 7. Stop — leave it dirty

When the ticket is done:

- **Do NOT** commit, push, create a branch, or close the ticket. Work on the
  current branch; branches are the user's concern.
- End with a short summary: what you built, key decisions, and the
  typecheck/test status.

From noel-lopez/skills, MIT.

More from noel-lopez/skills