kn-implement

Implementing a Task

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.

Inputs

• Task ID
• Existing implementation plan
• Linked spec, docs, templates, and referenced tasks

Preflight

• Confirm a plan exists; if not, redirect to /kn-plan <id> first unless user explicitly overrides
• Read task notes and pending ACs before changing code
• Identify whether the task is standalone or linked to a spec
• If the request is to complete an approved spec or multiple linked tasks, route to /kn-flow @doc/<spec-path> instead of implementing a single task in isolation
• If linked to a spec, load the spec only as needed for requirements/AC context; do not pull a long task list into the prompt
• If linked to a spec, read every rule in its canonical Locked Decisions section before changing code. An unreadable rule or concrete conflict blocks implementation.
• Retrieve relevant accepted/current System Decisions with sourceTypes:["decision"], status:"accepted", includeHistorical:false, and a bounded task query.
• Decide what verification is required: tests, lint, build, validation, manual checks

Step 1: Review Task

mcp_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.

Step 2: Check Templates

mcp_knowns_templates({ "action": "list" })

If template exists → use it to generate boilerplate.

Step 3: Work Through Plan

For each step:

1. Do the work
2. Check AC (only after done!)
3. Append note

mcp_knowns_tasks({ "action": "update", "taskId": "$ARGUMENTS",
  "checkAc": [1],
  "appendNotes": "Done: brief description"
})