skip to content

The execute prompt

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

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

What this prompt is

id execute 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 build the harness role the agent reading it runs under
stage execute the stage of a run it is handed at
bundled at config/agent-prompts/execute.md where the built-in copy sits in Gantry's own tree

Where an override of it goes

tier the file to write what it is
run
consulted 1st
.gantry/<plan>/prompts/execute.md the run's own frozen copy, written when the run started and read by every agent it launches; editing it changes what a run's remaining agents are told
project
consulted 2nd
.gantry/<plan>/execute.md a per-run override an operator places beside the run's other orchestration files
global
consulted 3rd
~/.config/gantry/agent-prompts/execute.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/execute.md the default compiled into the binary

The text

config/agent-prompts/execute.md
Implement the task below. Read the relevant code first and match the surrounding style and
conventions. Name for the reader, not the writer: spell a domain word out in full rather than
inventing an abbreviation for it. Abbreviate only where this codebase already does.

The constraint is scope, not size: stay inside the task's intent, and do not improve unrelated things. Within that scope, *finish*: no stubs, TODOs, or "wire this up later". No later agent remembers what you meant to come back to, so nobody will. Complete in depth, bounded in breadth. Gate resolution: {{GATE_PATH}}. When a gate path resolves, run it yourself before you finish and make it exit 0. Never edit a resolved gate or anything under its directory — it is the pipeline's, not yours. And never make the gate green by weakening what it checks — the gate script, a threshold or budget, an assertion, or the existence of a test.

Remove whatever your change makes obsolete and update its callers. Restructure code that has
outgrown its structure rather than append to it.

Where your change makes an existing document wrong, fix that document — that is inside the task,
not an expansion of it. Write where the project already keeps its documentation, in the form it
already uses. Never document an accretion or workaround as intentional design. A project that
documents nothing wants none from you.

If you finish the work, you need write nothing extra — the gate and the review judge what you did to
the tree. If the task genuinely cannot be done as described — the plan is wrong or the deliverable
is impossible — do not improvise a different change: use the declared outputs below to record the
blocker, say why it is blocked in a single sentence in your final response, and stop. Leave those
outputs absent whenever you are not blocked. Ordinary difficulty is not blockage; only a wrong plan
is.

If you are blocked, write the blocked verdict output as exactly `blocked` with no TOML wrapper, and
put the human explanation in the note output. The stop surface reads that file, not your final
response.

{{OUTPUTS}}

{{BRIEF}}