---
name: antifragility-audit
description: Runs an antifragility/reasoning-architecture audit methodology against a target codebase (your own, or an external repo given a URL) and produces a structured report. Invoke with a repo path or URL, e.g. "/antifragility-audit https://github.com/owner/repo" or "/antifragility-audit ~/projects/some-repo".
---

# Antifragility / Reasoning-Architecture Audit

**Public methodology page:** https://theonedegreedispatch.com/antifragility-audit
(process-level description — a related consulting offering, distinct from
this open-source implementation). **PATENT PENDING | U.S. Provisional
Patent Application No. 64/132,274.** **License:**
this tool (`SKILL.md`, `precheck.mjs`, `render-pdf.mjs`) is Apache License
2.0 — see `LICENSE` and `NOTICE` in this same directory, including the
patent grant/retaliation terms (License §3) and the trademark boundary
(code is Apache-licensed; the "One Degree" name/branding is not — see
`NOTICE`). Every report this skill produces carries the same patent/
license/methodology-link notice — see `render-pdf.mjs`'s branded template
and Step 5 below; keep that notice if the report format changes.

Scores how a system's AI-touched decision-making holds up under stress — not
a generic code review. This methodology was developed and proven across two
real, structurally different audits: a mature, live production system with
real incident history baked into its own code comments, and a pre-build
project (governance docs plus one small deterministic module, no AI layer
shipped yet). Those two passes are why this skill has the maturity-gating
step below (§2) and the 7th dimension (§3.7) — both were added *because* a
real audit surfaced a real gap, not designed in the abstract.

**HARD RULE, learned the expensive way: any worked examples you use to
calibrate your own tone/rigor are for your OWN internal reference — never
content for the deliverable report itself.** An early version of this skill
leaned on a prior worked example by name throughout a new report — "the same
principle as [prior system]'s X," "unlike [prior system]'s real drift
problem," an entire opening section framed as a comparison — and had to be
rewritten from scratch once caught: an independent review of someone else's
system should stand entirely on that system's own content, never compared to
or cross-referenced against any other system you've audited or built. Every
dimension's reasoning generalizes to a plain statement of the principle
itself (e.g., "a guardrail must not be overridable by the reasoning layer it
constrains," not "the same thing [other system]'s X does") — if a sentence
in the report names any comparison system, that sentence is wrong and needs
to be rewritten before the report ships, not after. **This means: get it
right on the first generation, not through a manual editing pass
afterward** — the skill should produce a clean report with confidence every
time, without needing a human to catch and hand-edit the same mistake
repeatedly.

## Step 1 — Get the target locally, read-only

- **Public GitHub repo (URL given):** `git clone --depth 50 <url>` into an
  isolated scratch directory, never inside an existing project. Depth 50 is
  enough for real git-log archaeology without a full clone; go deeper only
  if the repo's own history looks load-bearing (frequent, dated incident-
  documenting commit messages) and shallow history is visibly cutting off
  real signal.
- **Private repo:** `gh repo clone <owner>/<repo>` using your own existing
  GitHub auth — same idea, still fully local, nothing new gets exposed and
  nothing is uploaded to a third party. If `gh` isn't authenticated for that
  org, say so plainly rather than trying to work around it.
- **Local path already on disk:** just read it directly, no clone needed.
- **Never** paste target source into a third-party tool, SaaS, or web form to
  "run the audit" — the whole point of this mechanism is that analysis
  happens locally, against a local clone. If asked to keep a target's code
  from being exposed anywhere, a local clone deleted after the report is the
  actual answer, not a lighter-weight one.

Delete the clone when the report is delivered unless asked to keep it — it's
scratch, not a project.

**Run the mechanical pre-check now, before the judgment-based discovery
pass:** `node precheck.mjs <local-clone-path>` (ships alongside this file).
It reports real, cheap signals — git history depth, CI presence, AI/LLM
dependency hints, dated-incident-comment density, reasoning-architecture-
shaped filenames, a README deployed-system claim — and a
`suggested_maturity_mode` string. Treat that suggestion as a well-informed
hypothesis to confirm or overturn in Step 2 below, never as the verdict
itself — it's real signal, not a substitute for reading the actual code.
Tested against two structurally different real repos before being trusted;
two real bugs were found and fixed in the process (a `git log --reverse -1`
footgun that silently returned the newest commit instead of the oldest, and
a file-count cap that cut off the single most relevant file in a
1,300+-file repo before ever testing it) — see the script's own header
comments before trusting its output blindly on a new target.

