Template Engineering

Guide for creating meta-prompt templates - prompts that build prompts.

When to Use

• Creating new slash commands that generate plans

• Encoding team workflows into reusable templates

• Designing meta-prompts for chores, bugs, features

• Analyzing existing templates for improvement

Template Anatomy

Every effective template has five sections:

1. Purpose Section

Clear description at the top:

[Work Type] Planning

Create a new plan in specs/*.md to resolve the [Work Type] using the exact specified markdown Plan Format.

2. Instructions Section

Guidance for the agent:

Instructions

• You are writing a plan, not implementing
• Use your reasoning model: THINK HARD about the plan
• Focus on files in the Relevant Files section
• Include validation commands that verify completion
• Fill in every section of the Plan Format

3. Relevant Files Section

Guide context loading:

Relevant Files

Focus on the following files:

• README.md (project context)
• src/** (source code)
• tests/** (test patterns)
• docs/** (documentation)

4. Plan Format Section

Template with placeholders:

Plan Format

[WorkType]: <name>

Description

<what needs to be done>

Relevant Files

<files to modify>

Step by Step Tasks

<numbered actionable tasks>

Validation Commands

<commands proving completion>

Notes

<edge cases and considerations>

5. Parameter Section

Accept user input:

[WorkType]

$ARGUMENTS

Design Workflow

Step 1: Identify the Work Type

What class of problems does this template solve?

• Chores: Maintenance, updates, cleanup

• Bugs: Investigation and fixes

• Features: New functionality

• Refactors: Code improvement

Step 2: Define the Plan Structure

What sections does this work type need?

Work Type Essential Sections

Chore Description, Files, Tasks, Validation

Bug Problem, Solution, Reproduce, Root Cause, Tasks, Validation

Feature User Story, Implementation Plan, Testing, Acceptance

Refactor Before/After, Migration, Rollback

Step 3: Write Instructions

Guide the agent's reasoning:

• What should they focus on?

• What reasoning depth is needed? ("think hard")

• What common mistakes should they avoid?

• What format requirements are strict?

Step 4: Specify Relevant Files

Limit scope to improve quality:

• Core files for this work type

• Test files to understand patterns

• Config files if relevant

• Avoid overly broad patterns

Step 5: Test with Examples

Validate your template:

• Run with simple input

• Check generated plan completeness

• Try edge cases

• Refine based on results

Quality Checklist

Before deploying a template:

• Purpose clearly states what template does

• Instructions include "THINK HARD" for reasoning

• Relevant Files are specific, not too broad

• Plan Format has all necessary sections

• Validation Commands section is mandatory

• Parameter uses $ARGUMENTS correctly

• Output location specified (specs/*.md)

Common Patterns

Reasoning Activation

Use your reasoning model: THINK HARD about the plan and the steps to accomplish this work.

File Output Pattern

Create a new plan in specs/*.md using the following naming: specs/[worktype]-[descriptive-name].md

Validation Mandate

The Validation Commands section is REQUIRED. Every plan must include commands that prove the work is complete.

Anti-Patterns to Avoid

Too Broad Relevant Files

Bad: */ (everything) Good: src/auth/, tests/auth/ (focused)

Missing Validation Section

Bad: No way to verify completion Good: Specific test and lint commands

Vague Instructions

Bad: "Make a good plan" Good: "Focus on error handling edge cases, include rollback steps"

No Output Location

Bad: Plan written somewhere undefined Good: specs/[worktype]-[name].md pattern

Related Memory Files

• @template-engineering.md - Core concepts and examples

• @meta-prompt-patterns.md - Prompt hierarchy

• @plan-format-guide.md - Standard plan structures

Version History

• v1.0.0 (2025-12-26): Initial release

Last Updated

Date: 2025-12-26 Model: claude-opus-4-5-20251101