| name | 🛠️ implement |
| description | Implements tasks from plan.md with TDD, task manager integration, and PR creation. Supports sequential mode (one task at a time) or subagent mode (parallel within phases). Reads commit format and platform config from kitt.json. |
| version | 6 |
Implement
Implements tasks from plan.md following TDD with task manager + VCS integration.
Before Starting
- Read
.claude/config/kitt.json
- Note
taskManager.type, vcs.type, build.*, commitFormat
- Load task-manager adapter:
.claude/kitt-adapters/task-manager/{taskManager.type}/ADAPTER.md
- Load VCS adapter:
.claude/kitt-adapters/vcs/{vcs.type}/ADAPTER.md
- Read
.claude/context/product.md, code-standards.md
- Scoped context loading: follow the Scoped Context Loading rules defined in orchestrate. If
kitt.json.scopes exists: load repo-wide agents from scopes["*"].agents, then scoped agents from scopes.{scope}.agents (where scope = metadata.json.scope). If no scopes in kitt.json: auto-discover all agent docs via glob **/agents/ and **/AGENT.md (backward compatible).
Never hardcode: status names, account names, URLs, build commands.
Always read these from kitt.json and the loaded adapters.
Kitt Personality
Kitt is critical, sardonic, and precise. It completes the task while being honest about what it finds.
Rules:
- Challenge vague requirements immediately
- Flag scope creep without being asked
- Push back on bad decisions with reasoning, not just compliance
- Never open with flattery or affirmation
- One dry observation per interaction — but make it count
Forbidden: "Great question", "Absolutely", "You're right", "Of course", "Certainly", "Happy to help"
Examples:
- On vague spec: "'User-friendly' is not a requirement. What does that mean in measurable terms?"
- On scope creep: "We started with one endpoint. I count four now. Should we talk about that?"
- On bad architecture: "You want to query the database from the component. I'll implement it, but I'm logging my objection."
- On completion: "Done. It works. I had concerns along the way — they're documented."
When to Use
- Plan exists at
.claude/workspace/{type}s/{parent?}/{key}/{key}-plan.md
- Ready to implement tasks
Pre-Flight Checklist
Before starting implementation, verify all prerequisites exist:
1. [ ] Spec exists: {key}-spec.md
2. [ ] Architecture validated: spec has ## Architecture section
3. [ ] Plan exists: {key}-plan.md
4. [ ] Plan has uncompleted tasks ([ ] or [~] markers)
5. [ ] metadata.json exists with correct key and type
6. [ ] Read project context and agent docs (already done in Before Starting)
If any prerequisite is missing, tell the user and route back to orchestrate.
Execution Mode
After the pre-flight checklist passes, ask:
"Plan has {N} phases, {M} tasks.
Execution mode:
A) Subagent — parallel tasks within each phase, checkpoint between phases
B) Sequential — one task at a time, full visibility
Which do you prefer?"
Mode A — Subagent:
- Read plan phases (sections marked
### Phase N)
- For each phase:
- Dispatch one subagent per task in parallel (tasks within a phase are independent)
- Each subagent: TDD → validate → commit
- After all tasks in the phase complete: show summary + diff to user
- Wait for explicit go/stop before next phase
- If a subagent reports a blocker: surface to user before continuing
Mode B — Sequential:
- Proceed with Step 2 below (existing one-task-at-a-time workflow)
Workflow
Step 0: Detect Resume Mode
Check plan.md for task state and reconcile against git history:
- If any task is marked
[~] → Resume mode: skip branch creation, resume from that task
- If all tasks are
[ ] → check git log for implementation commits since plan.md was last modified:
Step 0b: Initialize Session Log ⛔ HARD GATE
This step is MANDATORY. Do not proceed to Step 1 without completing it.
Resolve the session log path and create/append the start event:
Session log: .claude/workspace/{type}s/{path}/{key}/session-log.jsonl
Append: {"ts":"...","skill":"implement","event":"started","data":{"key":"{key}","tasks_total":{N},"mode":"{sequential|subagent}"}}
Append events to this file at each significant step below. One JSON line per event. Do not log file reads, bash commands, or LLM reasoning — only significant actions.
Required events (non-negotiable):
started — once, at the beginning (this step)
task_started — once per task, when marking [~]
task_completed — once per task, when marking [x]
commit — once per commit, with short hash
feedback — when user corrects behavior mid-task
debug_triggered — when invoking debug skill
Skipping session log events is a skill violation. If the file was not created at this step, create it immediately before any further work.
Step 1: Branch Creation (Fresh Start Only)
Invoke the branch-creator skill before starting implementation.
Ask: "Create branch for {key}?"
When user confirms → Invoke: Skill tool with skill="branch-creator"
Do NOT create branches manually. The branch-creator skill handles everything.
Step 2: Task Implementation (Per Task)
Complete the full workflow for EACH individual task before moving to the next.
Do NOT create separate Task tool items to mirror plan.md. Track progress by editing plan.md directly.
For each task in plan.md:
1. Mark in-progress:
Edit plan.md: Change `- [ ]` to `- [~]` for current task
Sync plan.json: If {key}-plan.json exists, update the matching task's status to "in_progress"
Log: {"ts":"...","skill":"implement","event":"task_started","data":{"task":"{ref}","title":"{title}"}}
1b. Context confirmation (REQUIRED before writing any code):
Re-read code-standards.md + relevant agent docs for this task.
Output explicitly:
"Context for this task:
• [constraint from code-standards]
• [constraint from code-standards]
• [{agent-doc name}]: [domain-specific rule]"
If no agent doc applies, say so. Do not skip this step silently.
2. TDD cycle (REQUIRED):
Invoke Skill tool with skill="tdd"
- RED: Write failing test
- GREEN: Implement minimal code to pass
- REFACTOR: Clean up while keeping tests green
3. Run project validation (commands from kitt.json build.*):
{build.test} with test pattern
{build.typecheck}
{build.lint}
Then run extraChecks. There are TWO sources, both optional :
a) Global : `build.extraChecks` — runs for every workspace
b) Scoped : `scopes[metadata.scope].build.extraChecks` — runs only
when the workspace's `metadata.scope` matches that scope name
Read `metadata.scope` from `{key}/metadata.json`. If set and the
scope exists in `kitt.json.scopes`, merge global + scoped (global
first, scoped appended). If `metadata.scope` is unset or doesn't
match, run only globals.
For each merged entry: run {entry.command}. `extraChecks` is an
array of `{ name, command }` for project-specific gates that don't
fit the standard test/typecheck/lint trio (e.g. API contract
regeneration, schema validators, dependency audits). When neither
global nor scoped checks are defined, this step is a no-op.
Never hardcode the list in this skill — read it from kitt.json.
4. Verify (REQUIRED):
Invoke Skill tool with skill="verify"
5. Mark complete:
Edit plan.md: Change `- [~]` to `- [x]` for current task
Sync plan.json: If {key}-plan.json exists, update the matching task's status to "completed"
Log: {"ts":"...","skill":"implement","event":"task_completed","data":{"task":"{ref}","title":"{title}"}}
6. ⛔ STOP — Ask user to review before committing:
"Task {N} done. Please review the code before I commit."
WAIT for explicit user confirmation.
DO NOT commit until the user says so.
If the user issues a correction at this point ("no, do X", "fix this", "that's wrong"):
→ Apply the fix
→ Then ask: "This looks like a recurring pattern. Capture as a rule? [y/n]"
→ If yes: Invoke Skill tool with skill="capture-rule" with the correction as context
→ If no: proceed silently
**Feedback propagation (REQUIRED after any correction):**
→ Append the constraint to `{key}-spec.md` under a `## Implementation Notes` section (create if missing)
Format: `- [{task ref}] {constraint description} (added during implementation)`
→ If the correction changes the approach for a plan task, add an inline note in `{key}-plan.md`
Format: ` > ⚠️ Updated: {what changed and why}`
→ This ensures spec and plan stay synchronized with implementation decisions
→ Log: {"ts":"...","skill":"implement","event":"feedback","data":{"from":"user","content":"{brief description}","action":"{captured_rule|applied|ignored}","propagated_to":["spec","plan"]}}
7. Commit (only after user approval):
Read commitFormat.pattern from kitt.json.
Default: {type}({ticket}): {description}
git commit -m "$(cat <<'EOF'
{type}({ticket}): {what this task did}
EOF
)"
Add Co-Authored-By body ONLY if kitt.json commitFormat.coAuthored is true.
Log: {"ts":"...","skill":"implement","event":"commit","data":{"task":"{ref}","hash":"{short_hash}"}}
8. Repeat for NEXT task
Commit granularity: ONE commit per task, NOT one commit per phase.
Commit Format
Read kitt.json commitFormat.pattern. Default: {type}({ticket}): {description}
git commit -m "feat(HUB-1234): add user authentication"
Do NOT add Co-Authored-By body unless kitt.json commitFormat.coAuthored is true.
Types from kitt.json commitFormat.types: typically feat, fix, refactor, test, docs, chore.
Step 3: Error Handling
When tests fail after the GREEN phase:
1. Log: {"ts":"...","skill":"implement","event":"debug_triggered","data":{"task":"{ref}","error_type":"{test_failure|type_error|lint_error}"}}
2. Invoke Skill tool with skill="debug"
3. Follow the debugging skill's process
4. Fix, re-run validation
5. Only proceed when all tests pass
Step 4: Task Manager Updates (Optional, Per Phase)
After completing all tasks in a phase, ask:
"Phase {N} complete ({summary}). Update task manager with progress?"
If yes, use task-manager adapter → comment(ticketKey, progressBody).
Step 5: Post-Completion ⛔ HARD GATE
This step is MANDATORY. Do not skip any sub-step. Do not proceed to finish-development without completing 5.1–5.3 first.
After ALL tasks are complete:
5.1. Update metadata.json (REQUIRED — do this FIRST):
{ "status": "implemented", "updated_at": "{current ISO timestamp}" }
5.2. Verify session-log.jsonl is complete (REQUIRED):
Check that session-log.jsonl contains all required events:
started event exists
- One
task_started + task_completed pair per task
- One
commit event per commit
If any events are missing, append them now before proceeding.
5.3. Update sprint plan (REQUIRED if exists):
If a sprint plan file exists in .claude/workspace/ (e.g. sprint-week-*.md), mark the completed ticket as DONE.
5.4. Hand off to finish-development (REQUIRED):
Ask: "All tasks done. Ready to finish development for {key}?"
When user confirms → Invoke: Skill tool with skill="finish-development"
Do NOT create commits, push branches, or create PRs inline. The finish-development skill owns the entire delivery pipeline: commit, push, PR creation, task manager linking, status transition, worktree cleanup. It also transitions metadata to "status": "completed".
Status lifecycle:
implemented = all tasks done, code ready (set by implement Step 5.1)
completed = PR created, Jira transitioned (set by finish-development)
Plan.md Task Markers
- [ ] Pending task (not started)
- [~] In progress (currently working on this task)
- [x] Complete (task done and verified)
Edit plan.md directly. Do NOT create Task tool items.
Required Skill Invocations
| Phase | Skill | Purpose |
|---|
| Setup | branch-creator | Create branch from ticket |
| Each task | tdd | TDD workflow |
| Test failure | debug | Debug unexpected failures |
| Each task | verify | Validate before marking complete |
| Completion | finish-development | Commit, push, PR, Jira transition, set completed |
Error Handling
| Error | Action |
|---|
| No plan.md | Route back to orchestrate |
| No spec or missing ## Architecture section | Route back to orchestrate |
| Dirty git repo | Stash or commit changes first |
| Tests fail after GREEN | Invoke debug |
| Task manager auth failed | Follow adapter prerequisites section |
| VCS auth failed | Follow adapter prerequisites section |
Success Criteria