implement

Files (3)

• SKILL.md
• feature.md · references/
• refactoring.md · references/

SKILL.md (first lines)

# implement

Build the work described by a bd ticket, a spec, or the user's request. You own the
design and the verification; delegate bulk edits when the work is long-running
([guard-the-context-window](../guard-the-context-window/SKILL.md)).

## 1. Resolve the work

- A bd id: `bd show <id>`. Fuzzy words ("the auth ticket"): resolve via `bd list` +
  title match; more than one plausible match, name them and ask.
- Mark it in progress (`bd update <id> --status in_progress`). Read the acceptance
  criteria — they are the completion contract.
- No ticket (small direct request): proceed; suggest
  [to-spec-bd](../to-spec-bd/SKILL.md) only when the request is genuinely big.

## 2. Load the playbook

Match the task shape and read the matching playbook, then copy its steps into your todo
list verbatim. A step you choose not to do stays in the list with a one-line
`skip: <reason>`; skipping silently is not allowed.

- New behavior → [references/feature.md](references/feature.md)
- Structure changes, behavior stays → [references/refactoring.md](references/refactoring.md)
- Something is broken → hand off to the [diagnose](../diagnose/SKILL.md) skill instead.

## 3. Build

- Walk the [lazy-ladder](../lazy-ladder/SKILL.md) before writing anything.
- Test-first at the pre-agreed seams via [tdd](../tdd/SKILL.md); the spec's Testing
  Decisions name the seams. No spec: agree the seams before the first test.
- Typecheck regularly, run single test files regularly, the full suite once at the end.
- Comments and docs are welcome where they carry constraints the code can't; never
  strip existing ones.
- Integrate new requirements as if they had been foundational from day one, not bolted
  on; propagate through types, docs, and examples.
- Stateful operations answer "what happens if this runs twice? crashed halfway?" —
  add the reconciliation step when the answer is "depends what was left behind".

## 4. Verify and deliver

- Prove it on the real artifact ([prove-it-works](../prove-it-works/SKILL.md)); if the
  repo has a generated verify skill, run it. Every acceptance criterion checked, each
  against the real path, outcomes noted — not command names.
- Commits are small, ordered, and tell the story
  ([sequence-verifiable-units](../sequence-verifiable-units/SKILL.md)).
- PR descriptions use these sections, dropping empty ones: **Why** (intent, why this
  approach), **Scope** (facts from the diff, real symbols and paths), **Tradeoffs**
  (real choices only), **Blast Radius** (who and what it touches, why it's safe or
  risky), **Verification** (how each check ran and its outcome). Attach a screenshot or
  recording when it proves a claim.
- Close the ticket with the evidence note: `bd close <id>` after updating it with what
  shipped and how it was verified. Pausing instead: leave a resume note on the issue
  (progress, verified-so-far, next action) and a `wip:` commit — never stop mid-edit in
  a broken state.

From baranbingol1/bbstack, MIT.

More from baranbingol1/bbstack