pre-mortem — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited pre-mortem (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
Write incident reports for bugs that haven't happened yet. Read working code and identify where future edits will plausibly introduce failures.
This is NOT a linter. NOT a code review. This is a predictive failure analysis — imagining realistic future scenarios where reasonable edits break working code. The output is written in past tense ("What happened", "Why it broke") to force complete causal chains instead of vague warnings.
Ask: "Which area should I pre-mortem?" or infer from context.
Scope options:
Read the target code. Max 5 files for File/Feature scope. For System scope, work module by module.
For each code area, check these 12 fragility patterns:
| Pattern | What to Look For |
|---|---|
| Implicit ordering | Code that works only because steps happen in a specific order, with no enforcement |
| Shared mutable state | Globals, module-level dicts, class variables mutated by multiple callers |
| Stringly-typed contracts | String comparisons for control flow (if status == "active") |
| Baked-in data assumptions | Hardcoded column names, assumed data shapes, magic indices |
| Coincidental correctness | Code that produces right answers for current data but wrong for edge cases |
| Non-atomic operations | Multi-step mutations that can leave state inconsistent if interrupted |
| Invisible invariants | Rules that must hold but aren't enforced (e.g., "X must be called before Y") |
| Load-bearing defaults | Default values that silently mask failures instead of surfacing them |
| Implicit resource lifecycles | Files, connections, locks that depend on call order for cleanup |
| Version-coupled assumptions | Code that breaks when a dependency updates (API version, schema change) |
| Silent None propagation | Functions that return None on failure where callers expect values |
| Train/inference skew | ML paths where training and prediction use different preprocessing |
For each fragility found (max 7 per analysis), write a realistic incident report:
### Incident: [Short title]
**Severity:** P0 / P1 / P2 / P3
**Fragility Pattern:** [from table above]
**File(s):** [paths]
**What happened:** [Past tense — describe the plausible future scenario]
A developer added multi-field validation to the form processor. Each invalid field
now generates a separate error record. The success_rate metric divided total_records
by error_count, assuming one error per row. With multiple errors per row, the
denominator inflated, dropping the reported success rate from 94% to 61%.
**Why it broke:** [Root cause chain]
The success_rate calculation in metrics.py:47 assumed a 1:1 relationship between
rows and errors. This assumption was never documented or enforced. The validation
change was reasonable and passed all existing tests.
**How it was caught:** [Realistic detection path]
An A/B test showed a 30% drop in the success metric. The on-call engineer traced it
to the validation change merged 3 days prior.
**Hardening suggestion:** [Specific, minimal fix]
Add assertion: `assert error_count <= total_records` in metrics calculation.
Or: normalize by unique row IDs, not raw error count.Write all incidents to PRE-MORTEM.md (or .planning/PRE-MORTEM.md if that directory exists) with:
| Finding | Route To |
|---|---|
| P0 fragility in production code | Flag to the user immediately — potential current risk |
| P1-P2 fragilities | Add to a tracked "hardening backlog" (e.g., a TODO/backlog doc) |
| Pattern appears across 3+ files | Capture it as a systemic insight in your durable notes — it's bigger than one file |
| ML train/inference skew detected | Pair with a domain expert review before deploying the model path |
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.