Failure logging
Use when recording AI workflow failures, reviewing failure patterns, or applying the three-occurrence rule. Provides drift category codes and structured failure capture guidance.From its SKILL.md
npx -y skills add crowcreation/nexus --skill failure-loggingAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
3.4 KB, as published. Nobody here has run it
Drift Categories (optional)
Categories are an opt-in vocabulary, never a requirement. The day-one failure log is a plain date-and-root-cause line with no category at all, and most logs never need more than that. Reach for these codes only once your own entries ask for a shorthand — when the same kinds of failure keep recurring and grouping them helps. Do not impose them up front.
When you do choose to categorise, use one of these seven:
| Code | Category | What it means | Diagnostic question |
|---|---|---|---|
| SS | State Staleness | Acted on information that was true when cached but isn't anymore | "Was the data I used still current?" |
| CF | Context Fragmentation | Knowledge from one session never reached another | "Did another session or person already handle this?" |
| ID | Instruction Decay | Rules exist but weren't loaded or were contradicted by newer rules | "Is there a rule for this that I missed or that conflicts?" |
| DF | Discovery Failure | Built something that already existed because it wasn't discoverable | "Does this already exist somewhere I didn't check?" |
| CO | Coordination Failure | Multiple agents/processes individually correct, globally inconsistent | "Did different parts of the system make incompatible assumptions?" |
| FL | Feedback Loss | Learned from a failure but didn't encode the lesson durably | "Have I seen this before and failed to write it down?" |
| UN | Uncategorised | Doesn't fit the above categories | "Review weekly — 3+ UN entries with similar causes may indicate a new category" |
The Three-Occurrence Rule
When the same root cause appears 3 times in the failure log, it's no longer a one-off mistake — it's a system bug. The system is missing a preventive rule.
At 3 occurrences:
- Stop treating it as individual failures
- Write a preventive rule (a CLAUDE.md entry, a hook, a checklist item, or a process change)
- Record the rule in the failure log's "Preventive rule" column
The rule doesn't need to be perfect. It needs to exist. A rough rule that catches 80% of recurrences is better than no rule that catches none.
Severity
Each failure entry records blast radius:
| Value | Meaning |
|---|---|
| CONTAINED | Caught before affecting external output |
| EXTERNAL | Affected a client, published output, or downstream system |
Remediation Tracking
Each entry tracks progress from detection to enforcement:
| Status | Meaning |
|---|---|
| DETECTED | Failure recorded, no rule written yet |
| RULE WRITTEN | Preventive rule exists but not yet enforced automatically |
| ENFORCED | Rule is enforced via hook, gate, or automated check |
New entries start at DETECTED. Update the status as remediation progresses. The /status command surfaces failure-log patterns, including any root cause at three or more occurrences.
Writing Preventive Rules
Good preventive rules are:
- Specific: "Check HubSpot deal status before drafting follow-up email" not "be more careful"
- Automatable: Can be turned into a hook, a checklist, or a CLAUDE.md instruction
- Testable: You can tell whether the rule was followed or not
- Proportionate: The cost of the rule should be less than the cost of the failure recurring