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__list_templates({})

Step 2: Get Template Details

mcp__knowns__get_template({ "name": "<template-name>" })

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

Step 3: Read Linked Documentation

mcp__knowns__get_doc({ "path": "<doc-path>", "smart": true })

Step 4: Run Template

// Dry run first
mcp__knowns__run_template({
  "name": "<template-name>",
  "variables": { "name": "MyComponent" },
  "dryRun": true
})

// Then run for real
mcp__knowns__run_template({
  "name": "<template-name>",
  "variables": { "name": "MyComponent" },
  "dryRun": false
})

Step 5: Create New Template

mcp__knowns__create_template({
  "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)

Converted and distributed by TomeVault — claim your Tome and manage your conversions.