agentleFS
yiyaw-labyiyaw-lab/agent-armor/redline/SKILL.md

redline

Skill1 starsChanged 5 months agoMITView on GitHub

Convert a NEAR-MISS into an ENFORCED guardrail — a mechanism a non-agent actor (the harness/hook runtime, git, CI, the test runner, the OS) executes automatically and that BLOCKS on violation, not a passive lesson the agent must remember. The active-enforcement layer: where /harvest records a lesson and /hone advises from recurring grades, redline makes the dangerous class structurally impossible. Hard refusal criterion keeps it from shipping advice-in-disguise; every guardrail is proven to fire by negative control before it is trusted. Propose-on-approval. Modes: <near-miss> (diagnose + propose) | sweep | apply.

6 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

1 rule. 0 are common, 0 are distinctive, and 1 is very specific to this project.

  • 0

    Common

    Most of the 6 edited versions we read keep these.

  • 0

    Distinctive

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Propose-on-approval, one guardrail per commit, reversible: Default proposes and writes nothing.

    line 12

“Common” is measured: kept by at least 6 in 10 of the 6 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

The law this skill runs on: a guardrail that depends on the agent remembering is not a guardrail. Your suite has a deep passive-knowledge layer — memory (/harvest), preferences (/taste), skill instructions (/hone) — and all of it relies on recalling the right thing at the right moment, which is exactly what fails under pressure (the documented recurring self-bugs: a destructive step run past an unread guard; a leak scan that printed a false CLEAN right before a public push). redline is the missing active-enforcement layer: it takes a close call and converts it into a mechanism a NON-agent actor runs automatically and that BLOCKS — a settings hook that denies the call, a git hook that exits non-zero, a CI check that fails the build, a test the runner enforces, a permission deny, a code assertion. It escalates the scariest lessons from "the agent must remember this" to "the agent cannot get this wrong." The judgment is deciding a near-miss warrants a wall and which wall; the wall itself is the product.

Three hard invariants:

  • Exo-agent + blocking, or it is not a redline. The guardrail MUST be executed by a non-agent actor (the harness/hook runtime, git, CI, the test runner, the OS permission system) AND must BLOCK on violation (deny / fail / exit-nonzero) — never warn-and-proceed, never "the agent checks." If enforcement routes through the agent's own judgment or memory, it is advice → REJECT it and route to /hone (a skill nudge) or /harvest (a memory). This refusal criterion is the whole reason redline is not advice-in-disguise; never relax it.
  • Prove it fires — installed ≠ enforced. No guardrail is trusted until a NEGATIVE CONTROL demonstrates, with real output, that it BLOCKS the real bad input and PASSES the good input, firing at the actual risk point. A hook with a wrong matcher, a check swallowed by || echo CLEAN, a test nobody runs, a job scheduled where its state is empty — all are installed-but-inert (the false-CLEAN / placement-split trap). The proof is mandatory, not polish.
  • Propose-on-approval, one guardrail per commit, reversible. Default proposes and writes nothing; installs land only in apply, individually approved, each carrying its negative-control proof, branch-only and git-reversible. A blocking guardrail is high-blast-radius — never bulk-install.

