Release notes

0.1.0 · 2026-10-21

greenline 0.1.0 installs a practice into a Git repository for Codex and Claude Code: a managed instruction block in AGENTS.md and CLAUDE.md, a roster of skills by kind, steps, starts and habits, one change record per change and git hooks that hold the record's promises, with no account, no key and no service. Before any edit the agent proposes one of three modes, quick, regular or careful, with its cost, and waits for your answer; every change, in every mode, leaves one record of why, what and how, its checks recorded and its commits traced to it; the hooks hold the workspace before its first record as after, and a standing choice is your yes only where your proceed setting allows the mode. It is made for a project with a second day and a second contributor, where being careful is the point: the practice costs agent time and buys a repository a teammate can clone and resume, and a toy built in an afternoon is not its case.

A workspace made with 0.0.1 moves to 0.1.0 with no converter: follow the remedies below, the lock's first.

Offline by default, garden optional

• A greenline install needs no account, no key and no service, and works offline with every method it carries. The guidance that was built in moves to garden, a separate product of maintained engineering knowledge the owner can enable. A fresh install has no maintained knowledge until its owner enables garden.
• greenline connectors list, status, enable garden --url URL [--executable PATH] and disable garden manage the optional garden connector offline. Enabling writes the connector's entry to the manifest, installs the use-garden skill and adds its line to the managed block, in one change; disabling removes the three and keeps receipts and your text. greenline never installs, runs or contacts garden to enable it, and stores no credential.
• greenline connectors call garden OPERATION [--change ID] runs one of garden's six reads through the separately installed garden command, with literal arguments and no shell, and records the call before any result is shown. With --change the request belongs to that change, whose record must parse and be open or stopped; without it the request is a question's, owned by no one.
• greenline status reports each connector's state offline: for an enabled garden, the endpoint, the executable that would run and whether GARDEN_API_KEY is set, with a GL0125 warning when the executable would not run or the key is not set, never starting garden or reading the key.
• greenline inspect shows each consultation's receipt: its publication and every call's operation, outcome and units, never a unit's text. The package carries the licence of the Geist fonts the inspector embeds, assets/inspect-fonts/OFL.txt.

The modes and the proposal

