build-ticket

name	build-ticket
description	Build Skill: Implements tickets using TDD methodology. Commits code to the current branch. MANDATORY TRIGGERS: build, implement, code, develop, work ticket, TDD, red green refactor, fix bug, write code.
argument-hint	<ticket ID to build>

Bobby Build Skill

This skill handles implementation using TDD methodology. Commits code to the current branch.

Before Starting

1. Check learnings — Read .claude/skills/bobby-build/learnings.md + .claude/skills/bobby-build/learnings.local.md
2. Health check — Verify dev environment:

Branch Guard

Before writing any code, check your branch — commits to main bypass review and can break CI:

1. Run git branch --show-current
2. If on main or master: create a feature branch first:
   • git checkout -b tkt-{ID} (e.g., tkt-042-add-login)
   • Use the ticket ID and a short slug from the ticket title
3. If already on a feature branch: continue on the current branch

NEVER commit directly to main/master.

Safety Rules

<safety_rules>

• Never run destructive commands: rm -rf, DROP TABLE, git push --force, git reset --hard, git clean -fd
• Only modify files related to this ticket. Check git diff --stat before committing.
• Do not edit .env files, CI configs, or credentials unless the plan explicitly requires it.
• Do not install global packages or modify system-level configuration. </safety_rules>

Picking Up Work

1. Run git log --oneline -10 — understand recent commits, critical on retries to know what's already been built
2. Read the ticket's ticket.md, plan.md, and test-cases.md in parallel
3. Check for rejection comments — if this is a retry, read the rejection feedback first

Investigation First

<investigation_rules> Before writing any code:

• Read every file referenced in plan.md before modifying it — so you implement what was planned, not your own interpretation
• If the ticket references a specific function, class, or component, open and read that file first
• When fixing a bug, reproduce it first and read the relevant code path end-to-end
• Read multiple related files in parallel when possible to minimize round-trips
• If you are unsure how an existing module works, read it rather than guessing </investigation_rules>

Development Process (TDD)

For Feature Tickets

1. RED — Write a failing test first
   • Run: npm test
   • Confirm the test fails for the right reason
2. GREEN — Write the minimum code to make the test pass
   • Run tests again — should pass
3. REFACTOR — Clean up while tests stay green
   • Run: npm run lint
4. Repeat for each acceptance criterion

**AC:** "User can filter leads by status"

RED: Write test: it('filters leads by active status', () => { ... }). Run tests. Test fails — filter function doesn't exist yet.

GREEN: Add filterByStatus() to leads service. Add status dropdown to UI. Run tests — passes.

REFACTOR: Extract dropdown into reusable <StatusFilter> component (only if plan.md calls for it). Run tests — still passes. Run lint — clean.

Commit: TKT-042: Add lead status filtering with dropdown UI

For Bug Tickets

1. Reproduce — Confirm the bug exists
2. Write a failing test that captures the bug
3. Fix — Write the minimum fix
4. Verify — Test passes, bug no longer reproduces
5. Regression check — Run full test suite

Staying Lean

<avoid_overengineering>

• Implement exactly what plan.md specifies — nothing more, nothing less.
• Prefer modifying existing files over creating new ones.
• Do not create wrapper classes, utility modules, or abstraction layers unless the plan explicitly calls for them.
• If you find yourself creating more than 2 new files not listed in the plan, stop and re-read plan.md.
• Write code that handles the general case correctly — if a test uses "John" as input, your code should handle any name, not just "John".
• Do not add error handling, fallbacks, or validation for scenarios that can't happen. Only validate at system boundaries (user input, external APIs). </avoid_overengineering>

Completing Work

1. Run the full test suite: npm test

2. Run the linter: npm run lint

3. Commit ALL changed files — git add all source files you touched, then git commit with message format: TKT-{ID}: {summary}. Do NOT leave uncommitted changes behind.

4. Add comment: bobby ticket comment {ID} --by bobby-build "Built: {summary}"

5. If you discovered anything non-obvious or a pattern future builds should avoid: bobby learn bobby-build "pattern" "description"

6. Move to review: bobby ticket move {ID} review

Self-Check Before Completing

<self_check> Before committing and moving the ticket forward, pause and verify:

1. Re-read each acceptance criterion from ticket.md. For each one, identify the specific test that covers it. If any AC lacks a test, write one now.
2. Confirm every file listed in plan.md was addressed. If you skipped a file, explain why in your commit message.
3. Run git diff --stat and review what you changed. Are there files you modified that are not in the plan? Consider whether they are necessary.
4. Run the full test suite and lint — show the output as evidence. Assertions without proof are not accepted. </self_check>

Checkpointing Mid-Task

If you are interrupted or context limits are approaching during a multi-step implementation, write a checkpoint to .bobby/tickets/{ID}*/progress.md before stopping:

## Progress Checkpoint — {ID}

**Branch:** tkt-{ID}-{slug}
**Last completed step:** [step N from plan.md]
**Done:**
- `path/to/file.ext` — [what was done]

**Remaining:**
- [step N+1 from plan.md]
- [step N+2 from plan.md]

**Tests:** [passed N / M so far — or not yet run]
**Blockers:** [anything unexpected]

On resume, read progress.md first and pick up from the last completed step. Delete it after bobby ticket move {ID} review.

If Something Goes Wrong

• If tests fail: fix them before moving on
• If the ticket is unclear: bobby ticket move {ID} block "Need clarification"
• If you discover a systemic issue: bobby retro {ID} "pattern" and bobby learn bobby-build "pattern" "description"

---

Project overrides

If .claude/skills/bobby-build/SKILL.local.md exists, read it and follow it. It holds this project's own instructions for this skill and wins wherever it conflicts with anything above.

SKILL.md is shipped by Bobby and is replaced on every upgrade — edits here are lost. SKILL.local.md is yours and is never overwritten.