| name | self-growth |
| description | Continuous learning framework โ learn from work, organize knowledge, build feedback loops. Use when: recording lessons, organizing knowledge, or setting up learning systems that persist across sessions. |
Self-Growth Framework
You're an agent that improves over time. Knowledge gained during work shouldn't vanish when a session ends โ it should accumulate into reusable assets. But be selective: only accumulate what's within your scope and genuinely reusable.
References
Load on demand โ not every invocation requires all of these:
Five-Step Flow
Task or knowledge comes in
โ
โ Scope check: Is this my responsibility?
โโโ No โ Hand off (explain why + suggest who + share what you know)
โโโ Yes โ
โก Learning filter: Is this worth recording? Will it come up again?
โโโ No โ Don't record (or just note in daily log)
โโโ Yes โ
โข Knowledge routing: Where does it go?
โโโ Operational rules (tool quirks, paths, gotchas) โ Lessons Learned in CLAUDE.md + memory_store dual-layer
โโโ Reusable knowledge (methods, domain expertise) โ knowledge/ (staging) โ playbooks/ (validated) โ skills/ (formal)
โโโ Update existing skill โ Direct update
โฃ Feedback loop: Am I improving?
โโโ Read growth-profile.md "growth signals" and compare against today's work
โโโ Detect: user corrections, task success rate, rework frequency (role-specific signals)
โโโ Recognize: cross-task patterns ("user keeps fixing my X" = persistent weakness)
โโโ Calibrate: is this learning aligned with growth direction (Phase 1โ2โ3)?
โค Reflection cadence: When do I do all this?
โโโ During daily reflection โ execute โ -โฃ together
โ Scope Check
Before acting on a task or recording knowledge, ask:
1. Is this within my defined responsibilities?
โโโ Clear yes โ proceed
โโโ Clear no โ hand off
โโโ Unclear โ keep checking
2. Does it require my specific expertise?
โโโ Yes โ likely mine
โโโ No โ likely someone else's
3. Will doing this pull me away from core duties?
โโโ Yes โ hand off
โโโ No โ proceed
4. Still unsure?
โโโ Ask manager or user
How to hand off well:
- Explain why: "This involves [X], which is outside my scope"
- Suggest who: "This should go to [person], because they own [Y]"
- Share context: Hand over any relevant information you already have
Don't: refuse without giving direction, push through poorly, or quietly log it into your own knowledge base (that pollutes your domain).
Edge Cases
- Cross-domain support: You can read knowledge from other domains to complete your own work โ but you don't maintain their knowledge bases.
- No clear owner: Judge who it's closest to; if unsure, ask manager.
- Urgent but out of scope: Hand off. You can help organize information, but the core work should go to the right person.
โก Learning Filter
Trigger this when you:
- Solve a tricky problem (will this recur?)
- Discover a better approach (method or one-off trick?)
- Complete a complex task (any reusable knowledge in the process?)
- Are about to write a Lessons Learned (is this an operational rule, or should it be a standalone methodology?)
- End a session (anything worth preserving?)
Routing Decision
What I learned
โ
โโโ Operational rule (how tools work, paths, gotchas)
โ โ CLAUDE.md Lessons Learned + memory_store dual-layer (fact + decision)
โ
โโโ Reusable knowledge (methodology, domain expertise)
โ โ knowledge/ โ playbooks/ โ skills/
โ
โโโ One-off, won't repeat
โ Don't record (or just daily log)
Lessons Learned Format
### YYYY-MM-DD: One-line description
Content description...
When writing to Lessons Learned, simultaneously memory_store with dual-layer storage (fact + decision).
Lessons Learned vs. Independent Skill
CLAUDE.md Lessons Learned holds operational rules only: how tools work, where paths are, what to do first.
Methodology/domain knowledge gets its own Skill: reusable ways of doing things, domain expertise.
Test: "Would this knowledge be useful in a different project?" Yes โ independent Skill. No โ Lessons Learned.
โข Knowledge Routing
| Type | Where | Naming convention |
|---|
| Research/reflection notes (staging) | knowledge/ | {domain}-{topic}-{aspect}.md |
| Validated methodology | playbooks/ | Proven through the full cycle, executable independently |
| Domain expertise | Knowledge Skill | knowledge-{domain} |
| Methodology | Method Skill | method-{topic} |
| Project decisions | Project Skill | proj-{project}-{topic} |
| Deliverables / analysis reports | output/ | output/{task-name}/ |
| Daily log | memory/ | memory/YYYY-MM-DD.md |
Knowledge Lifecycle
knowledge/ (staging: things learned, researched, still being digested)
โ validated through real use
playbooks/ (finalized: handoff-ready, executable independently)
โ when it needs to be embedded in the system, go through Layer 3 approval
.claude/skills/ (formal: capabilities bound to the system)
Promotion Signals
Proactively evaluate whether knowledge in knowledge/ is ready to be promoted:
- Same type of problem appears 3+ times
- Appears across 2+ different tasks or projects
Promotion path:
- Operational rule โ CLAUDE.md Lessons Learned
- Reusable methodology โ
knowledge/ โ playbooks/ โ skills/
When to Create a New Skill
- Enough content? โ At least 2โ3 related knowledge points
- Clear boundary? โ Scope is defined; you know what doesn't belong
- Correct naming? โ Follows convention (
knowledge-, method-, proj-)
โฃ Feedback Loop
Run during daily reflection. Read your workspace's growth-profile.md.
Three Steps
- Signal detection: Read the "growth signals" in
growth-profile.md, compare against today's work โ did any positive or warning signals appear?
- Pattern recognition: Look for trends across multiple tasks โ "user always revises my X" = persistent capability gap; "revision volume is clearly dropping" = improving
- Direction calibration: Align with growth direction (Phase 1โ2โ3) โ "Does this learning move me closer to the next phase?" If what you learned drifts from the direction, note it but don't force a correction (may be exploration)
Without a growth-profile.md
If your workspace has no growth-profile.md, skip this step. The feedback loop requires a manager to define growth signals before it can operate.
If no explicit growth goals exist, focus on:
- Reducing rework (fewer corrections from user)
- Increasing first-attempt success rate
- Expanding the situations you can handle independently
โค Reflection Cadence
During the daily reflection schedule, execute โ โโฃ together:
- Review today's tasks and learnings
- Check Lessons Learned and
knowledge/ โ are there recurring patterns ready to be promoted?
- Execute knowledge routing
- Execute feedback loop
- Log to
evolution/weekly/
Reflection Principles
- Synthesize, don't collect โ Don't repeat what happened during today's work; extract what matters
- Search when you find gaps โ When you discover a knowledge gap, actively search to fill it; don't just think about it
- Check against user expectations โ Use the "user expectations" section of CLAUDE.md as the baseline
- Record or it didn't happen โ Saying "I learned X" without writing it down = didn't learn
- "Nothing to note" is usually wrong โ Look harder; don't dismiss reflection with a one-liner
Red Lines
- Don't record everything โ One-off facts aren't worth the overhead. Be selective.
- Don't build catch-all containers โ Each skill/file should have clear scope. Don't dump everything in one place.
- Don't record outside your scope โ Valuable knowledge that's not your domain? Pass it to the right owner.
- Don't reinvent โ Check if an existing skill/file already covers this before creating new ones.
- Don't skip the filter โ Every piece of knowledge goes through โก. No exceptions.
- Don't modify Layer 3 files yourself โ Write a proposal to
evolution/proposals/ and wait for approval.
Manager Collaboration
- When scope is unclear: Proactively ask your manager to clarify the boundary.
- When you find a gray area: Report it to the manager and let them decide ownership.
- When creating a new Skill: Notify the manager so they know what you've accumulated.
- When growth direction is in question: Report to the manager; let them update the
growth-profile.