• Three modes, quick, regular and careful, each keeping the whole change record; the block cut to under 1,500 words, with each skill's source text in front and greenline's mechanics in its references; the promises held by git hooks and one lean harness adapter; the record checks on the record's own facts alone.
• Each mode is a promise about time and assurance, and the three stand in a table in the managed block with the agents and rounds each may use and the depth at which each step runs: quick the builder alone, regular one fresh reviewer and one fix pass with the builder's written verify, careful the premise attacked by a fresh agent before the build, two reviewers and a fresh verifier. Every mode keeps every section of the record, a step it does not run holding the one line none at <mode>. The block, under 1,500 words, carries the loop, the promises one line each, each naming the mechanism that holds it where one does, the mode table and an index of what to read when each situation arises. The block calls itself the practice and never calls itself by the CLI's name to you; a command is quoted as it stands.
• A mode's agents are derived from its depths, the builder counted, and the mode table shows them: careful may start five, the builder, the premise reader, two reviewers and a verifier. The fix rounds are per step, one pass after review's findings and one after verify's at regular and up to two at careful, and greenline status judges a record's cost against its mode.
• Before its first proposal in a session the agent reads the situation greenline status prints, and a first request for a change in a repository with no change record on any branch is the orientation: groundwork on an empty tree, its own change before a feature request or the request's own when it asks for setup, otherwise a survey of the existing documents, its result written into the knowledge homes. The agent reads a skill's reference page when its SKILL.md sends it there.
• Before any edit the agent proposes a mode with its reason, its cost in agents and rounds, any floor or risk it found and whether it can start a second agent, then waits. Your choice is final, and a mode you name above the proposal has its cost restated before the work. The agent goes on without a yes in three cases only: the request names the mode, its words say to implement without asking, or the proceed setting allows the mode; the proposal still comes before the first edit, stating the mode as taken with its reason and where, and asks only a choice the request leaves open.
• A floor, secrets or security, a data migration, concurrency, a public contract or a behavior change no check could catch, raises the proposal to careful. A mode you named stays as named and a later floor is reported; under a proposal you accepted, the agent proposes the raise and waits again. The record names every floor found, and where you name a mode below one it says choice: owner with the mode proposed and the floor's reason.
• Work split into tickets waits twice: for the planning change's mode, unless the request names it, and on the ticket list with a mode beside each ticket. A mode you name at the list edits the ticket's entry; one you name as a ticket opens overrides it for that ticket, recorded as your choice.
• Agents run one after another in the change's one checkout, never in parallel and never in a worktree of their own. Every fresh agent gets one brief, delegates nothing and writes <step>-<n>.md in the change's folder; anticipate's report has four parts, and verify's verdicts stand. The builder reads the reviewer's brief only where review runs inline; at the independent depth the reviewers alone read it. Where the harness has no delegation, every depth above written runs without a fresh agent, and the step's section records the limit.
• The proposal also says where the change's commits will go, read from the repository's local setup with no network command: the current branch when it is not the default branch or the repository has no remote, otherwise a new branch greenline/<id>, and on a detached HEAD it names none and asks; your answer is final. A plan's tickets share the planning change's branch, and a worktree holds the change's checkout only when you ask for one and your harness runs the session in it. The close step offers the landing in one line, a push and a pull request where the remote is a forge, a local merge where no remote is a forge, or the branch left, each done only on your word. Before a local merge it names the base branch, makes the merge with its commit and then runs the change's checks on the merged result, so their facts name the merge; a red result stops the landing, keeps the change open and leaves the merge local for you to keep or undo.
• Where a repository's own rule pulls against the where line or the landing offer, such as a rule against merging one's own branch, the agent names the rule beside its proposal and beside the offer, and you decide; the setup still decides what is offered. Where the rule forbids committing on the branch the setup gives and the request names none, the agent asks which, recommending greenline/<id>, and never commits where the rule forbids.
• The skills and the guide say what the owner's yes is: the record's choice line written after the proposal, never a request to commit, to go ahead or to implement without asking. The setup change's record opens before its commit, a decision or a term written into the knowledge homes opens a quick record first, a trailer-shaped line of another key is no answer to a hook's refusal, a change's scratch stays under its own id, and the quickstart says Codex runs a project's hooks only once you trust its .codex layer.

The change record

