knowns-dev/kn-template

Working with Templates

Announce: "Using kn-template to work with templates."

Core principle: USE TEMPLATES FOR CONSISTENT CODE GENERATION.

Inputs

• Template name or generation goal
• Variables required by prompts
• Linked pattern doc, if one exists

Preflight

• Read the linked doc before running a non-trivial template
• Use dry run before generating real files
• Check whether a template already exists before creating a new one

Step 1: List Templates

mcp_knowns_templates({ "action": "list" })

Step 2: Get Template Details

mcp_knowns_templates({ "action": "get", "name": "<template-name>" })

Check: prompts, doc: link, files to generate.

Step 3: Read Linked Documentation

mcp_knowns_docs({ "action": "get", "path": "<doc-path>", "smart": true })

Step 4: Run Template

// 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
})

Step 5: Create New Template

mcp_knowns_templates({ "action": "create", "name": "<template-name>",
  "description": "Description",
  "doc": "patterns/<related-doc>"
})

Template Config

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"

CRITICAL: Syntax Pitfalls

NEVER write $ + triple-brace:

// ❌ WRONG
$` + `{` + `{` + `{camelCase name}`

// ✅ CORRECT - add space, use ~
${ {{~camelCase name~}}}

Step 6: Validate (after creating template)

mcp_knowns_validate({ "scope": "templates" })

Shared Output Contract

All built-in skills in scope must end with the same user-facing information order: kn-init, kn-spec, 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:

1. Goal/result - state what template was inspected, created, or run.
2. Key details - include the most important supporting context, refs, files, warnings, or validation.
3. Next action - recommend a concrete follow-up command only when a natural handoff exists.

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:

• which template was inspected, created, or run
• dry-run vs real execution
• generated or modified files
• any missing prompt values, doc gaps, or syntax issues

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.

Failure Modes

• Missing linked doc -> say so and inspect the template directly
• Dry run looks wrong -> stop and fix the template before real generation
• New template overlaps an existing one -> prefer update or consolidation

Checklist

• [ ] Listed available templates
• [ ] Read linked documentation
• [ ] Ran dry run first
• [ ] Verified generated files
• [ ] Validated (if created new template)