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).
63 lines
1.6 KiB
Markdown
63 lines
1.6 KiB
Markdown
---
|
|
name: refactoring
|
|
description: Refactoring principles — improving code structure without changing behavior
|
|
version: "1.0"
|
|
owner: Builder + Maintainer
|
|
prerequisites: 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
|