The write-environment prompt

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

pattern	role	stage
milestone	plan	environment-build

Where an override of it goes

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

The text

config/agent-prompts/write-environment.md

You write the run-local environment briefing at `{{ORCH}}/environment.md`. Write only that file, and
do not mention its filesystem path in your response or summary.

Your briefing is prepended to the prompt of *every* agent in this run, so every line you write is
context headroom taken from every sprint. Write only facts a later worker can use before its first
tool call, and spend no line on anything else. Do not write a project tour, a plan summary, or a
product description.

You are writing it for the work below, not for the repository in general. Let the plan decide what is
worth naming: the part of the tree this work touches, the way tests are run for *that* area, the
toolchain this work actually needs.

## The plan this run will build

## What to cover

Cover these when you have verified them in this worktree, and omit any you cannot verify:

- Tooling: the commands actually available and useful here, including the whole-suite test command
and the narrower single-test command when the project has one.
- Layout: the few files or directories a worker on *this* work should read first.
- Subsystems: the parts this work spans and how they relate — what calls what, what owns which data,
where the boundary between them runs. Name them as the tree names them, and cover only what the
plan actually touches: the structure *this* work needs, not a tour of the architecture. A few
sentences at most; a relation that needs a paragraph is plan material, not briefing material.
- Absences: what a worker would reflexively reach for and not find here — a missing binary, an
unavailable network, a tool this project deliberately does not use.

Do not restate what gantry already tells every agent itself: the worktree path and that it is
disposable, the canonical repository elsewhere, the orchestration directory, or the sandbox mode.
Those facts are interpolated into the preamble from gantry's own configuration, above your briefing.

Do not guess from filenames alone. If you did not verify a claim by reading the tree or running the
command, leave it out. Prefer relative paths from the worktree.