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.
§ 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 to low single digits — and, one language-server sweep aside, held there while the codebase kept changing underneath it. It is also, plainly, a correlation on one project, graded by its own author — 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.
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) and hasn't been run yet: it needs the upstream project's private per-finding archive — a question the published round-level dataset can't answer. If covered classes recur in new code at the uncovered rate, the claim is wrong.
§ 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 for any agent.
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
Two commands into your project.
Point the installer at any repo. It writes the workflow docs, the skills, the convention maps, the checks, and a permission allow-list — layered so nothing you already have is clobbered. Run without --packs and it detects your stack. Requires bash 4+ (on Windows, run under WSL).
Claude Code users can also add the slash commands as a plugin: /plugin marketplace add getsysop/sysop, then /plugin install sysop@sysop.