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/tdd/SKILL.md

@@ -0,0 +1,71 @@
+---
+name: tdd
+description: Test-Driven Development methodology — write tests first, implement to pass, refactor
+version: "1.0"
+owner: Builder + Tester
+prerequisites: test framework identified, build system working
+---
+
+# Test-Driven Development
+
+## When to use this skill
+
+- Implementing new functionality where correctness can be verified
+- Bug fixes where a regression test should exist
+- Any change where the expected behavior is well-defined
+
+## Core methodology
+
+```text
+RED    → write a failing test that captures the requirement
+GREEN  → implement the minimum code to make the test pass
+REFACTOR → improve the code while keeping all tests green
+```
+
+## Step-by-step procedure
+
+### 1. Understand the requirement
+- What behavior is expected?
+- What inputs produce what outputs?
+- What edge cases exist?
+- What error conditions should be handled?
+
+### 2. Write the test (RED)
+- Write the smallest test that captures one aspect of the requirement
+- Verify the test fails for the right reason (not a syntax error)
+- Run the test to confirm it fails
+
+### 3. Implement (GREEN)
+- Write the minimum code to make the test pass
+- Do not add behavior not captured by a test
+- Run the test to confirm it passes
+
+### 4. Verify (REFACTOR)
+- Run the full test suite (not just the new test)
+- Refactor if needed: extract methods, rename for clarity, remove duplication
+- Verify tests still pass after each refactor step
+
+### 5. Repeat
+- Return to step 1 for the next aspect of the requirement
+- Stop when all aspects are covered and tests pass
+
+## Common pitfalls
+
+- Writing tests after implementation (loses the design benefit)
+- Writing too many tests at once (harder to isolate failures)
+- Testing implementation details instead of behavior
+- Skipping the refactor step (technical debt accumulates)
+- Not running the full suite after changes
+
+## Evidence requirements
+
+- Test file with the new test(s)
+- Test output showing RED → GREEN progression
+- Full suite passing after completion
+
+## Exit criteria
+
+- All new tests pass
+- Full existing suite passes
+- Tests capture the behavior, not the implementation
+- Each test is independently runnable