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).
58 lines
1.2 KiB
Markdown
58 lines
1.2 KiB
Markdown
---
|
|
name: incident-investigation
|
|
description: Incident investigation — structured response to production or system incidents
|
|
version: "1.0"
|
|
owner: Detective
|
|
prerequisites: incident reported, system accessible
|
|
---
|
|
|
|
# Incident Investigation
|
|
|
|
## When to use this skill
|
|
|
|
- A production system is failing
|
|
- Users are reporting issues
|
|
- Monitoring alerts are firing
|
|
|
|
## Step-by-step procedure
|
|
|
|
### 1. Triage
|
|
- How severe is the incident?
|
|
- What is the current impact?
|
|
- Is it getting worse?
|
|
|
|
### 2. Stabilize
|
|
- Can we restore service quickly?
|
|
- Is there a safe rollback?
|
|
- What is the minimal fix?
|
|
|
|
### 3. Investigate
|
|
- Use systematic debugging methodology
|
|
- Collect evidence while the incident is live
|
|
- Note timeline of observations
|
|
|
|
### 4. Resolve
|
|
- Apply the fix
|
|
- Verify the fix works
|
|
- Monitor for regression
|
|
|
|
### 5. Review
|
|
- Document what happened
|
|
- Identify root cause
|
|
- Propose prevention measures
|
|
- Record in `memory/failures/`
|
|
|
|
## Common pitfalls
|
|
|
|
- Jumping to fix without understanding
|
|
- Not collecting evidence during the incident
|
|
- Blaming individuals instead of processes
|
|
- Not following up on prevention
|
|
|
|
## Exit criteria
|
|
|
|
- Service restored
|
|
- Root cause identified
|
|
- Prevention measures proposed
|
|
- Incident recorded in memory
|