// Use when implementing a task - follow the plan, check ACs, track progress
Use when debugging errors, test failures, build issues, or blocked tasks ā structured triage to fix to learn
Use when working with Knowns documentation - viewing, searching, creating, or updating docs
Use when extracting reusable patterns, decisions, failures, or knowledge into documentation
Use when implementing all tasks from an approved spec in one continuous run without manual review gates
Use at the start of a new session to read project docs, understand context, and see current state
Use when creating an implementation plan for a task
| name | kn-implement |
| description | 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_tasks({ "action": "get", "taskId": "$ARGUMENTS" })
If task status is "done" (reopening):
mcp_knowns_tasks({ "action": "update", "taskId": "$ARGUMENTS",
"status": "in-progress",
"appendNotes": "Reopened: <reason>"
})
mcp_knowns_time({ "action": "start", "taskId": "$ARGUMENTS" })
Verify: plan exists, timer running, which ACs pending.
mcp_knowns_templates({ "action": "list" })
If template exists ā use it to generate boilerplate.
For each step:
mcp_knowns_tasks({ "action": "update", "taskId": "$ARGUMENTS",
"checkAc": [1],
"appendNotes": "Done: brief description"
})
Working rules:
search to discover relevant sources; use retrieve when implementation needs assembled context with citations for docs, tasks, and memories.mcp_knowns_search({ "action": "retrieve", "query": "<keywords>" }) for retrieval; fall back to CLI knowns retrieve "<keywords>" --json if MCP is unavailable.Small: Add AC + note
mcp_knowns_tasks({ "action": "update", "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_time({ "action": "stop", "taskId": "$ARGUMENTS" })
mcp_knowns_tasks({ "action": "update", "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_tasks({ "action": "list", "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_memory({ "action": "add", "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_tasks({ "action": "list", "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