Skip to main content
The freeze command assigns one spec-freezer subagent to turn the raw task text into a verifiable, unambiguous specification stored at .agent/tasks/<TASK_ID>/spec.md. All downstream commands — build, evidence, verify, and fix — treat this file as the single source of truth for acceptance criteria.
The spec-freezer must not change any production code, and must not write verdict.json, evidence.json, evidence.md, or problems.md.

​
Parent prompt

Copy this prompt verbatim when delegating to the spec-freezer subagent. Replace <TASK_ID> with the actual task identifier. 
You are in SPEC FREEZE mode for TASK_ID <TASK_ID>.

Read:
- .agent/tasks/<TASK_ID>/spec.md
- AGENTS.md if present
- CLAUDE.md if present
- .claude/CLAUDE.md if present
- relevant .claude/rules/**/*.md files if present
- any user-provided task file or inline task text
- only the minimum relevant code needed to freeze the spec

Write or update:
- .agent/tasks/<TASK_ID>/spec.md

Requirements:
- Preserve the original task statement
- Produce explicit acceptance criteria labeled AC1, AC2, ...
- Include constraints
- Include non-goals
- Add a concise verification plan
- Resolve ambiguity narrowly and list assumptions
- Do not change production code
- Do not write evidence, verdict, or problems files

​
What the spec-freezer reads

  • .agent/tasks/<TASK_ID>/spec.md — the seeded placeholder created by init, which may already contain the original task statement
  • Any user-provided task file or inline task text passed to the parent
  • AGENTS.md if present
  • CLAUDE.md if present
  • .claude/CLAUDE.md if present
  • Relevant .claude/rules/**/*.md files if present
Only the minimum relevant production code needed to clarify ambiguity and freeze the spec. No broad codebase exploration.

​
What the spec-freezer writes

The spec-freezer writes or updates a single file: 
.agent/tasks/<TASK_ID>/spec.md

​
spec.md requirements

A frozen spec.md must contain at least:
1

Original task statement

The user’s task preserved verbatim or with only formatting changes. Never rewritten.
2

Acceptance criteria

Explicit, individually verifiable criteria labeled AC1, AC2, AC3, … Each criterion must be independently provable by a fresh verifier.
3

Constraints

Technical, scoping, or compatibility requirements that bound the implementation.
4

Non-goals

Explicit list of what the task does not include. Prevents scope creep during build.
5

Verification plan

A concise plan describing how each acceptance criterion will be verified — commands to run, files to inspect, or behaviors to observe.
6

Assumptions

Ambiguities resolved narrowly. Each assumption should be stated explicitly so the verifier can challenge it if necessary.

​
Hard boundaries

Must not touch

Any production code file in the repository.

Must not write

verdict.json, problems.md, evidence.md, or evidence.json.
Run init and confirm .agent/tasks/<TASK_ID>/spec.md exists before invoking the spec-freezer. Never overlap init with freeze or any other command.

Build docs developers (and LLMs) love

Get started for freeTalk to us