CritOS

Open source · Apache-2.0 · for Claude Code

Multi-agent governance for your repository.

Give every agent a domain, a memory and a boundary.

Good agents are built by a good team. CritOS organises the agents that build your software: a method written into your repo, and checks that show what is actually true.

Get started View on GitHub
  • Plain files in your repo
  • Versioned with git
  • No telemetry
PS> git clone --branch v1.1.1 https://github.com/CritosAI/critos.git C:\tools\CritOSPS> cd C:\tools\CritOSPS> powershell -ExecutionPolicy Bypass -File .\install.ps1
> /crit-scaffold-project
Windows or Linux · Claude Code · git · Node.js

The difference

  • Structure. The project cut into domains, the rules pinned in the repo.
  • Ownership. One agent per domain, and what it does NOT do.
  • Debt. Every request has one owner and stays counted until it is closed.
  • Verification. Twenty-four deterministic checks say what is actually true.

The problem

What happens between sessions and between agents.

Your agents write the code. The knowledge behind it doesn’t stay.

  • Every session starts cold. What the last one decided, and why, left with its chat.
  • Nobody owns anything. Two agents change the same part, and each undoes the other.
  • Nobody checks. Work is declared done when it isn’t, and the docs drift from the code.
  • Nothing adds up. The same question gets settled three times, and every new agent starts from nothing.

Add agents, and it multiplies.

Good teams solve this for people with code ownership, architecture decision records and bounded contexts. CritOS applies the same to AI agents.

The idea

Agents are part of the repo, like its modules.

  • Defined in the repo. What each agent owns, and what it does NOT do: its interface.
  • Its state in the repo. Its memory, in plain files.
  • A declared channel. Agents talk to each other through the inbox.

Versioned, reviewed and cloned with the code. Clone the repository on another machine and the team comes with it.

your-repo/
├── CLAUDE.md                  routing: where an agent starts reading
├── .claude/agents/agent-1.md  the steward (installed — do not edit)
└── .critos/
    ├── system/                the five contracts, PINNED at a release
    ├── project/               YOUR choices: settings, the roster,
    │                          the agents' definitions
    ├── memory/a<N>/           one folder per agent, one writer each:
    │                          STATUS, DECISIONS, LESSONS-LEARNED
    └── shared/                the inbox, the roadmap,
                               the register of iron rules

How it works

A domain, its memory, the governance, the rules.

  1. 01Domain

    Agents that own a domain, instead of playing a role.

    Not “a coder” and “a tester”: the owner of the billing engine, the owner of the deploy surface. Each states what it does NOT do, so one agent’s edge is where the next begins.

    A steward ships with CritOS. It interviews you, reads your repo, measures where the work concentrates and proposes the domains. It proposes; you decide. It works with one agent too.

  2. A role has nothing to remember. Memory needs a subject — and the subject is the domain.

  3. 02Memory

    The memory of that domain.

    Per agent: what is true now, what was decided and why, what must not happen again. Every session starts from there. Plain files in your repo, versioned with git.

    STATUSDECISIONSLESSONS-LEARNED

  4. 03Governance

    Governance that keeps the growth honest.

    • A shared inbox. Every request has one owner and a closure criterion, and stays counted until it is closed.
    • Twenty-four deterministic checks. Broken links and orphan docs, stale status, debts nobody is counting, citations of decisions that no longer exist, edits to the pinned rulebook.
    • A guard. It asks you before a git push, and before any git command that would sweep another session’s uncommitted work.
  5. 04Rules

    Rules pinned in the repo.

    The rulebook is pinned in each repo: a rule that changes under you fails silently. The checks are shared from the machine: a broken check fails loudly, for everyone — and gets fixed.

    TierWhat it holdsWho writes it
    systemthe rules that do not vary between projectsnobody, in your repo: it is pinned, and a check tells you if it drifts
    projectthe choices this project madeyou; the steward keeps it consistent
    workwhat the work producesthe agents, one writer per folder

A day with it

Boot, work, close, stop, ask.

  1. /crit-agent-onboard

    Pick an agent. It boots in order: the contracts, its own boundary, what it owes — and only then where it left off.

  2. work

    Inside its domain.

  3. close the round

    A local commit, one inbox line if it touched a neighbour’s domain, the checks on what changed.

  4. /crit-checkpoint

    When you stop: it reconciles its status with git and the inbox, and hands you a restart block.

  5. /crit-status-check

    “What is left?” — answered from the inbox and git, never from memory.

Category

What it is — and what it is not.

It is

  • A development method, written into your repo.
  • At development time: it organises the agents that build your software. Today, on Claude Code.
  • One owner per domain: each agent defined in the repo, with its memory and its boundary.
  • For software development: everything is built on git.
  • Checks that flag and never block: each finding goes to the agent that owns the problem.

It is not

  • Not a runtime, not an orchestration framework and not a service: it does not run agents, and nothing of it ships inside what you build.
  • No server, no database, no account behind it. An agent is started by you, or invoked by another agent — which of the two is yours to choose, per agent.
  • It never pushes, builds or deploys: those stay yours.
  • No telemetry, and no list of who uses it.

Install

Two steps.

Requirements. Windows (with Git Bash) or Linux. macOS is untested in 1.0. Claude Code, git, and Node.js (the installer and two of the checks use it).

1 The machine, once.

PS> git clone --branch v1.1.1 https://github.com/CritosAI/critos.git C:\tools\CritOS
PS> cd C:\tools\CritOS
PS> powershell -ExecutionPolicy Bypass -File .\install.ps1
$ git clone --branch v1.1.1 https://github.com/CritosAI/critos.git ~/tools/CritOS
$ cd ~/tools/CritOS
$ bash install.sh

The installer touches four things under ~/.claude, and nothing else: one link per skill, one for the guard, one settings.json entry that registers the guard (a backup is written first), and one block in CLAUDE.md between CritOS markers. -Uninstall / --uninstall removes exactly those.

Keep the checkout where it is: the controls run from it. Restart Claude Code afterwards.

2 Each repository, once.

Open Claude Code in your repo and run:

> /crit-scaffold-project

It pins the rulebook into the repo, creates the skeleton and commits. Then it offers you the steward: a short interview, a measured reading of your repo, a proposed set of agents — one is a legitimate answer — and, once you have ruled, the drafts of their definitions for you to approve.

Say later and you stop at a clean commit. /crit-team brings the steward back whenever you want — the first time, and every time the project has grown and the team should be looked at again.

Agents forget. Your repo doesn’t.

Start with one repository. One agent is enough: you still get the memory, the checks and the guard.

Install in two steps Read the README