Write plan templates with conditional sections that activate by task type — so every plan the agent receives contains exactly what applies and nothing it doesn't.

Guide

How to Use Adaptive Templates

Why flat templates fail

A bugfix plan doesn't need a migration section.

one flat template

Bugfix task — same shape as a feature

##Contextkept

##Acceptancekept

##Data Migrationnoise

##API Contractnoise

##Rollout Plannoise

##Test Plankept

Agent reads five irrelevant sections before reaching the one that matters — context diluted, token budget spent, signal buried.

adaptive

Bugfix task — template prunes itself

##Contextkept

##Acceptancekept

##Data Migrationskip

##API Contractskip

##Rollout Planskip

##Test Plankept

Only what applies appears. The same template source produces a different plan shape per task type — nothing hand-pruned.

Unused sections aren't neutral — they're pollution. The plan is the prompt.

The reading path

Five nodes — principle down to enforcement.

Read in this order to build up the "why" before the "how".

1

Principle

The Plan is the Prompt

A plan is not documentation — it's the prompt the implementing agent operates from. Every structural decision is an agent-performance decision.

2

Principle

Avoid Context Pollution

Sections that don't apply are noise. They dilute relevant context and spend token budget on nothing. Conditional sections become a correctness requirement — not a style choice.

3

Pattern

Adaptive Template Activation

The architectural response. Sections carry activation conditions — task type, complexity tier, classification label — and are included or suppressed accordingly.

4

Primitive

Plan

The artifact adaptive templates produce. Grounds every template decision in what the downstream agent actually consumes — its required fields, its shape, its contract.

5

Enforcement

Template-Declared Contracts

Makes the conditional structure verifiable: if a section is present, its required fields must be present. Converts the template from suggestion into enforceable gate.

Skip any node and you're guessing at a downstream layer — the motivation won't carry.

What a section looks like

Activation condition on top. Required fields underneath.

templates/plan.md

adaptive

## Context— always present —## Acceptance— always present —if: task_type == "feature"## API Contractrequiredendpoint, request, response, errorsif: touches_schema == true## Data Migrationrequiredforward, rollback, data-loss-riskif: complexity >= "high"## Rollout Planrequiredflag, cohort, abort-signal## Test Plan— always present —

Condition decides presence. Once a section is present, its required fields become non-negotiable — that's the contract.

Which sections fire per task

Same template. Four task shapes.

bugfix

Context

Acceptance

Test Plan

API Contract

Data Migration

Rollout Plan

feature (low)

Context

Acceptance

API Contract

Test Plan

Data Migration

Rollout Plan

feature (high)

Context

Acceptance

API Contract

Rollout Plan

Test Plan

Data Migration

schema change

Context

Acceptance

Data Migration

Test Plan

API Contract

Rollout Plan

One template source — four distinct plan shapes. The classification label is the only thing the author has to get right.

The discipline

A template is a function of task type — not a fixed shape every plan must wear.

Tag sections with activation conditions. Declare required fields per section. Let the contract reject malformed plans before they reach the implementing agent. The plan the agent reads is the plan it was designed for.