Menu
Use when running SDD verification and coverage reporting
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 only when the user explicitly wants the legacy no-review-gates pipeline for an approved spec; prefer kn-flow for normal spec orchestration
| name | kn-verify |
| description | Use when running SDD verification and coverage reporting |
Run validation with SDD-awareness to check spec coverage and task status.
Announce: "Using kn-verify to check SDD status."
Core principle: VERIFY SPEC COVERAGE → REPORT WARNINGS → SUGGEST FIXES.
knowns validate --sdd --plain
mcp_knowns_validate({ "scope": "sdd" })
Return the verification result using the shared output contract:
The key-details portion may include a compact status block such as:
Specs: X total | Y approved | Z draft
Tasks: X total | Y done | Z in-progress | W todo
Coverage: X/Y tasks linked to specs (Z%)
Warnings:
- task-XX has no spec reference
- specs/feature: X/Y ACs incomplete
Passed:
- All spec references resolve
- specs/auth: fully implemented
Good coverage (>80%):
SDD coverage is healthy. All tasks are properly linked to specs.
Medium coverage (50-80%):
Some tasks are missing spec references. Consider:
- Link existing tasks to specs:
knowns task edit <id> --spec specs/<name>- Create specs for unlinked work:
/kn-spec <feature-name>
Low coverage (<50%):
Many tasks lack spec references. For better traceability:
- Create specs for major features:
/kn-spec <feature>- Link tasks to specs:
knowns task edit <id> --spec specs/<name>- Use
/kn-plan --from @doc/specs/<name>for new tasks
Based on warnings, add the most relevant fixes inside the key-details section, then give one best next command only if a natural handoff exists:
For tasks without spec:
Link task to spec:
mcp_knowns_tasks({ "action": "update", > "taskId": "<id>", "spec": "specs/<name>" })
For incomplete ACs:
Check task progress:
knowns task <id> --plain
For approved specs without tasks:
Continue the approved spec through orchestration:
/kn-flow @doc/specs/<name>If the user only wants task generation:
/kn-plan --from @doc/specs/<name>
To validate a single task or doc (saves tokens):
// Validate single task
mcp_knowns_validate({ "entity": "abc123" })
// Validate single doc
mcp_knowns_validate({ "entity": "specs/user-auth" })
All built-in skills in scope must end with the same user-facing information order: kn-init, kn-spec, kn-flow, 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. Verification-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-verify, the key details should cover:
When verification reveals a clear follow-up, include the best next command. If the project is already healthy and no immediate workflow continuation is obvious, stop after the result and key details.
/kn-flow @doc/<spec-path> - Continue an approved spec with pending or missing task execution/kn-plan --from @doc/<spec-path> - Generate tasks only when verification shows an approved spec has none/kn-review <id> - Review implemented work before final verification/kn-flow when an approved spec has pending execution/kn-flow is the better approved-spec handoff