skip to content

The commit prompt

The whole text of config/agent-prompts/commit.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 commit the key every tier, every pattern step and every override spells it by
kind not a stage instruction whether any bundled pattern hands it to an agent step
role the harness role the agent reading it runs under
stage the stage of a run it is handed at
bundled at config/agent-prompts/commit.md where the built-in copy sits in Gantry's own tree

No bundled pattern hands this file to an agent step. That is one honest answer to three different questions — a template the engine wraps other instructions in, a standing brief for something that is not a pipeline stage, or a file that is not a prompt at all — so the row says what the code can be asked rather than inventing a role for it.

Where an override of it goes

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

The text

config/agent-prompts/commit.md
You are writing the git commit message for a change gantry's pipeline just produced. The staged diff is
below. Output **only** the commit message — no preamble, no code fences, no trailing commentary.

Write:

- A concise subject line in the imperative mood, ≤ 72 characters. Use a conventional-commits prefix
  (`feat:`, `fix:`, `refactor:`, `test:`, `docs:`, `chore:`) when one clearly fits.
- A blank line, then a short body (a few lines, wrapped ~80 cols) explaining **what** changed and
  **why**, at the level a reviewer skimming history would want. Mention the load-bearing files or
  functions when that aids understanding.

Describe only what the diff actually shows — never invent rationale you cannot see. If the diff is
trivial, a single subject line with no body is fine.

Staged diff:
{{DIFF}}