implement

Files (3)

• SKILL.md
• implement-phases.md · references/
• implementation-summary.md · references/templates/

SKILL.md (first lines)

# Implement

Execute complete feature implementations using a structured, phased approach with verification gates and atomic commits.

## HARD CONSTRAINTS (NON-NEGOTIABLE)

- **SCOPE IS LOCKED** — Only implement what is in the plan from `/analyze`. Nothing more.
- **NO SCOPE CREEP** — Do not implement work from other tickets, even if it seems related or helpful.
- **TICKET TRACKING IS MANDATORY** — Update ticket status (in-progress/done) as you work.
- **EPIC CLOSURE RULES** — Never close an epic while child tickets remain open.
- **COMMIT BEFORE CLOSE** — A ticket status can only be changed to 'done' AFTER the code changes for that ticket have been successfully committed.
- **VERIFY BEFORE COMMIT** — No code shall be committed until all verification steps (tests, lint, build, etc.) have passed successfully. If any check fails, you MUST resolve the issues and re-verify before attempting to commit.
- **NO --NO-VERIFY** — Never, under any circumstances, use the `--no-verify` flag with git commit. Pre-commit hooks must always run and pass. If they fail, fix the code. No exceptions, even if explicitly requested.
- **NO BRANCH CREATION** — Never create branches. The agent will already be on the appropriate branch when `/implement` is invoked. Do not run `git checkout -b`, `git branch`, or `git switch -c`. Work on the current branch.

### Scope Creep Self-Check

Before writing ANY code, ask:
1. Is this in the implementation plan? → NO = don't implement
2. Is this ticket in scope for this phase? → NO = don't implement
3. Am I adding something "nice to have"? → YES = note as follow-up, don't implement

If you discover related work, add it to "Discovered Follow-Up Items" and continue with scoped work.

## When to Use

- Building new features end-to-end
- Complex multi-component implementations
- Features requiring coordination across backend, frontend, and infrastructure
- Any implementation benefiting from structured phases and checkpoints

## Ticket Status Management (Beads Projects)

```bash
# Starting work on a ticket
bd update <ticket-id> --status in-progress

# Completing a ticket
bd update <ticket-id> --status done

# Verify epic children before closing
bd show <epic-id> --json  # All children must be status:done
```

### Status Update Rules

| Event | Action |
| ----- | ------ |
| Starting implementation | Mark parent ticket in-progress |
| Starting a child ticket in a phase | Mark child in-progress |
| Completing a child ticket | Mark child done |
| ALL children done → close epic | Mark epic done |

**NEVER close an epic while children are still open.**

## Phase Execution Loop

Every phase follows this exact sequence:

```
┌─────────────────────────────────────────────────────────────┐
│  PHASE EXECUTION LOOP                                       │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│   1. PLAN     → Define work for this phase                  │
│                 Mark phase tickets as in_progress           │
│                                                             │
│   2. WORK     → Execute the phase work                      │
│                 ⚠️  ONLY work in the plan — no extras        │
│                                                             │
│   3. VERIFY   → Run verification checklist                  │
│                 Tests pass, lints clean, build succeeds     │
│                                                             │
│   4. COMMIT   → Create atomic commit for phase              │
│                 Include ticket IDs in commit message        │
│                                                             │
│   5. UPDATE   → Mark completed tickets as done              │
│                 bd update <ticket-id> --status done         │
│                                                             │
│   6. PROCEED  → Only after commit + ticket updates          │
│                 Move to next phase                          │
│                                                             │
│   ⚠️  DO NOT PROCEED UNTIL COMMIT SUCCEEDS AND TICKETS      │
│       ARE UPDATED                                           │
│                                                             │
│   ⚠️  NEVER mark a ticket done until its changes are        │
│       committed.                                            │
│                                                             │
└─────────────────────────────────────────────────────────────┘
```

## Phase Overview

| Phase | Name | Description |
|-------|------|-------------|
| 1 | Requirements Analysis | Gather context, clarify requirements, set up tracking |
| 2 | Architecture Decision | Evaluate approaches, document decisions (if needed) |
| 3 | Parallel Implementation | Execute implementation across work streams |
| 4 | Integration | Integrate components, resolve conflicts |
| 5 | Verification | Run full verification checklist |
| 6 | Documentation & Cleanup | Update docs, clean up tracking, summarize |

See `references/implement-phases.md` for detailed phase instructions.

## Task Tracking Setup

Define ALL phases upfront before starting implementation:

```
Phase 1: Requirements Analysis
  - [ ] Gather context
  - [ ] Clarify requirements
  - [ ] Commit planning artifacts

Phase 2: Architecture Decision (if needed)
  - [ ] Evaluate approaches
  - [ ] Document decision
  - [ ] Commit architecture docs

From thoreinstein/agents, MIT.

More from thoreinstein/agents