MichaelTarasov02/Trail

Trail は何をしますか？

Git versions the code. This versions the reasoning.

One entry point. Say what you want in plain words, or say nothing and get the state of this repository plus the next sensible step.

Language

Answer in the language the person asked in. The files you write follow the repository's own language, detected from its commit history — those are read by the team, not by the asker.

What this is, in sixty seconds

Somebody asks an agent for a change. The agent proposes something. The person says "no, not like that". The agent adjusts, and the work ships.

Git keeps the last step and throws away the other three. The diff survives forever; the reason it looks like that, the alternative that was rejected, and the correction that produced it are gone when the session closes. Six months later git blame names a commit and a date, and nobody can say why the obvious approach was not taken — so somebody takes it, and rediscovers the reason at full price.

A trail is four things per session, and nothing else:

DECIDED	a choice where a competent alternative existed — and whose choice it was
REJECTED	what was seriously considered and dropped, which leaves no other trace
CORRECTION	where the operator changed the direction, in their own words
ASSUMED	what was taken on faith, and what being wrong would cost

Everything testable against one question: could git log -p tell the reader this? If yes, it does not belong.

The part people underestimate

Every decision carries its source — [operator], [agent] or [project].

Work done with an AI is full of choices nobody consciously made: the model picked something reasonable, nobody objected, and it became the design. Those are [agent] decisions, and marking them is what lets a reviewer find them later.

Measured on the first real trail this tool produced, across two sessions: seven [agent], three [project], two [operator]. In the commit messages for those sessions all twelve look equally deliberate.

First: where is this repository

git rev-parse --show-toplevel 2>/dev/null || echo "NOT A GIT REPOSITORY"
[ -f .trail/config.yaml ] && echo "trail: set up" || echo "trail: not set up"
find .trail/entries -name '*.md' 2>/dev/null | wc -l
grep -rl 'Trail — decision record' CLAUDE.md AGENTS.md 2>/dev/null || echo "bootstrap: absent"

Use find, not a glob. In zsh an unmatched *.md is an error raised by the shell before the command runs, so 2>/dev/null does not suppress it — and the noise appears on exactly the repositories where the answer is "nothing here yet", which is the first impression a new user gets. Found by running this on a repository with no trail.

Report the four lines, then route:

State	Say
Not a git repository	trail anchors entries to commits; without git it still works but the entries are worth much less — offer, do not insist
Not set up	offer setup in one line and do it on a yes — see below
Set up, no entries	explain what the first trail-record will produce, and offer to run it now against recent commits
Set up, entries exist	show the last two, the source ratio, and what is open

Setup — one run per repository, and then it is automatic

Read references/bootstrap.md before setting anything up.

This is the step that matters most and is easiest to skip. Setup does two things:

1. Creates .trail/ — config, index, an empty entries/
2. Writes a short block into the repository's agent-rules file — CLAUDE.md, AGENTS.md, or whichever the repository already uses

The second is the whole point. That file is loaded by every future session automatically, so the trail gets maintained whether or not anyone remembers this skill exists, and whether or not it is installed. The block carries the entry format inline, so a teammate who clones the repository and has never heard of this tool still writes correct entries.

A tool that only works when you remember to invoke it is a tool that stops being used in about two weeks. This is the answer to that.

Show the block before writing it, and never write it without a yes — project rules change how every future session behaves.

Routing

They want	Skill
To write down what just happened	trail-record
To know why some code is the way it is, or whether an idea was already rejected	trail-why
To turn repeated corrections into project rules	trail-distil
To understand the idea, or to start	this skill

Route by reading the sub-skill, not by dispatching a subagent. The sub-skill needs the conversation you are in — what was asked, what was corrected, what you decided. A subagent gets none of that and produces a record of nothing.

Where the request is plainly one of the three, go straight there and say which you are using. Explaining the routing to someone who asked a direct question is overhead.

What to tell a person who has never used this

Three sentences, in this order, and then stop:

1. Git tells you what changed; this tells you why, whose call it was, and what was rejected.
2. Run it once per repository — after that every session keeps the trail on its own.
3. When you inherit unfamiliar code, ask it why before you change anything.

Do not explain the file format unprompted. People adopt this because of the question it answers, not because of a markdown schema.

Non-goals

• Committing, pushing, or opening anything.
• Editing the agent-rules file without approval.
• Replacing commit messages, code review, or an architecture decision record. It records what those three all omit.
• Recording everything. Four kinds of thing qualify; the rest is narration.