Your Name
2dabf8ef03
- memory/: cross-session project memory with decisions, lessons, failures, architecture, and sessions categories. Each has format templates and lifecycle documentation. - skills/: 12 reusable specialized methodologies (tdd, systematic-debugging, architecture-design, code-review, security-review, repository-analysis, failure-analysis, refactoring, test-analysis, incident-investigation, browser-automation, research). Each has frontmatter and methodology sections. - improvements/: proposal-based improvement system requiring human approval. - scripts/memory-lifecycle.sh: deterministic memory operations (recall, store, list, search, sessions, cleanup). - scripts/test-memory-system.sh: 12 structural tests for all new systems. - orchestrator.md: added Memory Recall stage, Learning and Memory Storage stage, Improvement Proposals workflow, memory/skills rules, and 3 new actions (A23-A27) to the action catalog. Updated behavioral acceptance test and state separation model. - All 12 subagents: added Memory & Skills Awareness sections with recall and store instructions. - docs/AGENT_ARCHITECTURE.md: documented memory, skills, and improvements systems (sections 12-14). Updated action count (27), state model, and remaining weaknesses. - README.md: documented new systems, updated repository layout, added test-memory-system.sh documentation. All 39 tests pass (16 architecture + 12 memory + 11 bootstrap).
70 lines
1.9 KiB
Markdown
70 lines
1.9 KiB
Markdown
---
|
|
name: failure-analysis
|
|
description: Failure analysis methodology — analyzing system failures to identify patterns and prevent recurrence
|
|
version: "1.0"
|
|
owner: Detective
|
|
prerequisites: failure observed, evidence available
|
|
---
|
|
|
|
# Failure Analysis
|
|
|
|
## When to use this skill
|
|
|
|
- A failure has occurred and needs to be understood
|
|
- Recurring failures need pattern analysis
|
|
- Post-incident review is needed
|
|
|
|
## Step-by-step procedure
|
|
|
|
### 1. Collect evidence
|
|
- Gather all available evidence: logs, error messages, stack traces
|
|
- Note the timeline: when did it start, what changed
|
|
- Identify affected components and users
|
|
|
|
### 2. Classify the failure
|
|
- **Type**: tool / environment / assumption / plan / implementation / test / coordination
|
|
- **Severity**: critical / high / medium / low
|
|
- **Scope**: isolated / widespread
|
|
- **Frequency**: one-time / recurring
|
|
|
|
### 3. Root cause analysis
|
|
- Use the systematic debugging skill for individual failures
|
|
- For patterns: look across multiple failure records
|
|
- Ask: "What condition must be true for this failure to occur?"
|
|
|
|
### 4. Impact assessment
|
|
- What was the actual impact?
|
|
- What was the potential impact?
|
|
- Were there cascading effects?
|
|
|
|
### 5. Resolution
|
|
- How was it resolved (or is it still open)?
|
|
- Was the resolution verified?
|
|
- Are there residual risks?
|
|
|
|
### 6. Prevention
|
|
- What prevents this specific failure from recurring?
|
|
- What prevents the class of failures from recurring?
|
|
- Should a Toolsmith safeguard be created?
|
|
- Should a test be added?
|
|
|
|
## Common pitfalls
|
|
|
|
- Stopping at the symptom (not the cause)
|
|
- Blaming individuals instead of processes
|
|
- Documenting the fix without documenting the prevention
|
|
- Not checking for similar patterns elsewhere
|
|
|
|
## Evidence requirements
|
|
|
|
- Complete failure record in `memory/failures/`
|
|
- Root cause with evidence
|
|
- Prevention measures with verification
|
|
|
|
## Exit criteria
|
|
|
|
- Root cause identified
|
|
- Resolution verified
|
|
- Prevention documented
|
|
- Related failures checked for patterns
|