Files

T

Your Name 2dabf8ef03 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).

2026-09-08 04:31:40 -04:00

1.6 KiB

Raw Blame History

name, description, version, owner, prerequisites

name	description	version	owner	prerequisites
refactoring	Refactoring principles — improving code structure without changing behavior	1.0	Builder + Maintainer	tests exist and pass, behavior is well-understood

Refactoring

When to use this skill

Code works but is hard to understand or maintain
Duplication exists that should be extracted
Naming is unclear or misleading
Structure doesn't match the conceptual model

Core principle

Refactoring changes structure, not behavior. If you don't have tests, write them first. If you can't verify behavior is preserved, don't refactor.

Step-by-step procedure

1. Verify baseline

Run the full test suite
Confirm all tests pass
Note the test output (baseline for comparison)

2. Identify the refactor

What specific structural improvement?
What is the expected benefit?
Is this the smallest useful refactor?

3. Make the change

One small step at a time
Run tests after each step
If tests fail, revert and try a smaller step

4. Verify

Run the full test suite again
Compare output to baseline
Verify no behavior change

5. Document

Note what was refactored and why
Update relevant documentation if public interfaces changed

Common pitfalls

Refactoring while fixing a bug (mixes two changes)
Not having tests before refactoring
Making large changes in one step
Renaming things that don't need renaming
"While I'm here" scope creep

Exit criteria

Full test suite passes
No behavior change (same inputs, same outputs)
Code is clearer/simpler than before
Change is small enough to review

1.6 KiB Raw Blame History