## Step 2 — Discovery pass: which evidence tier is even reachable?

Before applying the rubric, work out what KIND of target this is. This
determines which stages can be code-verified vs. which can only be a design
review vs. which aren't assessable at all — forcing a code-verified score
onto a pre-build repo (or the reverse — treating a mature system's docs as
sufficient without checking the actual call sites) is the single biggest way
this audit goes wrong.

Ask, in order:
1. **Does this system have a live, running, production instance at all?**
   If no — no deploy target, no real users, no incident history — you're in
   **design-review mode**: score what real code exists (component inventory,
   test coverage, deploy/CI hygiene), and explicitly do NOT score stages that
   require live behavior (stress response) or a genuinely built reasoning
   layer (causal structure, calibration, guardrail wiring) — mark those
   "not assessable" or "design-reviewed only," never force a number.
   **"Not scored" is not the same as "no verdict," and must not collapse into
   silence.** Design quality is itself a real, evidence-based signal about how
   the later build is likely to go — not proof, but a genuine leading
   indicator worth stating plainly, not burying in neutral description. Name,
   explicitly, whichever of these actually shows up: internal consistency
   (does the design contradict itself anywhere), falsifiable specificity (are
   its own rules checkable, or just vague good intentions), whether it names
   its own open questions honestly instead of glossing over them, real
   scoping restraint (does it say no to things, defer correctly, avoid
   over-building), and whether its hard rules trace to a real, cited reason
   rather than being invented for their own sake. A design that shows several
   of these is a genuinely good sign and the report should say so directly —
   "unusually rigorous for this stage" is a real finding, not hedging. A
   design that's internally inconsistent, vague, or glosses over its own
   risks is an equally real, equally worth-stating negative signal. Either
   way, keep the epistemic line honest: a strong design predicts good
   execution, it doesn't guarantee it — say what the signal is and why it's
   a signal, not a promise.
2. **If it does have live behavior: does the codebase's own history/comments
   document real, dated incidents** ("real, live bug"-style comments with
   dates and root causes), or is incident history absent/undocumented? The
   former lets you verify claims directly against git archaeology; the
   latter means treating any "this survived a real incident" claim as
   unverified until you find independent evidence (a linked ticket, a test
   with a dated comment, anything checkable — not just prose asserting it
   happened).
3. **Does the system have any AI/LLM-touched decision surface at all?** Some
   targets (a lot of ordinary backend/product code) genuinely have none —
   say so and stop; this methodology exists for AI-touched judgment, not
   general code quality. Don't manufacture a Stage 2-6 finding out of a
   system that's fully deterministic end to end.

## Step 3 — The seven dimensions

Same rubric regardless of target. **Every dimension below is written as a
standalone principle — apply each one to the target's own content only.
Never write a report sentence that names another audited system, your own
projects, or any comparison target; state the principle itself instead.**

1. **Brittleness surface / Component Inventory** — is the decision-making
   logic explicit, typed, inspectable code (or a real config/rule table), or
   is it an LLM improvising every time with no structure underneath? Check
   real test coverage against the failure modes the code itself claims to
   handle, not just that tests exist.
2. **Causal/reasoning structure** — does the system maintain an explicit,
   small, sourced model of cause-and-effect (or equivalent decision logic),
   or does it regenerate reasoning-shaped prose per interaction? Check
   whether every reasoning-flavored output actually traces to something
   structured, not just whether the structure exists somewhere unused.
3. **Risk & failure-mode coverage** — are known failure modes named and
   handled (a real detector, a real fallback), or does the system silently
   fabricate/guess when data is missing? Independently brainstorm failure
   modes the system's own docs/comments DON'T name, and check whether
   anything catches them anyway — the gap between your own list and the
   system's own register is itself the finding.
4. **Reasoning depth & calibration** — for whatever "what happens if" or
   confidence-bearing logic exists: are confidence labels grounded in real
   data-quality signals, and is there any mechanism tracking whether high-
   confidence calls are actually right more often than low-confidence ones
   over time? (Almost always "no," even for mature, live systems generally
   — this is a close-to-universal gap in AI calibration approaches, not a
   defect specific to any one target. Don't penalize a target unusually
   hard for a near-universal gap; do still name it as its own finding.)
