Phase 1-3: Add memory, skills, and improvement systems

- 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).

skills/failure-analysis/SKILL.md

@@ -0,0 +1,69 @@
+---
+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