skip to content

The design/briefs/review prompt

The whole text of config/agent-prompts/design/briefs/review.md, as an agent is handed it.

Bundled agent prompts — one row of 30, exported from config/agent-prompts · every prompt · the resolution order

What this prompt is

id design/briefs/review the key every tier, every pattern step and every override spells it by
kind stage instruction whether any bundled pattern hands it to an agent step
role review the harness role the agent reading it runs under
stage review the stage of a run it is handed at
bundled at config/agent-prompts/design/briefs/review.md where the built-in copy sits in Gantry's own tree
pattern role stage
milestone review review

Where an override of it goes

tier the file to write what it is
run
consulted 1st
.gantry/<plan>/prompts/design/briefs/review.md the run's own frozen copy, written when the run started and read by every agent it launches; edit it to change what a run's remaining agents are told
project
consulted 2nd
.gantry/<plan>/design/briefs/review.md a per-run override an operator drops beside the run's other orchestration files
global
consulted 3rd
~/.config/gantry/agent-prompts/design/briefs/review.md the materialized global mirror; it overrides the built-in once its bytes differ from the built-in's
built-in
consulted 4th
config/agent-prompts/design/briefs/review.md the default compiled into the binary

The text

config/agent-prompts/design/briefs/review.md
Review the design brief for the ticket below. The gate proves only that the brief exists and has the
required sections; judge whether a fresh page builder could actually build a distinctive, faithful page
from it.

Check purpose, data contract, functions, signature, states, materials, and done criteria against the
project. Improve the brief directly when the fix is safe. If it needs another pass, write the review
scope verdict and retry note requested by the standard review contract. If it changes assumptions for
remaining tickets, express that by editing the scoped ticket files the active pattern permits.

When you route, use the run history in your environment section. Repeated failure on one ticket is
evidence about the ticket: repeat the same ticket only when the prior note named one specific gap,
this attempt closed it, and the rest is plainly reachable in one more pass. Judge the whole ticket
each time, not just what the previous review complained about - attempts that each deliver a
different fragment mean the ticket asks for too many independent things; say so and edit the scoped
ticket files when permitted. The attempt count is never a reason to lower the bar: do not mark a final
attempt `complete` to let the run proceed - the attempt budget exists so an unconvergeable ticket
stops visibly and resumably.

Write `{{VERDICT_PATH}}` as TOML holding exactly one of `value = "complete"`, `value = "retry"`, or
`value = "blocked"`. The file holds that one TOML assignment and nothing else - no prose verdict line.
When choosing `retry`, write the one-sentence reason to `{{RETRY_NOTE_PATH}}`.

Brief:
{{BRIEF}}

Diff:
{{DIFF}}