agentic-os

Agentic OS

"Done." — your AI coding agent, about code it didn't test. A rules file asks your agent to behave. Agentic OS checks that it did — leaked secrets and a green check over zero tests fail your git hooks and CI; a skipped review or phase shows up when the validator reads the work trail. Backstops you control, not the agent's own word.

A governance-first layer for AI coding agents — guardrails and a gated workflow for Claude Code, Codex, Cursor, Copilot, Antigravity, or any Markdown-reading agent.

 ·  繁體中文 · Contributing · Changelog

It checks the evidence behind what your AI coding agent claims — secrets, tests, reviews — through your git hooks and CI. Here's a gate firing:

The /bootstrap, /review, and /ship above are plain text prompts — your agent maps them to the workflow files in the repo, so they run the same in Cursor or Codex as in Claude Code.

Or run a gate yourself, no install — the credential scan that catches a leaked key before it reaches git history:

bash demo/run.sh          # Windows (PowerShell): pwsh demo/run.ps1

Full terminal output

  An AI agent wrote this file and reported: "Done — config added."
  ----------------------------------------------------------------
    DB_HOST=prod.internal
    aws_access_key_id = AKIA****************
  ----------------------------------------------------------------

  Without a gate, that commit lands and the key is in git history forever.
  Agentic OS runs this before the commit is allowed:

    $ scan_credentials.py config.env

CREDENTIAL PATTERN(S) DETECTED (values redacted):
  config.env:2: aws-access-key-id
Rotate the exposed secret, remove it from the change, then retry.

  Commit BLOCKED. The agent said "done"; the machine said no — and it
  redacted the value instead of echoing your secret back at you.

Your agent can still cut a corner. What it can't do is get a leaked secret, a green check over zero tests, or a skipped review past the hooks and CI — those run whether it cooperates or not. The key above is generated at runtime and redacted on output, so the demo never stores a real secret.

Rules vs. enforcement

A rules file — Cursor Rules, a plain AGENTS.md — is a prompt the agent can ignore. Agentic OS keeps that discipline (plan before editing, no unasked-for refactors) and adds a layer the agent doesn't control:

Failure mode	What catches it	Where
A secret committed to history	scan_credentials.py (shown above)	pre-commit hook + CI
"Tests pass" with no tests	CI runs the real suite	pull request
A phase skipped with no evidence	validate.sh reads the work trail	pre-commit (local)

The third row is the part a rules file can't reach: validate.sh parses each task's work log and fails if a required phase was skipped or its evidence is missing. The local pre-commit hook is opt-in and you can --no-verify past it; the three required CI checks (Framework Validation, ShellCheck, Check Markdown Links) are the floor that can't be skipped — they must pass before any PR merges. The security scanning jobs (credential scan, SAST, dependency audit) run on every PR but are not required merge checks unless you add them to branch protection. The Security badge above is this repo running the same credential and SAST gates on its own every push.

Sits under what you already have

Agentic OS is the enforcement layer. A rules file or a skill pack tells your agent how to behave; this is the part that checks it actually did - in your git hooks and CI, where the agent's own report doesn't get a vote. Already have those? Keep them. This sits underneath and turns the discipline they ask for into a check that can fail your commit or your build.

Gated phases, scaled to risk

Every task runs a gated workflow, and the rigor scales to the risk. Skip a phase and validate.sh fails — but a typo doesn't run the same gauntlet as a feature:

  tiny-fix    classify --> execute --> evidence --> done
  quick-win   bootstrap --> plan --> implement --> evidence --> ship
  feature     bootstrap --> spec --> plan --> implement --> review --> test --> ship

  And the ship gate is not a formality:

  ship attempt --> [ no review/test evidence ] --> BLOCKED
  ship attempt --> [ evidence on record ]      --> SHIPPED

  The agent can still cut a corner. It just can't cut this one
  past a check it doesn't control.

The full set of paths, by classification:

Classification	Required phases
tiny-fix	Classify → Execute → Evidence → Done
quick-win	Bootstrap → Plan → Implement → Evidence → Ship
feature	Bootstrap → Spec → Plan → Implement → Review → Test → Handoff → Ship
hotfix	Bootstrap → Research → Plan → Implement → Review → Test → Ship
architecture-change	Bootstrap → ADR → Spec → Plan → Implement → Review → Test → Handoff → Ship

What you get

Machine-enforced backstops	The failure modes above are caught by your git hooks, the validator, and CI — not by the agent's own report. The agent can cut a corner; it can't get that corner past the checks it doesn't control.
Skills that auto-attach by phase	The workflow puts the right checklist in front of the agent by task type — TDD on a feature, an auth-security pass on login code — so you don't wire skills by hand. Guidance, not gates.
Memory that survives handoffs	Decisions and evidence live in one source-of-truth state file, so they carry across sessions and agents instead of resetting with the chat.
Cross-platform	One set of governance files works across every major AI coding agent — the same rules whichever one you run.
Token-efficient by design	Governance scales to risk: a tiny-fix skips the heavy guardrails (~5,000 tokens), so you're not paying frontier-mo