You are the skill evolution engine. You read development cycle analysis (/recall output) and quality metrics (/metrics output), then patch skill instructions to prevent recurring issues.
Do NOT ask the user questions. Analyze findings and apply patches autonomously.
ARGUMENTS: $ARGUMENTS
- If arguments contain
--dry-run, show proposed patches WITHOUT applying them. - Otherwise, apply patches normally.
CONSTRAINTS:
- Maximum 3 skills patched per run (keep changes reviewable)
- Patches are ADDITIVE only (add checklist items, add phases, add gates)
- Never delete existing skill instructions
- Never modify skill names or descriptions
- Every patch must be justified by a specific finding
- Bump the version number of any modified skill (if it has one)
============================================================ PHASE 1: GATHER FINDINGS
- Auto-detect the project's memory directory by searching:
.claude/projects/directories matching the current project path~/.claude/projects/directories (replacing path separators with-)- The project root for any
MEMORY.md
- In the memory directory, look for:
recall-*.mdfiles (development cycle analysis)MEMORY.md(project memory with metrics baseline and debt items)- Any
*-metrics-*.mdor*-recall-*.mdfiles
- Search for metrics snapshots:
- Check the memory directory for
metrics-*.mdfiles - Check sibling directories of the memory directory for metrics data
- Check for any
metrics/subdirectory in the project
- Check the memory directory for
- If no recall/metrics data exists, run the analysis:
- Execute
git logcommands to get commit data - Classify commits by type and skill signature
- Identify rework patterns (fix commits following feat commits)
- Execute
- Extract actionable findings:
- Root causes of rework (from recall "What caused unnecessary rework" section)
- Metrics that regressed or missed targets
- Rework hotspots and their causes
- Pipeline execution gaps (skipped/reordered steps)
============================================================ PHASE 2: MAP FINDINGS TO SKILLS
For each finding, determine which skill(s) should be patched.
Use the pattern categories below. These are tech-stack-agnostic — adapt the specific checklist items to whatever stack the project uses.
| Finding Category | Target Skill | Patch Type |
|---|---|---|
| Missing error handling / defensive coding | /iterate |
Add error-handling checklist for the detected stack |
| Accessibility added as afterthought | /iterate |
Add a11y requirement to component/screen creation |
| Unbounded queries or missing pagination | /iterate |
Add query-safety checklist (limits, cursors, indexes) |
| Missing idempotency in async jobs | /iterate |
Add idempotency checklist for the job/worker framework |
| Too many QA passes (>2) without convergence | /qa |
Add "route upstream after 2 rounds" instruction |
| Performance/scale issues found late | /iterate |
Add perf checklist (N+1, caching, lazy loading) |
| Design/theme inconsistency | /iterate |
Add design-token-first requirement |
| Schema/data-model churn | /arch-review |
Add schema design phase before implementation |
| Domain inconsistencies across layers | /analyze |
Add cross-layer naming/contract checks |
| Missing cleanup/disposal of resources | /iterate |
Add resource lifecycle checklist (connections, listeners, timers) |
| Security issues found late | /iterate |
Add security checklist (input validation, auth checks, secrets) |
| Tests written in batch after features | /iterate |
Add "test with feature" co-commit requirement |
| Dead code / orphaned files accumulating | /iterate |
Add cleanup step to feature completion |
| Missing input validation | /iterate |
Add validation checklist for API/form inputs |
Prioritize by impact: patches that prevent the most rework commits come first.
============================================================ PHASE 3: GENERATE PATCHES
For each patch (max 3):
- Read the current SKILL.md file for the target skill.
- Identify WHERE to insert the new content:
- Checklists: add to existing checklist section or create one
- Phase instructions: add to the relevant phase
- Gates: add between existing phases
- Generate the patch content:
- Use the same formatting style as the existing skill
- Reference the finding that justifies the patch
- Keep additions concise (3-10 lines per patch)
- If
--dry-runmode:- Show the proposed diff (before/after) for each patch
- Show which file would be modified and where
- Do NOT apply any changes
- Skip Phase 4 (logging)
- Output the report and stop
- If normal mode:
- Apply the patch using the Edit tool
- Bump the version number in the skill header (if present)
============================================================ PHASE 4: LOG CHANGES
Skip this phase entirely if --dry-run was specified.
Append to
~/.claude/skills/CHANGELOG.md:## {date} ### {skill name} v{old} -> v{new} **Triggered by:** {project name} /recall analysis **Finding:** {specific finding from recall} **Patch:** {what was added/changed}Update the project's MEMORY.md to note which skills were evolved:
## Last /evolve Run ({date}) - Patched: /iterate v4 -> v5 (added error-handling checklist) - Patched: /qa v3 -> v4 (added upstream routing)If a sync/backup script exists at
~/.claude/scripts/sync-backup.sh, run it. Otherwise, skip this step silently.
============================================================ SELF-HEALING VALIDATION (max 2 iterations)
After producing output, validate data quality and completeness:
- Verify the analysis consumed sufficient data.
- Verify all output sections have substantive content (not just headers).
- Verify recommendations are actionable and reference specific evidence.
IF VALIDATION FAILS:
- Identify data gaps and attempt alternative data sources
- Re-generate incomplete sections with expanded analysis
- Repeat up to 2 iterations
============================================================ OUTPUT
Skill Evolution Report
Mode: {normal | dry-run}
Findings Analyzed
| # | Finding | Source | Impact (est. fix commits prevented) |
|---|
Patches {Applied | Proposed (dry-run)}
| Skill | Version | Patch Summary | Justified By |
|---|
Patch Details
For each patch, show the before/after diff of the skill file.
Deferred Findings
Findings that could not be addressed by skill patches (need architectural changes, etc.)
NEXT STEPS:
- "Run the patched skills on your next project to validate improvements."
- "Run
/metricsafter the next project to measure impact." - "Run
/promoteto check if these patterns should be global."
============================================================ SELF-EVOLUTION TELEMETRY
After producing output, record execution metadata for the /evolve pipeline.
Check if a project memory directory exists:
- Look for the project path in
~/.claude/projects/ - If found, append to
skill-telemetry.mdin that memory directory
Entry format:
### /evolve — {{YYYY-MM-DD}}
- Outcome: {{SUCCESS | PARTIAL | FAILED}}
- Self-healed: {{yes — what was healed | no}}
- Iterations used: {{N}} / {{N max}}
- Bottleneck: {{phase that struggled or "none"}}
- Suggestion: {{one-line improvement idea for /evolve, or "none"}}
Only log if the memory directory exists. Skip silently if not found. Keep entries concise — /evolve will parse these for skill improvement signals.