knowns-dev/knowns/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

Use the current template schema returned by templates({ action: "get" }). A minimal example:

name: react-component
description: Create a React component
doc: patterns/react-component
 
prompts:
  - name: name
    type: text
    message: Component name?
    validate: required
 
actions:
  - type: add
    template: component.tsx.hbs
    path: src/components/{{pascalCase name}}.tsx
    skipIfExists: true

Syntax Rules

• Use the template engine's documented {{helper value}} expressions directly.
• Do not construct template delimiters through string concatenation or add JavaScript interpolation syntax around them.
• Validate helper names and output paths with a dry run before writing files.

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-flow, kn-go, kn-plan, kn-research, kn-handoff, kn-implement, kn-test, kn-review, kn-debug, kn-decision, 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.

Do not manage platform-synced skill copies; this source defines the built-in workflow 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)