Settings

GTM keeps its settings in two files. config.yml holds the mechanics: paths, commands, git rules. team.md, your team settings, holds the weights: priorities, roles, specialists and limits, each with its reason and the date it was decided. /gtm:init drafts both; /gtm:tune changes them.

What does config.yml hold?

Every command and role reads it first. Paths are relative to the repository root; regexes are JavaScript syntax, matched against repository-relative paths.

Can I add my own gate step?

Yes. A key you add under verify runs when verify.gate lists it:

verify:
  crap: "<command>"
  gate: [lint, test, crap]

One example is a CRAP (Change Risk Anti-Patterns) score, per function. Complexity here means cyclomatic complexity, the number of independent paths through the function, and coverage runs from 0 to 1:

complexity² × (1 − coverage)³ + complexity

The formula comes from crap4j, a Java tool, whose limit is 30. Complexity 10 reads 110 with no test and 10 fully covered, so a complex untested function stands out.

The score is language-neutral: any tool that gives cyclomatic complexity and coverage per function will do. Your command exits non-zero above your limit. GTM ships no such command and runs none by default.

What does team.md hold?

Your team settings, read by every command that dispatches a role. Each line carries its reason and the date it was decided; GTM passes the role values on every call, so they win over the defaults in the role files.

Risky paths also set effort. Work that touches them raises the security and final reviewers one level, and lets the implementer’s correction rounds climb to xhigh; elsewhere those rounds stop at high.

The limits and their defaults: a task gets 3 correction rounds, each raising the implementer’s effort one level; the file limit for a fix is 3 files; mockups pass at 8/10 with no must-fix finding and are redrawn 3 times at most, and with a picked direction the taste threshold is 7 out of 10; risky tasks get a dry run, on paths matching migrations?/, ((?<!a)sync|contract|schema) and (db|store|storage)/. The review cadence line sets how often each reviewer runs: by default the reviewer once per wave of standard tasks, ux-qa once per branch, the security and data reviewers on every task they concern; fix rounds per standard review gives a wave’s review one correction round. The two budgets, budget per task and budget per branch, are none or <minutes> min, <tokens>k tokens, and start at none; a profile without these lines reads as none. Past 1.5 times a budget, /gtm:deliver raises a Heads-up, notes it in the ledger and goes on: no budget changes a verdict, a correction round or the order of tasks. After three measured runs with no budget, /gtm:tune proposes both at the medians of those runs. The tasks per branch line caps a plan at 8 tasks by default, a release-only task not counted; a plan over it goes back to the architect once, then you choose on a card to split or accept.

To change any of them, see Change your team settings.

How do I sign a standing go?

A standing go is your go given ahead, for one class of change, until you take it back. Two settings turn it on: git.push: standing in config.yml, and one line in team.md’s Gates that /gtm:tune standing go docs <regex> writes on your answer to its card (/gtm:tune standing go off removes it). Under it, /gtm:ship pushes nothing: when every changed file is in the class and every proof holds, it records a landing that a program of yours reads, checks and merges; otherwise it shows its go card, with the reason. A tag or a release always asks you.

The line has exactly this shape, on one line:

- standing go: <class> · paths `<regex>` · proofs <list> · why: <reason> · <YYYY-MM-DD>

<list> is exactly the proofs the class requires, in this order, separated by , . The <regex> holds no backtick and can only narrow the class. A line one character off, a regex that fails, an unknown class or proof, or two lines for one class: no standing go for that class.

Whatever the line says, no class takes a file on a risky path, and a deleted or renamed file, a link, a submodule or an executable file is never in a class. A class lists what may land, not what may not: a Markdown file outside docs/, README.md included, asks your go. An agent instruction file inside docs/ (a nested CLAUDE.md or AGENTS.md), or a page an agent file imports, can land: if your agents read docs/, narrow the line’s regex to the folders they do not.

The landing is .gtm/reports/<slug>/landing.json, also shown as landing in state.json: {class, head, proofs}, head the full sha of the commit it holds for, proofs one {name, result} per proof: paths, clean, the class’s list, then footprint in stealth. state.json shows it only while the same check, run again, still gives it: a new commit, an uncommitted change or a changed line ends it, and the next check deletes a refused one. git.base counts only as a local branch name. paths holds against that local branch only, which any session can move or merge into. GTM records a landing only on the branch state.json names for its slug, <type>/<slug> in letters, digits and ._/-, and refuses any other.

GTM cannot prove that you wrote the line, nor the CI. Your program keeps a fingerprint of each line you sign, outside the repository: the line’s bytes from - to its last character, line end excluded. Any change to it, its proofs, reason and date included, is a new line to sign. Your program refuses a landing whose line differs, that names a class or a proof it does not know, or whose due proofs it cannot check. Before it merges exactly head, it checks the head and the CI again, and diffs head against the branch it merges into, not against the base GTM read, in a clone that fetched the branch over a transport (git clone --no-local, or a fetch from your remote). It never diffs in this repository or a plain local clone, which shares its objects and commit-graph: a session can rewrite either to hide a change from the diff.