Use when implementing a task - follow the plan, check ACs, track progress
Execute the implementation plan, track progress, and complete the task.
Announce: "Using kn-implement for task [ID]."
Core principle: CHECK AC ONLY AFTER WORK IS DONE.
/kn-plan <id> first unless user explicitly overridesmcp__knowns__get_task({ "taskId": "$ARGUMENTS" })
If task status is "done" (reopening):
mcp__knowns__update_task({
"taskId": "$ARGUMENTS",
"status": "in-progress",
"appendNotes": "Reopened: <reason>"
})
mcp__knowns__start_time({ "taskId": "$ARGUMENTS" })
Verify: plan exists, timer running, which ACs pending.
mcp__knowns__list_templates({})
If template exists → use it to generate boilerplate.
For each step:
mcp__knowns__update_task({
"taskId": "$ARGUMENTS",
"checkAc": [1],
"appendNotes": "Done: brief description"
})
Working rules:
Small: Add AC + note
mcp__knowns__update_task({
"taskId": "$ARGUMENTS",
"addAc": ["New requirement"],
"appendNotes": "Scope: added per user"
})
Large: Stop and ask user.
mcp__knowns__validate({ "entity": "$ARGUMENTS" })
appendNotes, NOT notes!)mcp__knowns__stop_time({ "taskId": "$ARGUMENTS" })
mcp__knowns__update_task({
"taskId": "$ARGUMENTS",
"status": "done"
})
Note: When task is marked done (or AC is checked), matching ACs in the linked spec document are automatically checked. No manual spec update needed.
Check if task has spec field. If yes, run SDD workflow:
mcp__knowns__list_tasks({ "spec": "<spec-path-from-task>" })
Count tasks by status:
done: completed taskstodo / in-progress: pending tasksIf pending tasks exist:
✓ Task done! This task is part of spec: specs/xxx
Remaining tasks (Y of Z):
- task-YY: Title (todo)
- task-ZZ: Title (in-progress)
Next: /kn-plan <first-todo-id>
If this is the LAST task (all others done):
✓ Task done! All tasks for specs/xxx complete!
Running SDD verification...
Then auto-run:
mcp__knowns__validate({ "scope": "sdd" })
Display SDD Coverage Report:
SDD Coverage Report
═══════════════════════════════════════
Spec: specs/xxx
Tasks: X/X complete (100%)
ACs: Y/Z verified
✅ Spec fully implemented!
If patterns discovered: /kn-extract
If a quick insight is worth remembering but doesn't warrant a full doc:
mcp__knowns__add_memory({
"title": "<insight>",
"content": "<2-3 sentence summary>",
"layer": "project",
"category": "<pattern|decision|convention>",
"tags": ["<domain>"]
})
All built-in skills in scope must end with the same user-facing information order: kn-init, kn-spec, kn-plan, kn-research, kn-implement, kn-verify, kn-doc, kn-template, kn-extract, and kn-commit.
Required order for the final user-facing response:
Keep this concise for CLI use. Skill-specific content may extend the key-details section, but must not replace or reorder the shared structure.
Out of scope: explaining, syncing, or generating .claude/skills/*. Runtime auto-sync already handles platform copies, so this skill source only defines the built-in output contract.
For kn-implement, the key details should cover:
You MUST suggest the next action when a natural follow-up exists. User won't know what to do next.
After task completion, check for:
More tasks from same spec?
mcp__knowns__list_tasks({ "spec": "<spec-path>", "status": "todo" })
Suggest based on context:
| Situation | Suggest |
|---|---|
| More tasks in spec | "Next: /kn-plan <next-task-id> for [task title]" |
| All spec tasks done | "All tasks complete! Run /kn-verify to verify against spec" |
| Standalone task | "Task done. Run /kn-extract to extract patterns, or /kn-commit to commit" |
| Patterns discovered | "Consider /kn-extract to document this pattern" |
Example output:
✓ Task #43 complete!
Next task from @doc/specs/user-auth:
→ Task #44: Add refresh token rotation
Run: /kn-plan 44
/kn-plan <id> - Create plan before implementing/kn-verify - Verify all tasks against spec/kn-extract - Extract patterns to docs/kn-commit - Commit with verificationnotes instead of appendNotes