5. **Stress response** — inject or find real evidence of behavior under:
   latency/provider failure, stakes-differentiated fallback (does a
   degraded path get LESS authority, not the same authority with worse
   output), and a real "confounded/ambiguous evidence" event if one exists.
   Never inject live stress against a real production service without
   separate, explicit authorization — read code + existing incident
   evidence instead, and say so.
6. **Guardrail & agency** — does autonomy narrow automatically when evidence
   quality drops, and does a real human-override path exist AND have an
   actual operational entry point (not just a function that's never called
   from anywhere)? Grep every call site of any "override"/"restore"/
   "confirm" function directly — don't take a doc's word that a path exists.
7. **Deployment & Operational Integrity** *(added after a real audit missed
   a multi-day production blind spot — a background pipeline running a
   stale, undeployed copy of its own recently-fixed code, invisible to the
   first six dimensions because none of them test whether deployed code
   matches the repo at all — see the Changelog at the end of this file for
   the full incident, kept there rather than here on purpose)* — does every
   component with a real fix path (repo commit → live effect) have automated,
   verified deployment, or does it rely on someone remembering to re-run a
   script? Is there any drift-detection between repo HEAD and what's actually
   running, for every deployed component, not just the primary app? If a
   component is deliberately excluded from the main deploy pipeline for a
   real, stated reason, does that exclusion carry a substitute integrity
   check, or does the exclusion become the blind spot?

## Step 4 — Evidence discipline (non-negotiable)

- Every claim gets: **Claim → Test performed → Evidence (real file:line /
  commit hash / test name) → Falsification condition (what would have
  proven this wrong) → Verdict.**
- State single-reviewer status plainly. Don't imply adversarial review
  happened if it didn't.
- Never compute a weighted score across stages that are on different
  evidence tiers (code-verified vs. design-reviewed-only vs. not-assessable)
  — averaging across tiers manufactures a false sense of precision; don't
  produce a number just because the report template has a slot for one.
- A claim in a doc/comment with no independently-checkable artifact (no
  commit, no linked ticket, no test) is **claimed, not confirmed** — say so,
  don't silently treat prose as evidence the way you'd treat a grep result.
- Every report **expires** on stated triggers (a named file/function
  changing, a stated time horizon, a new incident) — write the trigger list,
  don't leave the report open-ended.

## Step 5 — Report structure

