Positions

1. Light over complete

The smallest process that keeps quality: three sizes of change, few files, short pages. Every extra document is read by someone, or ignored, and both cost. Templates skip what a size does not need, and there is no requirements or architecture document unless a decision demands one.

Cost: some decisions are made in a plan rather than in an architecture document of their own.

2. Three checkpoints

For each Feature you approve the mockups, approve the Summary and give the go; these are its checkpoints. Everything else is settled inside the team and listed as decisions made for you, and kept in the logbook. The decisions that are yours are few; buried among status updates, they get lost.

Cost: the team will sometimes decide as you would not have; the list and the logbook make that cheap to overturn.

3. Evidence before claims

No “done”, “fixed” or “passing” without the command and its result, and what was not checked is said plainly. Agents never claim a check they did not run, reviewers cite file and line, and the final review runs the checks again. A confident claim without evidence is the dearest error to find later.

Cost: reports run slightly longer, and checks take time.

4. Tests first

A failing test comes before the code, and every acceptance line of the spec has its test. The failing run proves the test can fail, and acceptance lines written in a fixed form turn the spec into tests directly. The implementer’s method, the reviewer’s checks and guidelines/tests.md hold to it.

Cost: slower first commits on exploratory work.

5. Verdicts in your chat, reports on disk

Agents receive paths to files and answer in ten lines at most; their full reports live on disk, and the workflows keep intermediate results in their own variables. Your conversation holds verdicts, not transcripts, which saves context and usage.

Cost: one more report file per task in the project's .gtm/ folder.

6. Specialists only where they matter

Security, data and screen reviewers run only when a change touches their ground, decided by path patterns your project owns in team.md. A specialist on every task is expensive noise; a specialist missing on the task that needed it is a hole. Path rules make the choice explicit and open to review.

Cost: a path rule that is too narrow misses a change; a tune of the settings catches it, and so does the final review on a branch that has one.

7. One strong model, effort by role

By default every role runs the strongest model, and roles differ by how hard they think: high where a miss is costly, such as security and the final review, one level more on risky paths, low where the plan carries the thinking, such as implementation. Mixing models adds ways to fail; effort is the cheaper and more predictable lever.

Cost: a higher price per token than a mixed fleet on simple tasks.

8. Your priorities, recorded and revisited

How much security, data integrity, screens, performance, speed and cost matter is decided per project at /gtm:init, written down once with reasons and dates, and revisited with evidence through /gtm:tune. A banking backend and a weekend prototype should not run the same team, and nobody should restate their priorities every session.

Cost: a few minutes at the start, and settings that drift if never revisited.

9. Security and data integrity come first

An insecure or data-losing change never ships, whatever the size or the deadline: these failures cannot be apologised away or rolled back. A schema, migration or sign-in change is a Feature from the start, the security and data reviewers check every change on their ground, their findings always block the task, and the final review reads security and data first.

Cost: specialist reviews at a high effort, the security and final reviews a level higher on risky paths, and now and then a blocked task.

10. Nothing pushed, merged or released without your go

Agents never push, merge, tag or release; the main session does it only after your explicit go for that exact action, through /gtm:ship and git.push: ask in the config. Shipping is the decision with consequences outside the repository.

You can also sign the go ahead for one class, docs, with git.push: standing and a line that /gtm:tune writes on your answer: /gtm:ship then pushes nothing and records a landing, which a program of yours checks and merges. A tag or a release always asks.

Cost: one message per branch.

11. Keep history, no squash by default

Merge commits, small logical commits, and pushed history is never rewritten. The history is the record of how a decision was carried out, and bisect needs it. A project may choose squash in git.merge, and the choice is recorded.

Cost: a longer log.

12. Plain language, in your own language

Verdict first, short sentences, no jargon where a plain word exists, in the language you chose; code, commits and docs in the code language. Reading in a second language costs attention, and jargon hides weak reasoning.

Cost: two languages to keep consistent in some projects.

13. Cite sources, credit inspirations

Claims about libraries or behaviour say where they come from, reviewers give file and line, and ideas taken from other methods are credited in Where GTM comes from. That gives you traceability, and it is honest towards the people whose work GTM builds on.

Cost: a line or a link.

14. Accessibility is a rule, not a polish item

Targets, contrast, keyboard access and accessible names are hard rules, and a failure is an important finding. An inaccessible screen is a broken screen for some users, and fixing it late costs more. The design critic measures them and the screen reviewer checks every screen change.

Cost: stricter design rounds and an automated check per screen and theme.

15. GTM serves the project, it does not sign it

What GTM writes into a project belongs to the project and reads in its voice. With stealth on, GTM leaves no trace at all: no files in the tracked tree, no names, no trailers, checked by a scan before every ship. A project’s history and docs are read by its maintainers for years, and a tool’s vocabulary there is noise. Stealth changes what GTM writes, not the rules an organisation or a project sets on AI tools and disclosure: follow those.

Cost: with stealth on, the team's memory stays on one machine and teammates do not inherit it, and the scan before shipping can stop on a false alarm.