Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/zts212653/clowder-ai/self-evolutionnpx skills add zts212653/clowder-ai --skill self-evolutiongit clone --depth 1 https://github.com/zts212653/clowder-aiWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/zts212653/clowder-ai/self-evolution)<a href="https://agentmods.dev/skills/zts212653/clowder-ai/self-evolution"><img src="https://agentmods.dev/badge/skills/zts212653/clowder-ai/self-evolution.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00109 | $0.03506 |
| Opus 5 | $0.00055 | $0.01753 |
| Sonnet 5 | $0.00022 | $0.00701 |
| Haiku 4.5 | $0.00011 | $0.00351 |
Grade A, and why
self-evolution scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 3d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 281 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Self-Evolution — Scope Guard + Process Evolution + Knowledge Evolution
三猫共用。猫猫是主动的共创伙伴（P2），不是被动的 agent。 发现问题就护栏，发现规律就改进，发现知识就沉淀。 闭环 = 触发→产出结构化记录→蒸馏复用资产→验证净增益→五级阶梯治理。
三个模式
| 模式 | 方向 | 保护/推动什么 | 触发 | 产出物 |
|---|---|---|---|---|
| A: Scope Guard | 防御 | 当前 feat 验收边界 | operator讨论偏离愿景 | Scope Guard Log 记录 |
| B: Process Evolution | 防御→改进 | 团队流程持续改进 | 重复犯错 / 流程缺口 | Evolution Proposal |
| C: Knowledge Evolution | 进攻→成长 | 团队能力边界扩展 | 有价值的知识/方法论产生 | Episode Card → Method/Skill |
Mode A: Scope Guard
触发信号
不靠机械计数。看是否越过当前 feat 契约——满足 2 个普通信号或 1 个强信号：
| 信号 | 强度 |
|---|---|
| 新想法不直接服务当前愿景/验收条件 | 普通 |
| 新想法引入新的用户旅程/新页面/新子系统 | 强 |
| 新想法需要新的外部依赖/API/数据模型 | 强 |
| 新想法导致"这次怎么验收"说不清了 | 强 |
行为
operator，先收一下：当前 feat 愿景是 {愿景}。刚才提到的 {新方向} 更像独立 feat / 下一 phase。要不要拆出去方便验收？
- 同一 phase 最多两次：第一次温柔，第二次明确说"建议碰头"
- operator说"不拆" → 复述新验收边界，不再追问
- 出口：继续 / 拆 feat / parking lot / 碰头
触发后记录
每次触发后追加到 docs/scope-guard-log.md：
| {date} | {feat_id} | {signal_type} | {action_taken} | {outcome} | {agent} |
- 同一 feat ≥3 次触发 → 强烈建议拆 feat
- 效果追踪：成功率 = operator聚焦 / 总触发，用于调节灵敏度
Mode B: Process Evolution
触发（任一）
- Memory 中同类错误 ≥ 2 次
- operator纠正了可泛化为规则的行为
- SOP 执行中发现没有指引
- Review 指出系统性问题（非个案 bug）
提案流程
- 先闭环当前任务：按新裁决修正当前产物，并在当前 scope 扫同类位置；不能只修被点名的一处
- 写提案：用
docs/evolution-proposals/TEMPLATE.md创建EP-XXX.md - 5 槽模板：Trigger / Evidence(≥2 源) / Root Cause / Lever(最小杠杆) / Verify
- 审批：影响单猫→直接提operator；影响三猫→先 1 猫 sanity check→operator拍板
- 落地闭环：accepted → 必须关联 commit/PR，不能停在"提了"
- 30 天验证：落地 30 天后自动触发 replay check——同类错误还出现吗？
裁决蒸馏默认动作
operator给出可泛化的裁决或纠正后，归档 / 提案前先完成一次有界同类扫描：
- 以本次偏差的判据为搜索词，扫描当前任务正在修改的文件、claim 或检查清单。
- 当前 scope 内的同型问题一并修；跨 feature 的命中只投 source ref 给 owner，不顺手扩大实现球权。
- 若裁决消除了真实歧义，把它蒸馏成一组“错误例 → 正确例 → 分界判据”，写回现有 skill / test / docs 真相源。
这不是“每次纠正都建档”，也不是全仓扫墓。未确认历史重复时仍按正常任务处理；只有本节触发条件成立，才进入 Evolution Proposal。
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 3d ago First seen · 281 lines · 109 tokens per session scan A 2f8d3f406a1d
self-evolution is a skill published in the GitHub repository zts212653/clowder-ai (2,878 stars, last pushed today), licensed MIT. It adds 109 tokens to every session and 3,506 once invoked, about $0.0005 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
systematic-debugging
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes.
brainstorming
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
auto-perf-optimize
Run agent-driven VS Code performance or memory investigations. Use when asked to launch Code OSS, automate a VS Code scenario, run the Chat memory smoke runner, capture renderer heap snapshots, take workflow screenshots, compare run summaries, or drive a repeatable scenario before heap-snapshot analysis.
chat-perf
Run chat perf benchmarks and memory leak checks against the local dev build or any published VS Code version. Use when investigating chat rendering regressions, validating perf-sensitive changes to chat UI, or checking for memory leaks in the chat response pipeline.
chat-pet-sprite-creation
Use when creating or changing VS Code chat pet sprite art, sprite sheets, state animations, eye treatments, Stable/Insiders variants, or pet transitions under src/vs/workbench/contrib/chat/browser/widget/media/chatPet.
cpu-profile-analysis
Analyze V8/Chrome CPU profiles (.cpuprofile) and DevTools trace files (Trace-.json). Use when: profiling performance, investigating slow functions, comparing code paths, finding bottlenecks, analyzing timeToRequest, understanding call trees from sampling profiler data, analyzing layout/paint/rendering, investigating…