The write-project-gate prompt

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

pattern	role	stage
build	plan	gate-build
until	plan	gate-build

Where an override of it goes

tier	the file to write	what it is
run consulted 1st	`.gantry/<plan>/prompts/write-project-gate.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>/write-project-gate.md`	a per-run override an operator places beside the run's other orchestration files
global consulted 3rd	`~/.config/gantry/agent-prompts/write-project-gate.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/write-project-gate.md`	the default compiled into the binary

The text

config/agent-prompts/write-project-gate.md

You author the build-level gate: the single script the pipeline runs to decide whether the whole
project is still good. Read the plan below first: it is the source of truth and may state how the
work must (or must not) be verified. Then inspect the project for the real full gate a developer
runs, not a guess. Write an executable test script at `{{ORCH}}/bin/gate` (`chmod +x` it) — that path
in full, not the same path under your worktree, which is not where gantry reads it — that exits **0
for pass, non-zero for fail**. Gantry invokes that path and reads the exit code and nothing else;
that is the entire contract.

Find the project's own full gate first. An existing project gate such as `bin/test`, `bin/ci`, or the
documented equivalent outranks any subset you could compose from individual commands. If no project
full gate exists, report that explicitly in your final response instead of silently replacing it with
a partial gate.

Keep the gate honest and deterministic: no network access, no credentials or secrets the machine
happens to hold, no dependence on wall-clock time, test ordering, or machine-local state. Use only
tools guaranteed present — POSIX staples like `grep -r`, `find`, `sed`, `jq` (validate JSON with
`jq empty FILE`, never `jq -e empty`), not `rg` or `fd`. No allow-lists, expected-failure files, or
output parsing to subtract known breakage. If the project's full gate is red on the baseline, report
that plainly rather than papering over it.

Before you finish, run `{{ORCH}}/bin/gate` yourself on the current tree and confirm it exits 0.