/abide-compile

name: abide-compile
description: Compile a repository's instruction files (AGENTS.md, CLAUDE.md and friends) into an Abide rubric, then validate and calibrate it.

Compile an Abide rubric

You are turning the rules a person wrote for coding agents into a rubric that a checker outside your context window can enforce on every edit. The checker sees only one rule and one diff at a time. Nothing else. Every decision below follows from that.

Two facts before you start:

• Rules come only from the user's own files. Never add a rule you think they should have. If a file holds zero rules, the rubric holds zero rules and you say so.
• The rubric is a committed, hand-editable file. A person will read it, and a verdict must trace to a rule they can point at. Quote their wording.

Step 1. Read the sources

The hook that sent you here listed the instruction files it found and where the rubric goes. Read every listed file in full. Then:

• Follow pointer files. A file whose whole content is "Read instructions from X" or "Read ./AGENTS.md" is a pointer. Read X and treat X as a source in its own right: list it under `sources` with its own path so it gets its own hash.
• Files under a subdirectory apply only there. The hook gave each one a scope glob. Rules from that file carry that glob.
• Read `CONTRIBUTING.md` only when it was listed, and keep only sentences that give an instruction. Prose about how to open a pull request is not a rule.
• If a lint config was listed (`eslint.config.*`, `.eslintrc*`, `biome.json`, stylelint config), skim it for rule names. When a rule you extract is already enforced there, keep the rule and record the lint rule name in `check.overlaps`. It stays in the rubric because lint runs later than an edit and the convention still binds; the label keeps it from being reported as a new finding.

Step 2. Extract every statement that instructs

Go through each file top to bottom. A rule is any sentence that tells the agent to do or not do something about code. Headings, background, and rationale are not rules, but they often say what a rule is for and belong in the wording of its question.

For each rule capture:

• `text`: the user's own words, trimmed to one or two sentences. Do not paraphrase into something more general.
• `source.path` and `source.line`: where it came from. Line numbers matter; they are how the person finds it.
• Any code block next to it. A worked example or counterexample carries more signal than the prose, and belongs in the question's criteria (see step 4).

Do not merge two rules into one because they sit under one heading. Do not split a rule that is one idea.

Step 3. Classify each rule into exactly one bucket

Ask the questions in this order and stop at the first yes.

1. Can a linter enforce it exactly? Then `check.type` is `lint`. Examples: `interface Foo` when the rule says use `type`; `as` casts; `fetch(`; `process.env.`; `Date.now()`; `console.log`; `npm install`. Put the linter rule that enforces it in `how` (`@typescript-eslint/consistent-type-definitions`, `no-restricted-syntax`, a stylelint rule) or, failing that, the AST or grep shape, and a `pattern` as a hint when one is obvious. Abide records these and reports them for the user's own linter; it never runs them and never sends them to the model. The judge is for what a linter cannot express. 2. Does the rule need counting or measuring: line lengths, line counts, selector counts, nesting depth, alphabetical or length order (imports or props ordered by line length is the common one)? That is mechanical work, and the judge cannot count. If step 1 found no regex for it, `check.type` is `deferred` with reason "needs a script, not a judge". Do not turn it into a model question; it will score about 0.4 on everything. 3. Can a judge answer it by looking at a change and nothing else? Then `check.type` is `model`. Most style, structure, comment, error handling, naming, and "do not do X" rules land here. 4. Does answering need the rest of the repository? "Reuse existing error codes", "follow existing patterns", "any visual pattern in two places becomes a shared component", "check whether a helper already exists". Then `check.type` is `deferred` with a one line `reason`. These are real rules that this version cannot check on a diff, and the report says so. 5. Is it about the conversation or the process rather than the code? "Ask when unsure", "state a plan", "run the tests before you finish", "clean up processes you started". Then `check.type` is `unenforceable` with a `reason`.

Every statement lands somewhere. Count them: the summary you give the user is the four bucket counts.

Step 4. Write the question for each model rule

The judge is a small, fast model that answers typed questions with a probability. It is good at narrow, concrete questions and bad at vague ones. A vague question scores about 0.4 on everything and never fires, and the user reads that silence as good news. Write every question so that a violating diff scores near 1 and a clean diff scores near 0.

• One idea per question. If the rule has two parts, make two rules.
• Ask about the diff: "Does this change add ...", "Does this change put ...". Name the concrete shape you want caught: the identifier, the call, the syntax, the position. "Does this change add a comment that restates what the line below it does?" beats "Are comments sparing?".
• Never put scope in the text. "For a file under apps/web/src/server" belongs in the `scope` field, not in the question. Scope is a list of globs relative to the repo root, for example `["apps/web/src/server/**/*.service.ts"]`. Omit it when the rule applies everywhere.
• Keep instructions under about 60 words. Every word is billed on every edit whether or not the rule fires.
• Ask for existence, not for a judgment of the whole: "Among the added lines, is there at least one comment whose content a reader could reconstruct from the code directly below it?" fires on the first of