Menu
Use when generating code from templates - list, run, or create templates
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-template |
| description | Use when generating code from templates - list, run, or create templates |
Announce: "Using kn-template to work with templates."
Core principle: USE TEMPLATES FOR CONSISTENT CODE GENERATION.
mcp_knowns_templates({ "action": "list" })
mcp_knowns_templates({ "action": "get", "name": "<template-name>" })
Check: prompts, doc: link, files to generate.
mcp_knowns_docs({ "action": "get", "path": "<doc-path>", "smart": true })
// Dry run first
mcp_knowns_templates({ "action": "run", "name": "<template-name>",
"variables": { "name": "MyComponent" },
"dryRun": true
})
// Then run for real
mcp_knowns_templates({ "action": "run", "name": "<template-name>",
"variables": { "name": "MyComponent" },
"dryRun": false
})
mcp_knowns_templates({ "action": "create", "name": "<template-name>",
"description": "Description",
"doc": "patterns/<related-doc>"
})
name: react-component
description: Create a React component
doc: patterns/react-component
prompts:
- name: name
message: Component name?
validate: required
files:
- template: ".tsx.hbs"
destination: "src/components//.tsx"
NEVER write $ + triple-brace:
// ❌ WRONG
$` + `{` + `{` + `{camelCase name}`
// ✅ CORRECT - add space, use ~
${ {{~camelCase name~}}}
mcp_knowns_validate({ "scope": "templates" })
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. Template-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-template, the key details should cover:
When template work naturally leads to implementation or review, include the best next command. If the user only inspected templates or finished with a dry run decision, do not force a handoff.