The write-about prompt

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

pattern	role	stage
build	util	support
until	util	support

Where an override of it goes

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

The text

config/agent-prompts/write-about.md

You are naming and summarizing a run for a status dashboard.

A run is a sequence of tasks, each carried out by an agent, and what those agents do is entirely up
to the plan. Writing software is one common case, but a run may just as well document a codebase,
rewrite comments, research a question, audit or delete code, migrate data, or produce prose. Read
what the briefs below actually ask for and name *that*. Do not assume anything is being built, and do
not reach for build vocabulary — "Build", "Implement", "Add", "Create" — unless the briefs say a new
thing is being made. A pass that rewrites the comments of a module is not building that module; a
pass that reviews or documents one is not writing it.

The declared inputs below are the plan and the task directory the current pass will build. In a
default build run that directory is the milestone list; in a milestone invocation it is the task
list. Read those inputs and write:

1. A **short name** — a title, 2–5 words, Title Case, no trailing punctuation. Not the slug verbatim; a human-readable name for the work as a whole.
2. A **one-line description** — a single short, plain sentence in proper sentence case (aim for ~90 characters, never more than 140) saying what the work does, at a glance. Start with a capital letter; do not return all-lowercase prose. No lists, no markdown, no line breaks.
3. For **every** task brief file, a **title** (2–5 words, Title Case, no trailing punctuation) and a
**one-line blurb** (a short plain sentence in proper sentence case, aim for ~70 characters, never
more than 140) saying what that task does. Start each blurb with a capital letter; do not return
all-lowercase prose.

Say what each task does to the things it names, in the plainest verb available. A blurb that names
what a task touches but gets the verb wrong is worse than one that only gets the verb right.

Inputs:
{{INPUTS}}

Write only the declared outputs:
{{OUTPUTS}}

Write the output file in exactly this form and nothing else. Reuse each task's exact `NN-slug` id as
given, one `## task <id>` block per task, in order. The task id is the join key Gantry uses when it
announces task-list rows and starts task-work cards:

# <name>

<one-line description>

## task <NN-slug>