/redline <near-miss> (default — diagnose + propose)

  1. Pin the near-miss. State precisely what almost went wrong, what the damage would have been, and what single check would have caught it. (Pull it from the session, a /harvest lesson, or the user's description.)
  2. Pick the enforcement substrate. Choose the exo-agent, blocking mechanism that makes THIS failure impossible: a settings.json PreToolUse/permission DENY (harness-enforced) · a git pre-commit/pre-push hook exiting non-zero (git-enforced) · a CI check failing the build · a regression test the runner enforces (CLAUDE.md already mandates this for the four recurring areas) · a code-level assertion/schema that raises. If only a passive option exists (a note, a skill step, a warn-and-proceed), STOP — this is not a redline; route to /harvest or /hone and say so.
  3. Answer the interrogation (the not-advice test), in one line each: WHO executes it (must be a non-agent) · WHAT it does on violation (must block, not warn) · WHERE it fires (the placement triad — at the risk point, reading the right state, in the filesystem/runtime that actually consumes it). If the answer to "who runs it" is "the agent" or "whoever remembers," it fails — reject.
  4. Design the negative control. Specify the bad input that MUST be blocked and the good input that MUST pass, and how you will show real output for both. Scope the block as tightly as the failure — the pass-on-good leg is the proof you did not over-wall (a guardrail that blocks legitimate work is worse than the near-miss).
  5. Propose + route to the executor. Emit the guardrail (its diff/config), its interrogation answers, its negative-control plan, and its executor handoff (a hook → /update-config; a test → tests/; a deny rule → settings; a code assertion → the call path). Write the guard WITH its reason cited (the near-miss it prevents) so /moonwalk later returns KNOWN-LIVE and /raze refuse-lists it by construction. Write nothing yet.

/redline sweep

Read-only. Scan the memory store + the recent session for passive lessons that are dangerous AND exo-agent-enforceable but still live only as advice (a memory, a CLAUDE.md note, a repeatedly-nudged hone step that recurred anyway). Emit the "which scars should become walls" backlog: each candidate near-miss · the wall that would enforce it · its substrate · whether a negative control is feasible. Propose and write nothing. (Mirrors /hone audit and /raze audit; this is also /hone's escalation surface — a failure that recurred DESPITE a nudge is proof advice is insufficient.)

/redline apply

Execute ONLY pre-approved guardrails from a prior scan. Install each via its executor (hook via /update-config, test into tests/, deny into settings.json, assertion into the call path), then RUN its negative control — block-on-bad and pass-on-good, with real output, at the actual risk point. One guardrail = one commit. A guardrail that fails its negative control (does not block the bad input, or blocks the good one) is NOT installed — it is theater or it over-walls; report and drop it. Record each installed guardrail + its proof to ~/.claude/redline/guardrails.md so its real fires can be graded later (closes the loop the way /raze and /hone do).

Rules

  • Exo-agent + blocking or reject: the refusal criterion. Every guardrail answers who-runs-it (non-agent) / what-on-violation (blocks) / where-it-fires (the risk point); "the agent" or "whoever remembers" = advice = route to /hone or /harvest, never shipped here.
  • Prove it fires, always: installed-but-unproven is the false-CLEAN / inert-matcher trap; a negative control with real output at the actual risk point is mandatory before trust. A wall you did not prove stops anything is worse than none.
  • Do not over-wall: scope the block exactly to the failure; the pass-on-good-input leg proves you did not break legitimate work. A false-positive wall erodes trust and gets disabled — that is redline's add-back: log it and loosen.
  • n=1 is enough, and redline is /hone's escalation: a near-miss too dangerous to await recurrence, OR a failure that recurred despite a hone nudge (advice proven insufficient), warrants the wall. Do not wait for ≥2 the way /hone does — the point is to act before the damage.
  • Lane discipline: redline ENFORCES (active); /hone advises from recurring grades (skill bodies); /harvest records lessons (memory); /update-config is redline's hook EXECUTOR — do not re-implement hook-writing; /moonwalk reads guards (redline writes them, with the reason cited so moonwalk's excavation is trivial); /raze protects them (tests/gates/the logging net are refuse-listed). A project fact → /burn rent; a preference → /taste.
  • Essentialness metric (honesty hook): log to ~/.claude/redline/guardrails.md; the grade is guardrails that demonstrably FIRED ÷ installed, plus the drop in repeat near-misses. A wall that never fires over time is theater → /raze it; a wall that fires on good work is over-scoped → loosen. It earns its keep the moment a documented recurring self-bug stops recurring because the system now PREVENTS it instead of REMINDING about it.
  • Shared-tree safety: explicit git add <path>, never -A; settings/hook edits go through /update-config's lane; no history rewrite on a shared branch; an adversarial /code-review must try to refute each guardrail (especially its negative control) before any PR.

Pipeline placement: /grade-session + /harvest surface the near-miss → redline decides it is dangerous + exo-agent-enforceable → installs the blocking guardrail (executor: /update-config / a test / CI / a permission) → proves it fires → /moonwalk later reads its cited reason, /raze refuse-lists it. redline is the active-enforcement layer; it does not advise (that is /hone) or merely record (that is /harvest) — and it refuses to pretend a passive note is a wall. Naming: redline = the hard line the system will not let you cross; if the unrelated loaded sense of "redlining" grates, ratchet (a guardrail only tightens, never loosens) is the sharpest alternative — kept as a possible alias, not created.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.