• Every change has one record, .greenline/ledger/<id>.md, opened before the first edit from the skeleton for its mode in .greenline/ledger/README.md: the mode and how it was chosen (owner, accepted or standing), why, the state (open, stopped, done or dropped), the "next" line that resumes it, and one section per step the mode runs. One session writes it at a time, so a session that resumes a stopped change writes on in it.
• A change's folder, .greenline/ledger/<id>/, holds the reports of the fresh agents it cites, the briefs greenline brief wrote and, under checks/, the facts of every check. Every commit of a change carries the trailer Greenline-Change: <id> from the moment it is made, as the last line of the message's last paragraph beside any trailer the harness adds there, and no commit is reset, amended or rewritten to move it.
• A change is open while a session holds it, a wait for your answer within the session included, and stopped only when the session leaves it unfinished, with its "next" line; resuming sets it open again before any edit, and a request for another change stops the open change first. A reviewer's and a verifier's brief is the file greenline brief writes into the change's folder, never the builder's; anticipate's brief, a fresh agent's scratch folder and a looped step's relay note are named working files, and a decision or a term written only into the knowledge homes needs no record.
• Every stop commits the record and its folder, the check facts under it, with the change's trailer, so a stopped change is found from any branch or a clone and resumes on the branch that commit sits on. A change's id is chosen with its proposal, and its commits never go to another change's branch, a ticket's going to its planning change's: on another change's branch, the new change takes the default branch where there is no remote, and otherwise greenline/<id> made from it, the default branch read from origin/HEAD, else init.defaultBranch, else the branch HEAD names when it is no change's branch (any greenline/<id>, or another branch a change's proposal named, never the default branch), and with none the agent asks you. A stop's commit holds nothing else: the change's uncommitted edits stay for its resume, working edits you ask to commit are a commit of their own, and a new change is not proposed while the stopped change's edits are in the tree. Where no remote is a forge, the close offers a local merge or the branch left, never a pull request. An agent a step's method starts, such as a research agent, gets the one brief and is counted in no cost.
• .greenline/WORK.md says where a change's files live and how long each lives: the record and its folder, a plan directory .greenline/plans/<NNN-name>/ with one tickets.md and a mode per ticket, the working files under the git-ignored .greenline/tmp/<id>/, the decision home and the glossary.
• The glossary home is now GLOSSARY.md, with GLOSSARY-MAP.md for several contexts; a repository that already keeps a CONTEXT.md keeps it as its glossary.
• The close records done only on green checks, with probes run apart, and keeps the change's trailer with the commit it belongs to; a wait is no stop; a named mode needs no yes and the record names its floor; the builder reads the reviewer's brief at inline only; every check runs through greenline check; starts and habits load only in their situation.
• The reviewer's brief stays out of the builder's hands at the independent depth, every check on a long build runs through greenline check, a fresh agent's scratch stays under the change's folder, a record counts every agent started, and greenline status lists the newest finished changes first.
• A workspace may delete .greenline/work/ and .greenline/ledger/records/, which nothing reads any more, and each receipt collection of schema 4 or owned by an account, which greenline status reports as GL0401 until it is deleted. The installed files of the retired skills are orphans that greenline sync reports; remove them with greenline sync --force-managed <path>.

The roster by kind

• Thirty-seven skills in three kinds. The seven steps run where the mode reaches them: frame, plan, anticipate, build, review, verify and close. The starts are chosen from the situation a request begins in: router, what-to-build, wayfinder, diagnose, architecture-survey, sweep-tests and groundwork. The habits load only when their situation arises: tdd, ponytail, deep-modules, boundaries, domain-and-types, concurrency, secrets, prose, show-me, progress-check and, with garden enabled, use-garden.
• The block lists the roster by kind: the steps in the line's order under the mode table, the starts by situation and the habits by situation, each kind introduced once.
• A start loads only at the orientation, in its row's situation or when you name it, and a habit only in its row's situation: architecture-survey is never an orientation where a change record exists, secrets loads only with a secret in reach and ponytail for code the request leaves open. A record names a start only when it ran. The survey keeps its report in the working files and never opens it; with nothing to resume, router says so and asks for the request; diagnose ranks its hypotheses before its first probe; ponytail builds only on a measured need.
• Three extras install only when skills.include names them: diagram-design, architecture-map and product-description, which is now an extra too.
• Nine trials install only where trials names them: the starts idea-refine, constraint-driven-development, correct and improve-instructions; and the habits build-the-lever, guard-the-context-window, pr-writing, to-questionnaire and benchmark-checklist. No step is a trial: anticipate is careful's premise review.
• The new skills replace the old roster: grilling, grill-with-docs, research and prototype are in frame; to-spec and to-tickets in plan; implement in build; delivery-review, review-lens and ponytail-review in review; verify-this, control-cli and control-ui in verify; record-architecture-decisions in close, and domain-modeling split, its questioning into frame and its glossary into close; project-router is router, diagnosing-bugs is diagnose, improve-codebase-architecture is architecture-survey, codebase-design is deep-modules, model-the-domain and type-system-discipline are domain-and-types, boundary-discipline and fail-loud are boundaries, concurrency-method is concurrency, airgap-secrets is secrets, and answer-plainly, unslop and technical-writing are prose. A skills.exclude naming an old name must name the new one, since sync refuses a skill the roster does not hold.
• Every skill's SKILL.md is its front, the method in its sources' own words as its recipe cuts and merges them, and a step's references/greenline.md holds greenline's mechanics for it: where its work lands in the record, its section's form at each mode's depth and the commands it runs. frame's interview, read only at careful, is in references/interview.md, and review's start of the fresh reviewers, read at the independent depth, is in references/reviewers.md. At careful frame puts every open behaviour to you through the interview, at regular it answers the open questions from the repository for you to correct, and an inline frame line credits you only with a choice you made. verify runs a baseline in a copy of the earlier commit, never over the change's working tree.
• The frame and review steps and the constraint-driven-development start are corrected: the floor guard passes the change that introduces it, the reviewer's brief is a page of its own, and frame says where a start's four answers go.
• Four skills of obra/superpowers were read whole for the roster. Finishing a development branch joins the close step's landing: the base branch named before a local merge, the change's checks run on the merged result through greenline check, a red result stopping the landing with the merge left local, and a rejected push never forced. Parallel dispatch, subagent-driven development and an agent's own worktree are not taken, since the practice runs one agent at a time, the builder builds, and every agent works in the change's one checkout.
• The skill classes are gone; each skill's activation follows its kind unless its entry states the other, and agents/openai.yaml lists each skill's kind.

