Open source Claude Code MIT-licensed
Recurring review findings become rules it enforces for you.
Sysop brings a full team's engineering rigor to one builder and an AI — from first plan to merge. You bring the idea worth building; Sysop brings the discipline: a complete development lifecycle, plus a feedback loop that turns the mistakes your reviews keep catching into checks the computer runs on every future task. Self-improving in a narrow, deliberate sense: you ratify every rule it promotes — nothing learns autonomously.
That command installs the loop alone — reviews that remember, rules you ratify, checks the computer runs — the recommended first slice for an existing codebase. The full lifecycle is one flag away (see § IV).
§ I · The distinction
Advice a model is asked to remember,
versus checks the computer runs.
Every AI coding tool can collect house rules and paste them into a prompt. Prompts are advice — the model may or may not apply them, and the pile only grows. Sysop takes the recurring finding, promotes it to a written convention, and — when it's mechanically checkable — compiles it to something deterministic: a grep rule, a Semgrep AST rule, a language-server pass, a coverage gate on the paths you mark critical. Enforced identically on every run, no model in the loop.
It notices the pattern
A finding that survives across review rounds isn't a one-off — it's a convention. Dual-mode review (quality + security) surfaces it; a cross-round gate promotes it into a written map consulted automatically on every future task.
It compiles the checkable ones
The conventions a computer can verify stop being prose. They become grep + Semgrep rules in a shared registry, a pyright/tsc pass, and a diff-coverage gate — a deterministic floor under every change, with no LLM asked to remember.
It retires the stale ones
Rules aren't write-only. A false-positive ledger tracks checks that fire wrongly across rounds and flags them for demotion — so the enforced set stays sharp instead of accreting alert-fatigue forever.
The pile of prompt text never gets smaller. The set of things the computer proves for you does.
§ II · The evidence
As the convention map grew, the reviews got calmer.
This isn't a projection. Sysop was extracted from a real project that ran 71 review rounds between February and July 2026. As its rule set climbed from zero to 78, the critical share of findings fell from one in five in February to about one in twenty by April, spiked back to one in six in May — an enforcement sweep filing already-promoted rules one-per-call-site, explained under the chart — and ran low through the thin summer tail. Fell, then held low, spike included; the full table is below. It is also, plainly, a correlation on one project, graded by its own author and filed by one era of reviewing model — so the limits are printed right under the chart, along with what would prove the claim wrong.
View the data
| Month | Cumulative conventions | Findings | Critical share |
|---|---|---|---|
| Feb 2026 | 0 | 285 | 21.4% |
| Mar 2026 | 65 | 1,549 | 10.5% |
| Apr 2026 | 75 | 1,089 | 5.4% |
| May 2026 | 78 | 270 | 16.7% |
| Jun 2026 | 78 | 68 | 0.0% |
| Jul 2026 | 78 | 37 | 5.4% |
Mined from the upstream project's review archive — 71 rounds, 3,298 findings, Feb–Jul 2026. Critical share is used because it needs no size denominator; raw counts mostly track the rubric, not the code — as conventions are promoted, later rounds file one finding per call site where early rounds bundled. May's uptick is exactly that: more than half of its criticals are already-promoted rules enforced one-per-call-site across legacy code, not new defects. Per-line normalized rates agree on direction from the March peak. Full method and the per-round chart are in the monograph, Fig. 7.
What this chart doesn't prove
One project, one grader. n = 1, and the same person built the tool, ran the project, and adjudicated every review — severity is self-graded. The labels have moved at least once: June's only critical was reclassified out during a later archive consolidation. Counted, June reads ~1.5%, not 0%.
Maturation is a live rival. Young codebases surface their worst findings early — the naive auth, the wrong schema — and the critical rate falls as they harden, with or without a convention loop. Nothing in this chart separates the loop's contribution from ordinary maturation.
The tail is thin. June is 68 findings and July is 37. At those sizes one bad round moves the share by double digits — "held low" is three quiet months and one excused sweep, not a stable estimate.
The reviewer is an instrument too. Every finding here was filed by the same era of reviewing model, and a review is a sample, not a census: when two frontier reviewers later scanned one identical tree, their finding sets mostly did not overlap. Just past this chart's window (August 2026), the number arrived — the upstream project's first full round under a newer model generation and a repository-derived scan scope filed 358 findings against the 23–45 a single round filed in the months before, and an unrelated second vendor on the identical tree filed 132, confirming the backlog was real. Most of that surge was scope and lens growth, and the per-mechanized-class signal held (zero new blocking findings) — but it means a quiet month bounds what that era's reviewer looked at and could see, not what was there. Expect totals to saw-tooth as coverage and lenses grow; the number that should decline, and the only one this section claims, is recurrence of an already-mechanized class.
What would settle it. Finding classes already covered by a promoted convention should stop recurring in new code while uncovered classes keep arriving at their old rate — maturation depresses both, the loop selectively suppresses the covered ones. That test is specified in the method notes shipped with the dataset (docs/analysis/REPORT.md), where it has now been run against the upstream project's private per-finding archive (the published round-level dataset can't answer it). The result is mixed and does not broaden this claim: the review instrument — the scan tooling — changed twice mid-history, so the rate comparison is inconclusive; the one robust signal — finding classes stop recurring after a convention is mechanized with a machine check — confirms the mechanization clause but is partly true by construction, and prose-only conventions show no separable effect from maturation. If covered classes recur in new code at the uncovered rate, the claim is wrong; for prose-only conventions the test can't tell, which is why this section claims only the mechanization-specific effect.
§ III · The whole lifecycle
Not a reviewer bolted on at the end.
A process from intent to merge.
Most tools in this space review a diff. Sysop is the loop around the diff — it plans the work, isolates it, documents it, reviews it two ways, and learns from what it finds. Composable skills, each one a slash command in Claude Code — and a documented step you can port, with named limits, elsewhere. The six moves below are one pass around that loop. One level up, the monograph frames the same system as three phases of a project's life — plan (the intake move), execute (the middle of the strip: the task's own plan attacked, built in isolation, documented), maintain (the dual-mode review and the promotion loop) — and the tutorial walks the same loop as four concrete commands.
Intake
brain-dump or existing repo → validated task queue
Adversarial review
the plan is attacked before it's built
Isolated worktrees
parallel work, no stepping on each other
Deferred docs
documentation written from the real diff
Quality + security
dual-mode, against the convention map
The promotion loop
findings → conventions → deterministic checks
The loop closes on itself. What the review keeps finding this month becomes what the checker enforces next month — so the same mistake has to get past a standing check, not a memory, to happen twice.
§ IV · Start
Start with the loop.
The smallest install — and the recommended first one for an existing codebase — is the convention loop alone: the review and audit skills, the maps, the compiled checks, inside whatever branching and merge workflow you already run. No task queue, no worktrees, no merge gate; nothing you already have is clobbered. Run --packs auto and it detects your stack. Requires bash 4+ to run the installer — the scripts it installs run on bash 3.2, so stock macOS is fine afterwards. (On Windows, run under WSL.)
It was run once, end-to-end, against a real ~60k-line open-source codebase before it shipped — three review rounds in, a freshly mechanized convention caught an instance no round had filed. It also folds reports from Anthropic's claude-security plugin into the same ledger, so an outside scanner's findings become tracked work — how that works. Loop mode: the day-one walkthrough →
The whole lifecycle — where the loop grows. Planning, the task queue, worktree-isolated builds, the single human merge gate — everything § III describes. Drop --mode loop to start there directly (the natural door for a greenfield project — /intake wants a project to plan), or grow a loop install in place later with a single --update --mode full: purely additive, and nothing the loop has learned is touched.
Claude Code users on the full lifecycle can also add the slash commands as a plugin: /plugin marketplace add getsysop/sysop, then /plugin install sysop@sysop. (A loop install needs no plugin — the plugin's extra commands are the lifecycle skills, whose supporting scripts a loop install deliberately doesn't have.)