Your agents forget.
Your repo won't.

Your agent proposes how sure each change must be, waits for your yes, and writes it down for tomorrow's agent.

Read the docs first

Every change runs seven steps. You choose how deep.

A mode is how sure a change must be, and the choice is yours: quick, regular or careful. Every change then runs the line: the same seven steps, from frame to close. The mode sets how deep each step goes: skipped, done by the working agent, or handed to a fresh agent that never saw its reasoning.

  1. propose · wait

  2. frame

    inlinewrittenwritten

  3. plan

    inlinewrittenwritten

  4. anticipate

    skippedskippedindependent 1 agent

  5. build

    inlinewrittenwritten

  6. review

    skippedindependent 1 agentindependent 2 agents

  7. verify

    inlinewrittenindependent 1 agent

  8. a finding or a failed check sends the work back to the step it affects

  9. close

    inlinewrittenwritten

  10. the change record

How deep a step runs

none
skipped, its section says so
inline
one line, by the working agent
written
a section, by the working agent
independent
a report, by a fresh agent
How deep each step runs in each mode
Stepquickregularcareful
frameinlinewrittenwritten
planinlinewrittenwritten
anticipateskippedskippedindependent, 1 agent
buildinlinewrittenwritten
reviewskippedindependent, 1 agentindependent, 2 agents
verifyinlinewrittenindependent, 1 agent
closeinlinewrittenwritten
The line starts with the wait: the agent proposes a mode, and by default nothing moves until you answer.

Every change leaves one record.

The change record is one Markdown file in your repo. The agent opens it before the first edit. It says why the change was made, what each step did and how the work was checked. If the work stops, the record says where to pick it up. A folder of the same name sits beside the record, holding each fresh agent's report and the facts of every check run through greenline check.

An example

---
mode: regular
choice: accepted
why: "Keep the caller's deadline across retries."
state: done
next: none
reviewed: independent
agents: 2
rounds: 1
starts: ["review 1"]
---

An example change record, for the change on the guide's pipeline page; no workspace holds it.

While a change is stopped, this line names the step reached and the action that resumes it. A finished change, like this one, says none.

frame

Retries reset the deadline; the caller's deadline must hold for the whole call.

plan

Carry the deadline in the retry context and stop retrying once it passes.

anticipate

none at regular

build

The context now holds the deadline; a test covers three retries.

review

FindingSeverityWhat was done
The last retry could start after the deadline.majorFixed: each attempt checks the time first.

At regular, a fresh agent does the review. This section links its report and says what was done about each finding.

verify

The suite passed on the final code through greenline check: the three-retry test and the two-second deadline test pass, and no other test changed.

greenline check records each check's command, commit and outcome beside the record. No output is stored.

close

Done in two commits, each with the trailer Greenline-Change: 2026-10-08-retry-deadline. One fix round was used.

This example follows the skeleton greenline installs for a regular change, so its shape is the real one. Its content is the pipeline guide's example, carried through to its close.

Watch the agent wait.

In each session below, the agent edits nothing until you answer its proposal. After your yes, every step it runs goes into a record in the repo, so tomorrow's session reads the files, not the chat.

example session
$ cd ~/tracker
$ npx greenline init
Workspace initialized. ok
Youthe sidebar says "1 issues". fix the plural
ClaudeA one-line fix with nothing left to decide, so I'd run it in quick mode: 1 agent, 0 fix rounds, no review. Nothing in it calls for more care, though I can start a second agent if you'd rather have regular. I'll wait for your answer.
Youyes
+ .greenline/ledger/2026-10-09-issue-plural.md mode: quick (accepted)
ClaudeFrame: the label says "1 issues" when the count is one. Only that label changes.
ClaudePlan: pick the noun from the count, and test 0, 1 and 2.
ClaudeBuild: the label now picks "issue" or "issues", with a test for 0, 1 and 2.
ClaudeVerify: I ran the test through greenline check. It fails without the fix and passes with it.
ClaudeClose: the record holds all five steps that quick runs, and the commit carries the record's id.
$ greenline status --change 2026-10-09-issue-plural
greenline status
change 2026-10-09-issue-plural (.greenline/ledger/2026-10-09-issue-plural.md)
mode: quick (accepted)
why: The sidebar says 1 issues when the count is one.
state: done
next: none
step reached: none
review depth: none
cost: 1 agent, 0 rounds
1 commit, 2 files
e6b337257c69
files: label.js, label.test.mjs
checks:
node label.test.mjs (step verify): passed, exit 0, started 2026-10-10T04:38:05.179Z, latest of 2 runs
ran on the final code
findings: 0; notices: 0
ok
Codex and Claude Code follow the same steps and write the same kind of record. Neither remembers the session; the record stays in your repo.