Section order: Cover → Executive Verdict → Scope → Score Card → Stage
Findings (one subsection per dimension, Claim/Test/Evidence/Falsification/
Verdict each) → Stress Test Results (if assessable) → Remediation Roadmap
(Priority/Finding/Recommendation/Status table) → Provenance Appendix (an
ID'd table of every source used) → Certification (signed, dated, with
expiry triggers) → **Methodology note** (its own final section, every
report, not optional): one short paragraph — "Produced using the One
Degree Antifragility Audit methodology
(https://theonedegreedispatch.com/antifragility-audit). Methodology and
tooling: PATENT PENDING | U.S. Provisional Patent Application No.
64/132,274. Tool licensed under Apache License 2.0 — see LICENSE and
NOTICE." This
belongs in the `.md` itself, not just the PDF wrapper's footer — the `.md`
gets sent and read standalone often enough that it needs its own copy. Add a short framing note up front whenever the target's
maturity mode changes what "scored" even means for this pass (e.g., a
pre-build target where most dimensions can only be design-reviewed, not
code-verified) — don't bury that in the verdict prose, and don't frame it
as a comparison to any other target; frame it entirely in terms of what
THIS target's own maturity stage makes assessable.

**Before delivering: re-read the finished report once, specifically
scanning for any sentence that names a system other than the one being
audited.** If one is found, rewrite it as a standalone statement of the
underlying principle before the report goes out — this check belongs in
the drafting pass, not as a fix applied after the fact.

## Step 6 — Adversarial verification (default ON, not optional)

A single-reviewer self-audit — the same session drafting a finding and
judging its own quality — is a real, disclosed limitation, not a
structural necessity. There's nothing stopping a genuine second pass; build
it in.

**Mechanism:** after Step 5 produces a draft, dispatch an independent
reviewer — a fresh Agent call with NO access to this session's reasoning or
conclusions, only the target's location and a specific claim to test — for
each load-bearing Stage Finding (at minimum: every "confirmed"/code-verified
verdict, and any "strong design signal" verdict driving the Executive
Verdict). Instruct the reviewer explicitly to try to REFUTE the claim, not
confirm it — re-read the same file(s), re-run the same test if there is one,
and report whether the evidence actually supports the verdict or is weaker/
stronger/wrong. Never show the reviewer this session's own verdict or
reasoning before it forms its own — that's the whole point of independence.

**On a refutation:** don't quietly keep the original verdict. Downgrade the
confidence, rewrite the finding to reflect what actually held up, or drop it
outright if the reviewer is right — the report's job is to be correct, not
to protect a draft. Log what got refuted and why in the Certification line,
the same way single-reviewer status used to be logged.

**On confirmation:** the Certification line changes from "no adversarial
review" to "adversarially verified — N of M load-bearing findings
independently re-checked, 0 refuted" (or however many were, honestly). This
is a genuinely stronger report than a single-reviewer pass, and the
Certification should say so plainly, not just drop the caveat silently.

**Cost/scope note:** this is a real cost (one extra Agent call per
load-bearing finding, more for a report with many), not free. For a quick,
low-stakes look, a single-reviewer pass with the disclosure intact is a
legitimate, honestly-labeled choice — just don't let that become the silent
default for a report meant to carry real weight. When in doubt, run it;
the Certification line is where the difference actually shows up to a
reader deciding how much to trust the report.

## Delivering the report

Write the `.md` to scratch space first, not into the target's own repo
(it's an external/read-only pass unless you're auditing your own system and
explicitly want it committed there). **Then always also produce a branded
PDF:** `node render-pdf.mjs <report.md> [output-basename]` (ships alongside
this file). Requires Playwright (falls back to `weasyprint` if unavailable;
fails loud with install instructions if neither is — never silently ships a
worse-looking PDF without saying so). Verify the PDF looks right before
sending — render a page or two to an image and actually look at it, don't
assume the renderer worked just because the process exited 0.

Send both files — the `.md` for anyone who wants to grep/diff citations
directly, the `.pdf` for anything presentable.

## Maintaining this skill (standing instruction, not a one-time task)

Keep this skill updated with real improvements on an ongoing basis, not just
once. There is no automated way to detect a "methodology improvement"
independent of an actual audit surfacing one — that's a judgment call by
construction. What's actually buildable, and what this section commits to:
**whenever running this skill surfaces a genuine gap or fix in the
METHODOLOGY itself — not just a target-specific finding — update this
SKILL.md (and `precheck.mjs`, if the fix is mechanical) directly, in that
same session, before delivering the report.** This is exactly how the 7th
dimension and both `precheck.mjs` bugs got added — a real audit run found
each one, and the fix went back into the tool immediately rather than
staying a one-off note in a single report. Don't wait to be asked a second
time.

When updating: add a dated entry to the Changelog below with what changed
and the real evidence that prompted it (a target audited, a bug found, an
incident) — same citation discipline as everything else in this skill. Never
silently rewrite prior guidance without a trail; if something in an earlier
version turns out to be wrong, say so in the new entry rather than quietly
deleting it.

### Changelog

- **2026-08-14** — Skill created, generalizing a worked methodology after two
  real audits: one mature, live production system, and one external pre-build
  pass (governance docs only, no AI layer shipped yet). The pre-build pass is
  why Step 2 (maturity-gated evidence tiers) exists — applying a mature
  system's rubric directly to a pre-code repo would have manufactured a
  false score.
- **2026-08-14** — Added the 7th dimension, Deployment & Operational
  Integrity, after a real audit found (one day post-publication) a real
  multi-day production blind spot — a background pipeline running a stale,
  undeployed copy of its own recently-fixed code — that none of the original
  six dimensions would have caught even if it had been in scope.
- **2026-08-14** — Built `precheck.mjs`, a mechanical pre-check for Step 2,
  after correctly refusing to claim the discovery pass was "built" when it
  was actually just unverified prose guidance. Tested directly against both
  worked examples above; found and fixed two real bugs before trusting it:
  (1) `git log --reverse --format=%aI -1` silently returns the newest
  commit's date, not the oldest, under this git version's `-1`/`--reverse`
  interaction — fixed by piping through `head -1` instead; (2) an initial
  500-file cap on the incident-comment scan cut off the single most relevant
  file in a 1,300+-file repo before ever testing it, because the directory
  walk's traversal order isn't size/relevance-sorted — fixed by scanning
  every matched file and only warning (not silently truncating) past a much
  higher sanity threshold.
- **2026-08-14** — Fixed a real leak: an early report generated from this
  skill named/compared to a prior worked-example system throughout — an
  entire opening section framed as a structural comparison, findings written
  as "the same principle as [that system]'s X," "unlike [that system]'s real
  drift problem." Caught and correctly rejected as a hand-edited fix: the
  skill itself, not just the one report, needed to stop producing this, so a
  future run doesn't repeat the mistake. Root cause: the worked-example
  references at the top of this file (meant for the auditor's own tone/rigor
  calibration) were sitting too close to the actual dimension-scoring
  instructions in Steps 2/3/4/5, so they leaked into drafted findings
  instead of staying background context. Fix: added a HARD RULE right after
  the worked examples, stripped comparison-system references out of every
  dimension description and step instruction (kept only in this Changelog
  and the intro's origin note, both clearly separated from active
  report-drafting instructions), and added an explicit pre-delivery
  self-check to Step 5 (re-read the finished report once, scanning
  specifically for any sentence naming another system). The goal stated
  directly: the skill should produce a clean report with confidence on the
  first generation, not rely on a human catching and hand-editing the same
  class of mistake every time.
- **2026-08-14** — A "not scored" design-review verdict was reading as too
  neutral, effectively burying whether a strong pre-build design is itself a
  real, meaningful signal about how the later build is likely to go. Fixed
  in Step 2's design-review-mode branch: "not scored" no longer means "no
  verdict" — the skill now names specific signals to check for (internal
  consistency, falsifiable specificity, honestly-named open questions, real
  scoping restraint, hard rules traced to a real reason) and states directly
  whether a design shows them, while keeping the epistemic line honest (a
  strong design predicts good execution, it doesn't guarantee it). Verified
  by drafting a fresh report against this version of the rule before
  shipping the fix.
- **2026-08-14** — Fair follow-up question, reading a report's own
  Certification line: "why isn't adversarial review run?" Correct — every
  report to this point was single-reviewer by construction (honestly
  disclosed, but never actually built as a real second-pass step). Added
  Step 6: dispatch an independent Agent, with no access to this session's
  reasoning, to try to REFUTE each load-bearing finding directly against the
  repo. Tested live before writing this entry — the first real run
  immediately found two genuine issues a single-reviewer pass had missed: a
  reproducible silent-failure path (a zero-denominator division producing
  NaN that slipped past the module's own conflict-flagging checks) and a
  real internal-consistency error in the target's own governance docs (a
  decision classified as requiring AI judgment whose own governing rules
  explicitly forbid judgment). Both findings were corrected in the report
  rather than left as originally drafted — proof this step earns its cost,
  not just a theoretical improvement.
- **2026-08-14** — Added `render-pdf.mjs`: every report now ships as a
  branded PDF alongside the `.md`, styled from the real public methodology
  page's own design tokens. Playwright primary, weasyprint fallback, loud
  failure with install instructions if neither is available. Found and
  fixed a real portability bug before trusting it: Playwright installed
  only globally is invisible to plain ESM `import("playwright")` even with
  `NODE_PATH` set — fixed by resolving npm's global root at runtime and
  `require()`-ing from there via `createRequire`. Verified by rendering a
  real report end to end and visually checking the output, not just
  checking the process exited 0.
- **2026-08-14** — This tool is now open-sourced (Apache License 2.0 —
  chosen specifically for the patent grant + retaliation clause in Section
  3, given the active patent application) and intended to be commercialized
  separately via services (training, educational content) layered on top.
  Added `LICENSE` (standard Apache 2.0 text) and `NOTICE` (patent-pending
  disclosure plus the trademark boundary: the code is Apache-licensed, the
  brand name is not). Added the same patent/license/methodology-link notice
  to every generated report via `render-pdf.mjs`'s branded template and a
  Methodology Note section in the `.md` itself.
- **2026-08-14** — Correction: the patent has two named co-inventors, not
  one. Fixed `LICENSE`/`NOTICE`'s copyright and "filed by" lines
  accordingly. Independently verified against the actual official USPTO
  Provisional Application Cover Sheet (PTO/SB/16) for this exact
  application, not just taken on the reporting party's word — its own
  INVENTOR(S) table lists exactly two names, matching what's now in
  `LICENSE`/`NOTICE`.