Your docs already state the rules. Striff checks every pull request against them, and when a change contradicts one, it quotes the sentence, before the merge.
Striff
on
Pull request #418
acme/checkout-service · feat/csv-export → main
1 rule broken
legacy/ in new code; use the equivalents in core/. AGENTS.md:18 Nothing in checkout depends on legacy Agent instructions CartService now imports legacy.pricing.PriceCalculator Broken by this PR The rule held before this pull request and is broken after it. PaymentGateway, and only the billing module talks to the Stripe SDK. docs/adr/0007-payments.md:12 Every class in billing.providers implements PaymentGateway, and only billing depends on com.stripe Payments ADR Holds The rule held before this pull request and still holds after it. common. ARCHITECTURE.md:42 No feature module depends on another feature module, where the features are cart, catalog and accounts Peer modules Holds The rule held before this pull request and still holds after it. is the rule compiled to a formula, your code parsed at each revision; the verdict is whether one satisfies the other. Three of the 42 rules this repository’s docs state. The dashboard lists all of them →
Recent findings in
scikit-learn/scikit-learn 67k 54held 0broken 1stale names 
Lightning-AI/pytorch-lightning 31k 7held 0broken 1stale names 
celery/celery 29k 29held 0broken 1stale names 
dotnet/BenchmarkDotNet 11.5k 8held 0broken 1stale names 
apache/storm 6.7k 90held 0broken 5stale names 
Netflix/mantis 1.5k 60held 0broken 2stale names The problem
Spec-driven development made your docs the instructions: coding agents read your specs and architecture docs as context, then write code that quietly contradicts them, and no reviewer re-reads those documents on every change to catch it. That gap is spec drift. Left unchecked, each merge drifts a little further from what your team agreed, until every change costs more than it should and nobody wants to touch the core. Striff catches the contradiction on the pull request, while it is still a one-line fix.
In our survey of 335 open-source repositories that write their architecture down, 63% already hand their coding agents docs to build from, and only 8% of those run anything that checks the code still matches.
Why coding agents make architecture review matter more·11 min read 63% of repositories hand their agents docs to build from. 8% of those check the code still matches.The check
One check, beside your CI. It says what the change moved, lists every rule your own documents state about the code it touched, says whether each one still holds and quotes the sentence it came from, and draws the classes involved.
Below is one from a public repository, its rules unedited, in the layout Striff posts today: catatafishen/agentbridge #1102 Open the check itself →
Striff catatafishen/agentbridge · #1102 · fix/issues-1074-and-later
Successful
All 24 documented rules about the code this pull request changes hold.
| # | Rule |
|---|---|
| 1 | Holds FileTool has a getGitFileStatus method · AGENTS.md#L338 “Append git status annotation (tracked/untracked/staged) using FileTool.getGitFileStatus()” |
| 2 | Holds McpProtocolHandler has a truncateIfNeeded method · AGENTS.md#L373 “The truncateIfNeeded() in McpProtocolHandler provides a safety net, but tools should self-limit” |
| 3 | Holds ConversationService depends on ConversationWriter · docs/CONVERSATION-PERSISTENCE.md “ConversationService (serialized async write queue) depends on ConversationWriter (synchronized SQLite writes)” |
| 4 | Holds FileTool depends on AgentEditSession · docs/INLINE-DIFF-REVIEW.md#L379 “FileTool.writeFile (all variants), FileTool.createFile, FileTool.deleteFile call AgentEditSession.ensureStarted()” |
| 5 | Holds McpHttpServer depends on McpProtocolHandler · docs/MCP-ARCHITECTURE.md “McpHttpServer 127.0.0.1:port depends on McpProtocolHandler JSON-RPC handler” |
| 6 | Holds GitCommitTool depends on GitTool · docs/bugs/COMMIT-NOT-FOUND-IN-LOG-BUG.md “GitCommitTool.java calls showNewCommitInLog(root) after a successful commit” |
Rows 7–24, all holding, are trimmed here.
added removed changed one box, one class
Every check carries a diagram. It draws the part of your architecture that the pull request touched, in UML class notation: a box for each class, its members inside it, and a line for each dependency between them. Color marks what the change added, removed and altered. Drag it to pan, or open it full size.
Striff maps how this pull request changes the architecture and checks it against the rules written in the repository’s own docs.
Striff is neurosymbolic: a language model reads your docs and proposes rules, and a program decides what is true. A parser turns your code before and after the pull request into a formal model of its types, members and references, resolved the way a compiler does, and each rule becomes a formula in first-order logic. Every verdict is formal model checking: does the model satisfy the formula? The language model is asked exactly one question, at the start, and it is asked in English — the grounding, the verdict and the sentence you read are all computed, and nothing is needed beyond the documents your repository already has.
01 How a documented rule becomes a verdict
01 Parse Deterministic
Both revisions of the code become one structural model — types, members, references, packages — resolved the way a compiler resolves them, never matched as text. Everything after this point is about the model, not about the source.
02 Read Language model
Your documents go to a language model, which proposes candidate rules from prose. The only step that reads English, and the only one that can be wrong without being caught — which is what the next step is for.
“Never import from legacy/ in new code” · AGENTS.md:18
03 Ground and compile Deterministic
Every name a proposed rule uses must resolve in the model. One that names a class your code does not contain is dropped rather than guessed at. What survives is compiled into a formula of first-order logic over the model — the point past which no prose is left to interpret.
04 Evaluate Deterministic
The formula is model-checked at both revisions. Which of the two satisfy it is the whole verdict: satisfied before and not after is a rule this change broke; unsatisfied at both was already broken and is not blamed on the change. The sentence you read on the check is composed from the formula, so it cannot drift from what was actually checked.
For teams
The check reads one pull request at a time. The dashboard is the same reading of your documents, added up across the organization: each sentence that makes a claim about the code, the rule it became, whether the default branch keeps it, and which repositories and pull requests broke one this month.
Docs & rules
Your architecture docs, ADRs and agent instructions as a tree. Pick a document for its own rules, a folder for every rule beneath it, or the repository for all of them: the sentence each rule came from, the rule it became, and whether the default branch still keeps it. Sort, search and export what you picked.
Open the docs and rules →
Checks
Each pull request Striff checked, newest first: how many of your documented rules it was held to, which it kept and which it broke, the documents read to get there, and the pull request one click away.
Open the checks →Documented rules
Documented rules brokenRules from your own documentation that a pull request broke: true before the change, false after it. The check quotes the sentence and the line it came from. Rules already broken before a PR are counted separately and never charged to it.
Documented rules heldShare of documented-rule checks where the pull request kept the rule: nothing in it broke the rule. Checked is held plus broken plus already broken; rules Striff couldn't check are left out rather than counted as a pass.
819 checked
Documented rules already brokenRules your documentation states that were already broken in the code Striff checked, not by the pull request that checked them. Reported so they are never mistaken for a pass, and never charged to that pull request.
PRs that broke no ruleShare of analyzed pull requests that broke none of your documented rules, over the last 6 months.
Pull requests
PRs analyzedTotal pull requests Striff checked across every active repo in this installation.
CoverageShare of GitHub PR-check webhook events (opened, updated, reopened) that completed analysis, over the last 6 months. Below 100% may mean PRs were skipped: check billing status or the repository connection.
Most-flagged repos over timeEvery repo that has been among a month's most-flagged at any point in the last 6 months, tracked month by month. A flag is a documented rule one of the repo's pull requests broke. A repo can show a lower or zero count in months it wasn't in that month's own top list.
PRs that broke a ruleThis month's recent pull requests that broke at least one documented rule, the most rules broken first. Click through to see each rule and the sentence it came from.
Jul 2026
Introduce direct DB call from the notifications module
Merge auth and billing request pipelines
Read ledger tables directly from the invoice webhook consumer
Metrics
Rules broken, held and already broken, the share of pull requests that broke none, and the repositories and pull requests flagged most. Where the fix-up time should go this quarter.
Open the metrics →Free Chrome extension
Reviewing an unfamiliar change means holding somebody else’s dependency graph in your head. The extension draws it in a tab beside Files changed, so you see what a change touches before you approve it. The same load checks the rules that repository states in its own documents, and a Findings button opens them beside the diagram.
Use the extension for one pull request, on demand, in any public repository, including ones you do not own. Use the GitHub App to check every pull request your team opens, post the result where the whole team reviews, and keep the history that becomes your dashboard.
Add to ChromeGet started
Nothing to learn and no workflow to change: Striff shows up as one more check on the PRs your team already opens. Start free on public repos, add private repos when you're ready.
Free
Public repositories
Your documented rules checked on every public pull request, with a diagram of each change, plus the browser extension for any public PR you visit.
Starter
One team's private repos
Your documented rules checked on every private pull request, with a diagram of each change, for one team’s repositories.
Enterprise
Self-hosted & 50+ repos
Private deployment, SSO, and audit workflows for organizations that need full control.
FAQ
You already wrote it down. Striff reads the documents in your repository that make claims about the code, turns those sentences into rules, and checks them against the code your pull request produces, quoting the sentence and linking the file it came from. Nothing is configured and no rule format is invented: your documentation is the rulebook. A rule can be as plain as where a class lives or as sharp as “the domain module must not depend on infrastructure”. Alongside the rules, every pull request gets a diagram of what changed and review notes on the components it touched. If your docs make no checkable claim about the code, Striff invents no rules of its own: you still get the diagram and the review notes.
Yes: it is the check that comes after the spec. Spec-driven workflows help you write a spec and build from it, and nothing in them checks, on the pull requests that follow, that the code still does what the spec says it does. Striff reads the specs, plans and design docs committed to your repository alongside your AGENTS.md, CLAUDE.md and ADRs, turns each sentence that makes a claim about the structure of the code into a rule, and checks every pull request against it. A sentence that describes work still to come is not held against code nobody has written yet. When a change contradicts the spec, the check quotes the line: that is spec drift, caught while it is still a one-line fix.
The diagram runs on Java, TypeScript, Python and C#. Striff parses source into a full structural model with its own parser, not regex or text matching, so references, inheritance and dependencies resolve the way a compiler sees them. Go is coming.
No, and the architecture is the answer. Every verdict is produced by deterministic analysis of the structure your change actually creates: the parser builds a model of both revisions, each documented rule is a query over that model, and a rule is held when nothing in the pull request breaks it. The model is fact-gated, which means it can rank findings, explain them and write the summary of what your PR did structurally, but it cannot originate one, rename one, or turn "could not answer" into a pass. That last constraint is why a rule Striff cannot answer from the code is left out of the results instead of quietly counted as green.
No. Striff runs as a GitHub Check next to your CI and posts its results when the analysis finishes, typically within a few minutes. It never blocks a merge unless you choose to make the check required.
Just install the GitHub App. It works on public and private repos alike and posts checks automatically on every PR, with no per-developer setup. Plans start at $29/month, based on how many repos actually get reviewed each month, not how many you connect. To try Striff on somebody else’s public pull request first, use the browser extension.
No. The extension runs in your browser on any public pull request you visit, so you can point it at somebody else’s repository without touching it, and it is free on every public pull request, with no account. The analysis itself runs on Striff’s servers. A free GitHub token raises GitHub’s rate limits: on a public pull request it is only sent to GitHub; on a private repository or a very large pull request, Striff’s servers use it to fetch the code themselves.
Yes. One load brings up the diagram and checks the rules that repository’s own documents state. When it finishes, a “Findings” button with the rule count on it opens the full list beside the diagram. Same pipeline as the GitHub App, on a repository you do not have to own.
Your code is parsed on Striff's servers in memory and not persisted. The AI explanation layer works from the structural model (component names, relationships, metrics, and doc excerpts), not your raw source files. For teams that need full control, self-hosted deployment is available on the Enterprise plan.
Every unchecked merge makes the next change a little more expensive. The cost compounds quietly, and nobody can point at the day it started. Striff starts checking on your next pull request.