Menu
Use only when the user explicitly wants the legacy no-review-gates pipeline for an approved spec; prefer kn-flow for normal spec orchestration
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Use when orchestrating a full Knowns spec or task wave through planning, implementation, review, integration, and verification, optionally using sub-agents when scopes are parallel-safe.
Use when you need to understand existing code, find patterns, search project knowledge, use web research for external/current facts, or explore a large codebase before implementation
Use when committing code changes with proper conventional commit format and verification
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
| name | kn-go |
| description | Use only when the user explicitly wants the legacy no-review-gates pipeline for an approved spec; prefer kn-flow for normal spec orchestration |
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.
kn-go, "go mode", or a no-review-gates auto pipelinespec, approved)/kn-spec first/kn-plan <id> + /kn-implement <id>/kn-flow @doc/<spec-path>specs/<name> (from $ARGUMENTS or ask user)--dry-run to preview tasks without executingFor most approved specs, use /kn-flow @doc/<spec-path> instead. kn-flow schedules tasks, gates parallel work, runs implementation and review together, and performs combined verification before commit.
Complete 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:
/kn-flow @doc/<spec-path> — preferred approved-spec orchestration path/kn-plan --from @doc/<spec-path> — generate tasks only/kn-review <id> — review implemented task or integrated wave/kn-verify — final SDD verificationWith --dry-run:
Show what would be created and ask user to confirm before running for real.
kn-go when /kn-flow is expected for review/sub-agent orchestration