Every borrowed sentence is accounted for.

greenline's 37 skills are the written methods your agent follows. Of those, 33 are built from the text of 13 open-source projects, all under the MIT licence and credited by name on the skills pages. greenline wrote the other four itself. Each skill's page shows the text as installed, where every passage came from, and the reason for every edit and every sentence left out.

See where each skill came from

No customers to quote yet. The proof on offer is the text: each borrowed passage beside its source's own file, at the commit it was taken from.

Settled ground stays settled.

When a change settles something lasting, the close step records it as a ruling in your repository's decisions book. The next agent reads that book before it reopens anything. greenline keeps a book of its own the same way. When it replaces a ruling, the old one stays on the page, marked as replaced. Three of its rulings, word for word:

GD-13

Current policy, from ADR 0038 and the move of guidance to garden on 2026-09-26: installed skills and local diagnostics work offline.

GD-02 Historical; superseded by GD-13

Everything is Markdown a person can open and read raw. The files are the state; Git is the history.

GD-11

Before v1 there is no backwards compatibility.

Read the whole book

Questions before you run it

What does it mean for an agent to carry a project?

It means the work outlives the chat: the project keeps why each change was made, what it did and how it was checked. Today most of that lives in a chat window and is gone when the chat ends. greenline has the agent write each change into a record in your repository, so the next session starts from that record, not from an empty chat.

Which projects is it for?

A project with a second day and a second contributor, where being careful is the point. The practice costs agent time: by default every change waits for your yes, runs its steps and is written down. What that buys is a repository a teammate can clone and pick up, with every change's reason and every check on record. A toy built in an afternoon is not its case; there the cost buys little.

What does "the agent proposes a mode" mean?

A mode is how sure a change must be, and there are three: quick, regular and careful. Before any edit, the agent proposes one, says why and what it costs in agents and fix rounds, and waits. You say yes or name another mode, and your answer is final. For a change that touches secrets or security, a data migration, concurrency, a public contract (an interface others rely on) or behaviour no check could catch, it proposes careful.

Do I have to change how I work?

A little. You keep your editor and your agent, and the agent writes the records as it works. Git gains a few rules: greenline's git hooks refuse a commit that no open change record allows, and a rewrite or a push its record has not cleared, and each refusal says why. You run three commands when you want them: greenline status shows where every change stands, greenline sync brings the installed files up to date and greenline inspect lets you read and edit the repository's settings in your browser. If you would rather not wait for every proposal, one setting lets the agent go ahead at a mode you choose and every faster one.

Does any of my code leave my machine?

No code or repository policy is uploaded. Your agent still talks to its own model, as it does today, and greenline adds no telemetry. greenline's one door out is garden's connector: it sends labels for what a question needs, never your code, and stays off until you enable it. Without it, skills work locally.

What is installed into Codex and Claude Code?

greenline's roster is 37 skills, the written methods your agent follows. They come in three kinds: the seven steps of the line, 12 starts the agent picks from how a request begins, and 18 habits that load when their situation comes up. Most install by default; extras install only when you name them, and trials, which are new methods, only where you turn them on. Guidance, the engineering knowledge garden maintains, stays garden's, with no guidance body or service in the package and no library saved locally.

What happens when the session dies mid-project?

Nothing written down is lost: the change's record is in your repository, and its "next" line says where to pick up. Ask a fresh session "what were we doing?" and it reads the open records, then tells you where each change stands and what comes next. Or run greenline status --change with the record's id to see the same thing yourself.

Start in your repository.

Run it in any Git repository. It needs no account, no key and no service. greenline shares its engineering methods across Codex and Claude Code.

The git hooks run greenline from your PATH, so install it there too: npm install --global greenline.

Skills work locally; guidance is an optional connector.