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).
Improvement Proposals
Controlled self-improvement for the agent team. No autonomous modification of core agent behavior without human approval.
Structure
improvements/
├── README.md # This file
├── pending/ # Proposals awaiting approval
│ └── YYYY-MM-DD_<id>.md
├── applied/ # Approved and implemented proposals
│ └── YYYY-MM-DD_<id>.md
└── rejected/ # Rejected proposals (kept for reference)
└── YYYY-MM-DD_<id>.md
Proposal format
# IMPROVEMENT-NNNN: <title>
Date: YYYY-MM-DD
Proposed by: <agent>
Status: PENDING | APPROVED | REJECTED | APPLIED
## Observed problem
<what was noticed — repeated failure, inefficiency, missing capability>
## Evidence
<supporting evidence — failure records, metrics, examples>
## Root cause
<why this problem exists>
## Proposed change
<what specifically should change>
## Affected agents/skills
<which agents or skills would be modified>
## Risks
<what could go wrong>
## Expected benefit
<what improvement this would produce>
## Verification plan
<how to verify the change works as intended>
## Approval
- [ ] Human review
- [ ] Impact assessment
- [ ] Rollback plan
How proposals are generated
At the end of substantial work, the Orchestrator (or any agent) may create a proposal when it detects:
- Repeated failures of the same type
- Inefficient workflows that waste agent resources
- Missing skills that would prevent a class of problems
- Missing tests that would catch regressions
- Documentation gaps that cause confusion
- Architecture problems that slow down development
- Poor agent delegation patterns
How proposals are processed
- Proposal created in
pending/ - Orchestrator presents to user at a natural stopping point
- Human reviews and decides: APPROVE, REJECT, or MODIFY
- If approved: implement the change, move to
applied/ - If rejected: move to
rejected/with reason - If modified: create a new proposal with the modification
Rules
- Never modify core agent behavior without approval
- Never modify the orchestrator's decision logic without approval
- Never add new agents without approval
- Always preserve backward compatibility
- Always include a rollback plan
- Always document what was changed and why