// Use when implementing all tasks from an approved spec in one continuous run without manual review gates
| name | kn-go |
| description | Use when implementing all tasks from an approved spec in one continuous run without manual review gates |
Run the entire SDD pipeline from an approved spec: generate tasks → plan each → implement each → verify → commit. No manual review gates between steps.
Announce: "Using kn-go for spec [name]."
Core principle: SPEC APPROVED → GENERATE TASKS → PLAN → IMPLEMENT ALL → VERIFY → COMMIT.
spec, approved)/kn-spec first/kn-plan <id> + /kn-implement <id>specs/<name> (from $ARGUMENTS or ask user)--dry-run to preview tasks without executingComplete these phases in order. Do not skip phases.
mcp_knowns_docs({ "action": "get", "path": "specs/<name>", "smart": true })
Check:
approved — if not, STOP: "Spec not approved. Run /kn-spec <name> first."mcp_knowns_validate({ "entity": "specs/<name>" })
If validation errors → fix or report before continuing.
Parse spec for requirements and generate tasks. Same logic as kn-plan --from @doc/specs/<name> but skip the approval gate.
mcp_knowns_tasks({ "action": "create", "title": "<requirement title>",
"description": "<from spec>",
"spec": "specs/<name>",
"fulfills": ["AC-1", "AC-2"],
"priority": "medium",
"labels": ["from-spec", "go-mode"]
})
Add implementation ACs per task:
mcp_knowns_tasks({ "action": "update", "taskId": "<id>",
"addAc": ["Step 1", "Step 2", "Tests"]
})
Report: "Created X tasks from spec. Starting implementation..."
Loop through all generated tasks in dependency order (foundational first, dependent last).
For each task:
mcp_knowns_tasks({ "action": "update", "taskId": "<id>",
"status": "in-progress"
})
mcp_knowns_time({ "action": "start", "taskId": "<id>" })
search for discovery first. If a task/spec needs assembled execution context, use mcp_knowns_search({ "action": "retrieve", "query": "<keywords>" }) before drafting or executing the plan. Fall back to CLI knowns retrieve "<keywords>" --json if MCP is unavailable.mcp_knowns_search({ "action": "search", "query": "<task keywords>", "type": "memory" })
mcp_knowns_tasks({ "action": "update", "taskId": "<id>",
"plan": "1. Step one\n2. Step two\n3. Tests"
})
mcp_knowns_tasks({ "action": "update", "taskId": "<id>",
"checkAc": [1, 2, 3],
"appendNotes": "Implemented: brief summary"
})
mcp_knowns_time({ "action": "stop", "taskId": "<id>" })
mcp_knowns_tasks({ "action": "update", "taskId": "<id>",
"status": "done"
})
mcp_knowns_validate({ "entity": "<id>" })
If errors → fix before moving to next task.
Progress report between tasks:
"✓ Task X/Y done: [title]. Continuing..."
After all tasks complete:
mcp_knowns_validate({ "scope": "sdd" })
Report SDD coverage:
SDD Coverage Report
═══════════════════
Spec: specs/<name>
Tasks: X/X complete (100%)
ACs: Y/Z verified
If coverage < 100% → identify gaps and fix.
Also run project-level checks:
# Build/test/lint — adapt to project
go build ./...
go test ./...
Stage all changes and commit with a single conventional commit:
git add -A
git diff --staged --stat
Generate commit message:
feat(<scope>): implement <spec-name>
- Task 1: <title>
- Task 2: <title>
- ...
- All ACs verified via SDD
This is the ONE gate in go mode — ask user before committing:
Pipeline complete. X tasks done, SDD verified.
Ready to commit:
feat(<scope>): implement <spec-name>Proceed? (yes/no/edit)
If context exceeds ~60% during implementation:
/kn-go specs/<name> again to continue remaining tasks."The skill will detect already-done tasks and skip them on re-run.
When invoked on a spec that already has tasks:
todo and in-progress onlydone tasksmcp_knowns_tasks({ "action": "list", "spec": "specs/<name>" })
blocked, append notes, continue to next task.Required order for the final user-facing response:
For kn-go, the key details should cover:
With --dry-run:
Show what would be created and ask user to confirm before running for real.
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 a task - follow the plan, check ACs, track progress
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