kn-template

---
name: kn-template
description: Use when generating code from templates - list, run, or create templates
---

# 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

```json
mcp__knowns__list_templates({})
```

## Step 2: Get Template Details

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

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

## Step 3: Read Linked Documentation

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

## Step 4: Run Template

```json
// 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

```json
mcp__knowns__create_template({
  "name": "<template-name>",
  "description": "Description",
  "doc": "patterns/<related-doc>"
})
```

## Template Config

```yaml
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)

```json
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)**