Chapter 2: Planning: Plan Artifacts, Constraints, Definition of Done

Series: LLM Development Guide

Chapter 2 of 15

Previous: Chapter 1: A Practical Workflow for LLM-Assisted Development That Doesn’t Collapse After Day 2

Next: Chapter 3: Prompt Documents: Prompts That Survive Sessions

What you’ll be able to do

You’ll be able to write a plan artifact that:

• Forces clarity on scope, constraints, and references.
• Produces verification steps (not just a task list).
• Is sized so an LLM can execute it phase-by-phase without drifting.

TL;DR

• A plan is a shared source of truth between you and the model.
• Keep plans at the “what” level; keep “how” in prompt docs.
• Every phase needs verification and a definition of done.
• If a plan file would exceed ~200 lines, split it.
• Always point to reference implementations by path.

Table of contents

• What belongs in a plan (and what doesn’t)
• A plan template you can paste
• Sizing rules
• Verification and definition of done
• Verification
• Gotchas

What belongs in a plan (and what doesn’t)

Plans work when they are explicit and boring.

Include:

• Goals and non-goals.
• Constraints and invariants.
• Reference implementations (by path).
• Phases in dependency order.
• Verification for each phase.

Avoid:

• Full code blocks.
• Deep implementation detail.
• “Make it better” language.

If you want the LLM to do a thing consistently across sessions, you need the thing written down.

A plan template you can paste

Create one plan file per phase for larger work.

# <Project> Plan

## Overview
<1 to 2 sentences about what we are building>

## Goals
- <Goal 1>
- <Goal 2>

## Non-goals
- <Explicitly out of scope>

## Constraints
- <Must follow reference style X>
- <Must not add dependencies>
- <Must keep backward compatibility>

## References
- <Path to reference implementation 1>
- <Path to reference implementation 2>

## Phase 1: <Name>
- [ ] <Task 1>
- [ ] <Task 2>

Verification:
- <Command>
- Expected: <Exit 0 / output contains X>

## Phase 2: <Name>
- [ ] <Task 1>

Verification:
- <Command>
- Expected: <...>

## Definition of done
- [ ] <All phases verified>
- [ ] <Tests pass>
- [ ] <Docs updated as needed>
- [ ] <No TODOs left behind>

## Risks / open questions
- <Open question 1>
- <Risk 1>

Sizing rules

You need the plan sized so the LLM can execute it without mixing unrelated changes.

Use these rules of thumb:

• Small (hours to 1 to 2 days): one PLAN.md.
• Medium (1 to 2 weeks): one PLAN.md with explicit phases.
• Large (multi-week): plan/phase-1a-...md, plan/phase-1b-...md, etc.

When in doubt:

• Split by file ownership (phases should avoid editing the same files).
• Split by interface boundaries (one phase defines types/contracts; later phases implement).

Verification and definition of done

Make verification explicit in the plan so you don’t have to negotiate it mid-session.

Bad:

• “Add tests”

Better:

• “Add unit tests for Foo and run go test ./... (expected: exit 0).”

If your phase can’t be verified, it probably isn’t a phase yet.

Verification

If you follow the template above, you should be able to run something like:

# Example: lint and test gates.
# Replace with your repo's actual commands.

go test ./...

git diff --stat

Expected results:

• go test exits 0.
• git diff --stat shows only the files you intended to touch in this phase.

Gotchas

• Plans that mix “what” and “how” become unreadable quickly.
• If you don’t write down constraints, the LLM will invent defaults.
• A “phase” that touches 30 files is usually multiple phases.

Continue -> Chapter 3: Prompt Documents: Prompts That Survive Sessions