菜单
Global evolution system for ship-faster skills. Uses hooks to capture context, failures, and session summaries, then generates patch suggestions (no auto edits) via skill-improver. Use when you want the skills to self-improve safely and continuously.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | skill-evolution |
| description | Global evolution system for ship-faster skills. Uses hooks to capture context, failures, and session summaries, then generates patch suggestions (no auto edits) via skill-improver. Use when you want the skills to self-improve safely and continuously. |
This skill makes the skills library evolve based on real development signals without auto-editing skills. The default output is a patch suggestion only.
Default hooks can only "log events" without automatically consolidating experience into skills.
The goal of this skill is to turn retrospectives into a fixed closing action:
skill-improver to generate minimal patch suggestions based on real run artifacts (still no auto-editing of skill library)skill-improver to propose a minimal patchHooks live in: ~/.claude/skills/skill-evolution/hooks/
Add to your global settings (or project settings) so hooks run automatically.
Example (merge into ~/.claude/settings.json or <project>/.claude/settings.json):
Configure behavior via ~/.claude/skills/skill-evolution/hooks/settings.json:
{
"min_fail_count": 2,
"ignore_tool_errors": true,
"noise_filters": {
"ignore_patterns": [
"typescript: type.*already exists",
"eslint:.*no-unused-vars.*react",
"prettier:.*prettier-ignore"
],
"max_failures_per_run": 20,
"recent_only": true,
"recent_window_minutes": 60
},
"output_format": {
"summary_only": false,
"include_context": true,
"include_recent_failures": 20,
"sort_by": "frequency"
}
}
Settings explanation:
min_fail_count: Minimum occurrences of a single error type before generating a candidateignore_tool_errors: Whether to ignore tool-level errors (vs user code errors)noise_filters.ignore_patterns: List of regex patterns to ignoremax_failures_per_run: Maximum failures to record per session (prevent explosion)recent_only: Only look at failures within recent time windowrecent_window_minutes: Only count failures within the last N minutesoutput_format: Controls evolution-candidates.md output format{
"hooks": {
"PreToolUse": [
{
"matcher": "Bash|Write|Edit",
"hooks": [
{
"type": "command",
"command": "bash ~/.claude/skills/skill-evolution/hooks/pre-tool.sh"
}
]
}
],
"PostToolUse": [
{
"matcher": "Bash",
"hooks": [
{
"type": "command",
"command": "bash ~/.claude/skills/skill-evolution/hooks/post-bash.sh \"$TOOL_OUTPUT\" \"$EXIT_CODE\""
}
]
},
{
"matcher": "Write|Edit",
"hooks": [
{
"type": "command",
"command": "bash ~/.claude/skills/skill-evolution/hooks/post-tool.sh \"$TOOL_OUTPUT\" \"$EXIT_CODE\""
}
]
}
],
"Stop": [
{
"matcher": "",
"hooks": [
{
"type": "command",
"command": "bash ~/.claude/skills/skill-evolution/hooks/session-end.sh"
}
]
}
]
}
}
Hooks write to project-local run folders:
<project-root>/runs/evolution/<run_id>/
logs/
events.jsonl
failures.jsonl
state.json
context.json
evolution-candidates.md
evolution-review.md
run_id is stored in <project-root>/runs/evolution/.current so all hooks in a session write to the same run.
When you have just completed a "deliverable big task" (e.g., you have already written final.md or filled the run’s tasks.md Delivery summary), you must do a brief retrospective when closing, and give the choice to the user.
In the conversation, ask only 3 questions (prefer multiple choice to reduce cost):
Do you want to optimize skills based on this run?
skill-improver first to generate minimal patch)What was the biggest blocker this time?
Which direction do you want to prioritize for optimization?
Execution rules:
skill-improver, only give run_dir path as input (don't paste logs into conversation)evolution-review.md (or corresponding workflow run's final.md / tasks.md), process collectively next timeevolution-candidates.md + evolution-review.md with the latest signals.skill-improver with the best run_dir (the workflow run_dir is usually better than evolution run_dir).{"ts":"2026-01-11T12:00:00Z","event":"post-bash","category":"build","exit_code":1,"summary":"next build failed: Module not found","artifacts":["logs/failures.jsonl"]}
evolution-candidates.md (auto-generated)evolution-review.md (auto-generated, includes the 3 questions)skill-improver (manual apply)No skills are edited automatically.
Analyze code quality based on "Clean Code" principles. Identify naming, function size, duplication, over-engineering, and magic number issues with severity ratings and refactoring suggestions. Use when the user requests code quality checks, refactoring advice, Clean Code analysis, code smell detection, or mentions terms like code review, code quality, refactoring check.
Documentation consistency reviewer that checks alignment between code implementation and documentation. Use when user requests reviewing documentation vs code consistency, checking if README/docs are outdated, verifying API documentation accuracy. Applicable for (1) reviewing README vs implementation consistency (2) checking if docs/ directory content is outdated (3) verifying API/config documentation accuracy (4) generating documentation consistency reports. Trigger words include doc review, documentation consistency, check outdated docs, verify docs.
Request/execute structured code review: use after completing important tasks, at end of each execution batch, or before merge. Based on git diff range, compare against plan and requirements, output issue list by Critical/Important/Minor severity, and provide clear verdict on merge readiness. Trigger words: request code review, PR review, merge readiness, production readiness.
Execute written implementation plans: first read and critically review the plan, then implement in small batches (default 3 tasks), produce verification evidence per batch and pause for feedback; must stop immediately and ask for help when blocked/tests fail/plan unclear. Trigger words: execute plan, implement plan, batch execution, follow the plan.
Extract a shareable runnable template under templates/NNN-slug/ from a real project: copy + de-brand + remove secrets + add env examples + docs, with minimal refactors. Use when you have a working project and want to turn it into a template.
Seed a new runnable template under templates/NNN-slug/ from a short spec by chaining existing skills (intake → ship-faster stages) while keeping it clean and shareable (no secrets, minimal scope). Use when creating a new template quickly.