The two settings

• .greenline/manifest.json gains proceed, none by default or a mode at which the agent goes on without waiting for that mode and every faster one, and trials, the trial skills the workspace enabled, none by default. greenline init writes both, greenline sync keeps them, and greenline inspect edits them. A value that is not a mode or a trial skill is refused by name, and a proceed naming a retired mode is set again by the owner.

The commands

• greenline guidance, greenline doctor and greenline evidence are removed: each is now an unknown command, refused with exit 2 and a message naming the commands. The guidance client and the provider setting are gone with them.
• greenline status is the one diagnosis. It checks the manifest, the decision book, the lock, an AGENTS.override.md and the installed files against what the settings generate, reports the connectors, and shows the changes: the open and stopped ones and the ten most recently closed, newest first (--all for every finished one), each with its mode and how it was chosen, its raises, the step reached, its commits and files and whether its checks passed on the final code; each plan's tickets and the ready frontier; and totals by mode, choice, raise and cost. --change ID is one change's resume view, with the briefs greenline brief wrote and, for an open change, the commits of code since its last recorded check. Findings (GL0401 to GL0409) fail the command and notices (GL0451, GL0452, GL0455, GL0456 and GL0459) never do, each code reading a record field or a durable fact of the repository; a nudge, a line with no code, marks what a mechanism holds or no record fact settles; a done record is judged while its latest check ran under the current installation, and after an update, or with no check, it is history read for its form alone. It writes nothing. The typed work artifacts, the execution accounts and their diagnostics (GL0121, GL0201 to GL0210, GL0301 to GL0306) are gone, and the JSON reply carries no view or ledger.
• greenline status opens with the situation: the commits and the branch, how many change records exist, the knowledge homes found, the languages at the roots and the changes stopped on other local greenline/* branches, read with git read-only and carried as situation in the JSON. Each open or stopped change shows its "next" line beside its state. A ticket's record opened under another mode than its tickets.md entry (GL0406) and a planning change below careful (GL0407) are findings, whose remedies keep your choice under choice: owner; a finished change's working files left in .greenline/tmp/<id>/, a done planning change the decisions book does not name and a mode taken without waiting that proceed does not allow are nudges, and the history line names the first five commits with no trailer by their short hash and counts the rest.
• greenline check [--change ID] [--step STEP [--round N]] -- COMMAND... runs one repository command for a change, its short form greenline check -- COMMAND... taking the one open change and the step its record is in, at the repository root, or in the directory of the declared check it matches, with no shell, and exits with the command's own code. Its output is shown and never stored; one facts file per run holds the arguments as given, the outcome, the duration, the commit, the tree id of the code outside .greenline/ and the installation's revision. A secret passed as an argument would be stored, so never pass one. It refuses, running and writing nothing, when the change is unclear or has no record, or the step, the command or its executable is not there. A command run without check leaves no facts and is not evidence. Every check of a change's code runs through it, its red runs, a rerun made only to read a failure and a reviewer's included, and a fresh agent's --round runs its command with TMPDIR set to that agent's scratch folder; a probe, a run whose green the change never claims, runs outside it. A fact is never written over or removed: each names the one before it, a fact found missing is the notice GL0459, and greenline check --change <id> --probe <fact> marks a run recorded by mistake as a probe.
• greenline brief --change ID --step review|verify --round N [--axis standards|spec] [--intent PARAGRAPH] writes a reviewer's or a verifier's brief from the change's record into its folder, .greenline/ledger/<id>/brief-<step>-<n>.md, its first line the command's mark, creates the agent's scratch folder and prints the brief's path; it never writes over a brief. greenline status reports a brief file the command did not write (GL0408), and a record whose agents counts fewer than the builder and the fresh agents its starts names (GL0409).
• greenline tidy [--change ID] removes the working files of done and dropped changes, and the close step runs it for its change at every close, the quick mode's included. It removes nothing outside .greenline/tmp/, never a folder a file of the ledger links into nor an open or stopped change's; a folder it keeps when --change named it, or a finished change's it cannot remove safely, is a GL0470 error.
• greenline init on a directory that is no Git repository asks whether to run git init there; --yes answers yes, and a no stops init with nothing written.
• Outside a Git repository, greenline init, greenline sync and the connectors' list, status, enable and disable refuse with words for the owner's decision: the agent offers git init and waits, and greenline init --yes runs it only as the owner's answer; nothing is initialised on the agent's own initiative.
• greenline connectors call takes --change alone: --record and --context are unknown options.
• greenline inspect renders the change records, their folders and reports, the plans with their tickets and the knowledge homes, each from its shape, beside the checks and receipts it already shows.

The hooks and the declared checks

• greenline init writes git hooks under .greenline/hooks/ and registers them in the repository's local configuration, as config-based hooks on git 2.54 or later, which run beside your own, and through core.hooksPath on an older git with no hooks of its own; on an older git holding your hooks or a hook manager's path it registers nothing and prints the line to add. greenline sync refreshes them and registers them in a clone. On a change's branch they write the change's trailer into every commit, --no-verify included, and refuse a message carrying another change's; refuse a commit before the record's choice line, your answer to the proposal; refuse a commit that sets the record done while the latest recorded run of a check is red, unfinished or absent; refuse an amend, a reset, a rebase or a forced move of the branch unless the record's rebase line holds your words; and refuse a push while the record has no landing line, and a force push always. Each refusal names the record fact it rests on, and a hook's own error never blocks git.
• greenline event --harness NAME is the one command every harness adapter runs, the harness's event on its input: it records the event in the change's raw log, prints the status mirror into the agent's context at a session's start and at each request, records a command whose text is a declared check's as that check's run, which the close never counts, and refuses one act, a write outside the ledger and the change's working folder before the record's choice. Init writes the adapter of Claude Code and Codex, and of Droid, Gemini, Cursor, OpenCode, Amp, Pi, Kiro and Copilot where the repository shows them, each entry the same command, merged beside your own; for Hermes and dsh it prints the lines to add. It exits 0 on its own error, so greenline never stops a tool by failing.
• greenline hook NAME is what each git hook's script runs; it reads only git's facts, the record's front matter and the check facts.
• The manifest's checks declares the project's checks, each a name, a command and a directory: greenline init proposes them from the project's own files and prints them, the agent confirms or corrects them in the first change, and greenline check --declare [--name NAME] [--dir DIR] -- COMMAND... adds one, running nothing. No hook parses a command; with none declared, greenline status says so.
• Every finding code greenline status emits reads a record field or a durable fact of the repository and serves one sentence of the block or an installed page; GL0453, GL0454, GL0457 and GL0458, which judged what a mechanism now holds or no record fact settles, are nudges and are never reused. The change record's front matter gains landing and rebase, your words for a push and for a rewrite of the change's branch.
• The git hooks hold a change on the default branch when the repository has no remote, the setup change commits the installed practice, a frame question goes in the reply that ends the turn, a declared check runs in its directory, the trailer write reports its failure, and greenline status says when greenline is not on the PATH.
• The git hooks and the harness hook hold a greenline workspace while no change is open: a commit on a branch with no open change and a write outside the record homes before any record are refused, and a standing choice counts as the owner's yes only where the proceed setting admits the mode.

Schemas and the lock

• The workspace manifest is schema 6 with no guidance field, and with checks, the project's declared checks, and hooks, which turns the git hooks and the harness adapters on or off; the receipt collection is schema 5, owned by a change or no one, with the source garden and the connector's error kinds (missing-executable, cancelled, deadline, output-cap, process, protocol, or garden's own refusal).
• The modes definition the package carries, corpus/runtime/modes.json, is schema 5: it declares the kinds step, start and habit, each with its mechanism, its contract and when it applies; gives each mode a words budget, the most words an agent reads at that mode and a ceiling greenline's own checks hold and never raise, 9500 for quick, 10400 for regular and 11700 for careful; derives each mode's agents from its depths in place of stating them; says which steps take a fix pass; and marks no step a trial. An earlier schema is refused by its version.
• The corpus manifest is schema 11: each skill states its kind, a step skill its slot, and the flags extra and trial only when true. An earlier schema is refused by its version.
• The lock, .greenline/lock.json, is schema 5 and names the pinned sources sources. greenline sync refuses a schema 4 lock with GL0104, "unsupported lock schema version '4' (expected 5)", and changes nothing. The remedy: delete .greenline/lock.json and run greenline sync, which rebuilds it and names as a conflict any installed file whose bytes differ, for --force-managed <path> to overwrite.

The public source

• Every roster skill is defined by a recipe that takes its sources' text sentence by sentence, with a reason for every edit and every dropped sentence, and a skill may combine several sources. node scripts/corpus.mjs renders and verifies each skill's files from its recipe byte for byte, measures how much upstream text survives exactly, records every change and every source read in a new ledger chain, and renders the ledger's index, the line view, the sources register and the notices; its refresh, intake and budget verbs move a source to a new commit with nothing taken unread, compare a candidate with the roster, and total each mode's words against its budget. The per-skill PROVENANCE.md pages and the old ledger are gone, and git keeps them; the package's provenance/ holds the ledger's index alone.
• Two sources join the roster's pins, addyosmani/agent-skills and obra/superpowers, both MIT, and seven others move to their upstream commits of 2026-10-07.

0.0.1 · 2026-08-28

• Commands: npx greenline init initializes a Git repository; greenline sync regenerates managed output; greenline doctor validates the installation and work artifacts; greenline status reports project state from artifact frontmatter. Every command runs offline, supports --json, and sends no telemetry.
• Roster: The full profile installs 38 skills for Codex and Claude Code. The starter profile installs the pipeline and working-law skills.
• Guidance: Installed skills provide local engineering methods. Decisions, specifications, tickets, reviews, and evidence remain as Markdown in the Git repository so another agent or session can continue the work.
• Block: npx greenline init adds a managed instruction block to AGENTS.md and CLAUDE.md. The block carries six working laws for completion, ambiguity, visual explanation, secrets, durable prose, and working preferences.