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).
97 lines
2.3 KiB
Markdown
97 lines
2.3 KiB
Markdown
# 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
|
|
|
|
```markdown
|
|
# 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
|
|
|
|
1. Proposal created in `pending/`
|
|
2. Orchestrator presents to user at a natural stopping point
|
|
3. Human reviews and decides: APPROVE, REJECT, or MODIFY
|
|
4. If approved: implement the change, move to `applied/`
|
|
5. If rejected: move to `rejected/` with reason
|
|
6. 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
|