Estigia

---

estigIA — workflow authority for AI coding agents

Your agent says it claimed the issue, that the review passed, that the branch is current. Estigia turns those sentences into things that were checked: the claim lives in a local store (~/.estigia/state.db), every later write is measured against it, every step that cannot be undone re-verifies it, and a review verdict is bound to exact bytes, so a push invalidates it.

One binary, under whatever agent you already use; it does not run your model. Its only detached processes are a reviewer CLI and the declared checks (which).

*El río del juramento. Lo que un agente promete, queda ligado a unos bytes exactos.*

Leteo is the river of forgetting. Estigia is the river of the oath — the gods swore by its waters, and perjury cost nine years outside Olympus. Two rivers of the same underworld, opposite jobs: one makes you forget, the other holds you to it.

What it feels like

Mostly, nothing: a run that has claimed nothing works as before. When it refuses, it says what it read and what to do about it:

$ git push origin HEAD

estigia: git push: gh issue view failed (1): none of the git remotes ... (read-failed) [world-action] the tracker could not be read; write nothing and retry the read error: failed to push some refs

*The tracker could not be read* is a different answer from *you may not push*, and Estigia will not turn the first into the second. That distinction is most of the design.

FLOW — Focused, Lean, Outcome-driven, Witnessed

FLOW is Estigia's own methodology: how a run takes a piece of work from an issue to a merge.

• Focused: small work stays small. Understood work is done directly, not planned, and exploration is in proportion.
• Lean: one writer, the smallest topology that works, and review only as heavy as the risk.
• Outcome-driven: done means the issue's acceptance criteria hold, with evidence, merged and verified.
• Witnessed: deterministic evidence first, then review by a context that did not write the change, and the merge at the reviewed head.

It rests on two pillars: *the claimed issue is the record of the work*, and *the publication is the review candidate*. Four principles follow from them: small work stays small; review is sized by risk; a review lineage gets a bounded number of corrections (Corrections per lineage, default 3); and the heavyweight two-judge review (Judgment Day) runs only when asked for.

You start it with flow (analyse and build, choosing the next issue from the tracker), flow dev [issue] (build) or flow triage (analyse and file at most one evidenced issue). A run then goes through five steps, which may merge or repeat:

flowchart LR

understand["Understand"] --> route["Route"] --> execute["Execute"] --> verify["Verify"] --> deliver["Deliver"] verify -->|"finding"| execute

Work that spans sessions or divides into units with their own acceptance keeps an ordered checklist on the claimed issue (task), never in a file. FLOW is how a run works; the workflow below is what Estigia enforces while it does.

The workflow

The workflow is the part a run cannot talk its way around: the states an issue moves through and the checks at each boundary. FLOW runs inside it.

flowchart TD

analysis(["analysis"]) --> ready(["ready"]) ready --> claim["claim"] claim --> inprogress(["in-progress"]) inprogress -.-> blocked(["blocked"]) blocked -.-> inprogress inprogress --> publish["publish"] publish --> review(["review by risk tier"]) review --> verdict["verdict on exact bytes"] verdict -->|"push: republish"| publish verdict --> deliver["deliver"] deliver -->|"approved"| release["release"] release --> done(["done"]) deliver -.->|"needs a person"| person["hand-back"] person -.-> deliver

classDef state fill:none,stroke:gray,stroke-width:2px classDef action fill:none,stroke:gray,stroke-dasharray:4 3 class analysis,ready,inprogress,blocked,review,done state class claim,publish,verdict,deliver,person,release action

Rounded nodes are states, square nodes are actions; dotted edges are the exceptions. What the gate holds at each boundary:

• One state at a time, in the local store; labels are a projection, written and read back. blocked names an exact exit condition and who discharges it.
• A claim before the first write. The earliest live claim wins, and the gate re-verifies it on every write it sees and at every irreversible step.
• A verdict bound to exact bytes — epoch, head, base and digest. Any push invalidates it: republish and ask again. A body says Refs # , never a closing keyword.
• Release last, after the evidence is posted (details).

The contract an agent reads is skill/SKILL.md; the GitHub half is delivery.md; review cost per tier is in review-cost.md.

Install

Pick one route. Each is copy-paste.

