菜单
Use only when the user explicitly wants the legacy no-review-gates pipeline for an approved spec; prefer kn-flow for normal spec orchestration
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
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