Linux, macOS:

curl -fsSL https://raw.githubusercontent.com/asanabrial/estigia/main/scripts/install.sh | sh

Windows (PowerShell):

irm https://raw.githubusercontent.com/asanabrial/estigia/main/scripts/install.ps1 | iex

npm (installs and sets up in one step):

npx -y @asanabrial/estigia setup --all

Cargo (needs Rust):

cargo install estigia

Then register it in your agents, and check:

estigia setup --all      # or: estigia tui

estigia status estigia doctor

Linux archives need glibc 2.39+ (not Debian 12, Ubuntu 22.04, RHEL 9); there, use cargo install estigia. The installers check the archive against its published checksum and refuse a mismatch. The binary lands in ~/.local/bin/estigia (%LOCALAPPDATA%\estigia\bin\estigia.exe on Windows); ESTIGIA_INSTALL_DIR moves it and ESTIGIA_VERSION takes a tag other than the latest. The npm package carries no binary: it fetches the same archive, and it is what the MCP registry entry starts (mcp-name: io.github.asanabrial/estigia). A source build has no installer record, so the commands that write into your agents ask for --allow-source-build (why); cargo install --git https://github.com/asanabrial/estigia takes main. The Dockerfile builds a server-only image; none is published.

Set it up in your agents

Installing the binary changes nothing on its own.

1. estigia tui opens the setup screen; s shows what it will write. Without it: estigia setup claude-code for one agent, estigia setup --all for all; --dry-run on either writes nothing.
2. Optionally route a role to a model, the spelling the screen ends by printing:

   estigia config set "Model routing" "developer=inherit" --agent claude-code

1. In a repository where any agent may write, estigia guard installs a pre-push hook that refuses a push no live claim authorises, whoever typed it.

setup installs the skill, a directive in the agent's instruction file and the hooks, which go into every agent with an event able to refuse — five of them, in a gate that reads five dialects. What else it writes is in what it writes.

Verify

1. estigia status: what is installed, where, and whether each agent is told (tools on) and stopped (gate on).
2. estigia doctor: skill, gh, remote, guard, prune, permission and the rest, read-only.
3. estigia sessions, feed, where, needs-person and changes (uncommitted work) are read-only too.

Uninstall

Uninstall removes what Estigia created and nothing else: not another tool's block, not your notes, not a file of its own you have since edited, which it keeps and names. Run in this order:

estigia uninstall --all --dry-run   # changes nothing; says what the next line will do

estigia uninstall --all # or: estigia uninstall claude-code estigia guard --uninstall # in each repository with the push guard estigia config forget # in each checkout cargo uninstall estigia # source build only; otherwise delete the binary rm -rf ~/.estigia # optional, read the warning first

1. The dry run is safe to repeat; estigia uninstall claude-code leaves the other agents alone.
2. uninstall --all takes Estigia out of every agent.
3. guard --uninstall removes only a hook Estigia wrote, and must go before the binary, which the hook calls.
4. config forget removes /.git/estigia/, the repository settings every uninstall survives; it says which file it removed.
5. Remove the binary by the route you installed with. Installer script or npm: delete ~/.local/bin/estigia (or $ESTIGIA_INSTALL_DIR/estigia); on Windows delete %LOCALAPPDATA%\estigia\bin\estigia.exe (or under %ESTIGIA_INSTALL_DIR%) and take that directory out of the user PATH. A source build: cargo uninstall estigia.

Before `rm -rf ~/.estigia`: state.db is the workflow store, one copy on this machine: claims, states, receipts, findings, verdicts, spend, tasks, the decision history, the session registry and the mailbox. Beside it: run pointers; jobs/; snapshots/ (up to three copies of the store); lifecycle/ (the binary's provenance records); workspaces/ and roots/; the screen's language; your checkouts list. The last uninstall --all takes the store and the run state and keeps the rest (per entry). Delete it only when you no longer want the history of what this machine's gate decided.

What REPLACE and OVERWRITE mean is in docs/what-it-writes.md.

A harness, not a document

The contract under skill/ is text an agent may ignore, so Estigia holds the tools: a PreToolUse gate, a Stop hook, a pre-push hook under git, and thirty-seven operations with schemas below. The local store is the authorit