autoskill

这项技能会分析编码会话，从用户的纠正和认可中提取持久偏好，然后针对会话期间启用的技能提出定向更新。它是一种跨会话学习机制，可确保 Claude 根据反馈不断改进。

用户会在使用过技能的会话结束后触发 autoskill。该技能会检测信号、筛选质量、将信号映射到相关技能文件，并提出精简且可撤销的编辑供用户审核。

会话范围

默认情况下，仅分析当前会话（从 SessionStart 到现在）。这样可以确保反馈新鲜、相关，且不受旧会话的干扰。

如需分析多个会话中的模式，用户必须明确提出请求，例如：“分析我最近 5 个会话”或“查找本周的规律”。

何时激活

在收到明确请求时触发：

• “autoskill”、“从本次会话中学习”、“根据这些纠正更新技能”
• “记住这个模式”、“确保下次执行 X”

对于一次性纠正，或用户拒绝修改技能时，不要激活。

在何处应用更改

区分特定技能的行为与适用于整个项目的约定：

在以下情况下更新技能：

• 信号涉及特定技能应如何运作
• 偏好会影响技能的触发条件或输出
• 模式涉及技能的决策过程

在以下情况下更新 CLAUDE.md：

• 适用于整个项目的约定（命名、文件结构、架构）
• 会影响多项技能的工具或库偏好
• 团队风格偏好（空格、注释、错误处理）
• 整个代码库通用的领域术语

示例：

• “不要为内部函数添加错误处理” → code-simplifier 技能（如何简化）
• “我们使用 cn() 工具函数合并 className” → CLAUDE.md（项目约定）
• “身份验证逻辑放在中间件中，而不是组件中” → CLAUDE.md（架构决策）

信号检测

扫描会话中的以下内容：

纠正（价值最高）

• “不对，用 X 替代 Y”
• “我们一贯如此处理”
• “在这个代码库中不要做 X”

重复模式（价值较高）

• 同一反馈出现 2 次或更多
• 多个文件中持续采用相同的命名或结构选择

认可（辅助证据）

• “对，就是这样”
• “很好，以后继续这样做”

忽略：

• 与特定上下文相关的一次性要求（“这里用 X”，但未提及“始终如此”）
• 含糊的反馈

冲突解决

当信号互相矛盾时，按以下优先级解决：

1. 时效性：较新的信号优先于较旧的信号（当前会话 > 过去的会话）
2. 明确性：直接纠正（“不对，改为做 X”）优先于认可（“看起来不错”）
3. 重复性：重复 3 次或更多的模式优先于单次纠正
4. 置信度评分：
   • 带有“始终／绝不”的明确纠正：5 分
   • 重复模式（出现 2 次或更多）：3 分
   • 单次纠正：2 分
   • 认可／确认：1 分

如果矛盾信号的得分相同，应先向用户询问以澄清，再提出更改。

冲突示例：

• 会话 1：“到处都添加错误处理”（2 分）
• 会话 3（当前）：“不要为内部函数添加错误处理”（5 分——明确纠正并包含“不要”）
• 结论：采用当前会话中的明确规则

信号质量筛选

提出任何更改前，先确认：

1. 这项纠正是否重复出现，或是否被表述为通用规则？
2. 这项偏好是否适用于未来的会话，还是仅适用于当前任务？
3. 这项偏好是否足够具体，可以据此采取行动？
4. 这是否是我原本不知道的新信息？

仅提出通过全部四项检查的更改。

什么算是“新信息”

值得记录：

• 项目特定的约定（“这里使用 cn()，而不是 clsx()”）
• 自定义组件／工具的位置（“按钮位于 @/components/ui”）
• 与默认做法不同的团队偏好（“我们更倾向于显式返回”）
• 特定领域的术语或模式
• 不显而易见的架构决策（“身份验证逻辑放在中间件中，而不是组件中”）
• 此技术栈特有的集成和 API 特性

不值得记录（我已经知道）：

• 通用最佳实践（DRY、关注点分离）
• 语言／框架约定（React hooks 规则、TypeScript 基础知识）
• 常见库的用法（标准 Tailwind 类、典型的 Next.js 模式）
• 通用安全实践（输入验证、防止 SQL 注入）
• 标准无障碍指南

如果我会给任何项目同样的建议，那它就不应该写进 Skill。

将信号映射到 Skill

将每个信号对应到本次会话中处于活动状态且相关的 Skill：

在以下情况下更新现有 Skill：

• 信号与本次会话中使用的 Skill 相关
• 该 Skill 的总置信度分数 ≥ 3 分
• 信号会影响 Skill 的行为或触发方式

在以下情况下提议新建 Skill：

• 多个相关信号（总分 ≥ 5 分）不适用于任何活动中的 Skill
• 某种模式在多个会话中持续出现
• 信号描述了一种可复用、定义明确的能力

在以下情况下改为更新 CLAUDE.md：

• 信号描述的是项目约定，而非 Skill 行为
• 新建 Skill 的总分 < 5 分
• 模式只适用于某个特定情境

在以下情况下忽略信号：

• 无法映射到本次会话中使用的任何 Skill
• 总置信度分数 < 2 分
• 与已有的成熟模式相矛盾，且缺乏有力依据

评分示例：

• 关于错误处理的 2 次明确纠正（2×2=4 分）→ 更新 code-simplifier
• 1 次认可 + 1 个命名模式（1+3=4 分）→ 需要再有一个信号或更高置信度
• 关于身份验证流程的 3 次纠正（3×2=6 分）→ 可以提议新建 auth-specialist Skill

提议更改

对于每项提议的编辑，请提供：

File: path/to/SKILL.md
Section: [existing section or "new section: X"]
Confidence: HIGH | MEDIUM
Score: [confidence points]

Signal: "[exact user quote or paraphrase]"

Current text (if modifying):
> existing content

Proposed text:
> updated content

Rationale: [one sentence]

按文件对提议进行分组。优先展示 HIGH 置信度的更改。

具体示例

会话背景： 用户在使用 code-simplifier 时两次纠正了错误处理方式

检测到的信号：

1. “不要为内部函数添加 try-catch 代码块”（明确纠正：5 分）
2. 从内部工具函数中移除了错误处理（模式：3 分）
3. 总分：8 分 → HIGH 置信度

提议的更改：

File: plugins/essentials/skills/code-simplifier/SKILL.md
Section: ## When NOT to simplify
Confidence: HIGH
Score: 8 points (5 + 3)

Signal: "Don't add try-catch blocks for internal functions" + pattern of removing such blocks

Current text:
> - Don't add error handling, fallbacks, or validation for scenarios that can't happen

Proposed text:
> - Don't add error handling, fallbacks, or validation for scenarios that can't happen
> - Don't add try-catch blocks for internal functions that are called by trusted code

Rationale: User explicitly corrected this twice; it's a specific, actionable rule for this project

审核流程

始终先提交更改供审核，再进行应用。格式如下：

## autoskill summary

Detected [N] durable preferences from this session.

### HIGH confidence (recommended to apply)
- [change 1] - Score: X points
- [change 2] - Score: X points

### MEDIUM confidence (review carefully)
- [change 3] - Score: X points

Apply high confidence changes? [y/n/selective]

在编辑任何文件之前，等待明确批准。

需要更新多个文件时的处理顺序

提议更改多个文件时：

1. 优先处理 HIGH 置信度的更改（分数 ≥ 7 分）
2. 按文件分组，尽量减少上下文切换
3. 标记提议更改之间可能存在的冲突
4. 先更新 CLAUDE.md，再更新 Skill（先处理项目上下文）
5. 按使用频率的顺序更新 Skill（最常用的 Skill 优先）

顺序示例：

1. CLAUDE.md：添加 cn() 工具约定（HIGH，8 分）
2. code-simplifier：错误处理规则（HIGH，8 分）
3. code-simplifier：变量命名模式（MEDIUM，4 分）
4. typescript-pro：类型注解偏好（MEDIUM，5 分）

应用更改

获得批准后：

1. 对目标文件进行最少且精确的更改
2. 如果 git 可用，使用提交信息：chore(autoskill): [brief description]
3. 报告更改内容

回滚指南

所有 autoskill 更改均可撤销：

如果可以使用 git：

1. 查找提交：git log --grep="autoskill" --oneline
2. 撤销特定提交：git revert <commit-hash>
3. 或撤销所有 autoskill 更改：git log --grep="autoskill" --format="%H" | xargs -n1 git revert

手动回滚：

1. 每项编辑都尽量精简且有明确针对性（易于识别）
2. 使用 git diff 查看具体更改：git show <commit-hash>
3. 手动撤销导致问题的特定部分

预防措施：

• 始终分别提交每项技能更改（不要批量提交）
• 使用描述性提交消息：chore(autoskill): add error handling rule to code-simplifier
• 每次更改后都先进行测试，再继续下一项

何时请求澄清

遇到以下情况时，使用 AskUserQuestion 工具：

信号含糊不清：

• 更正没有明确说明应改为怎样
• 观察到某种模式，但不清楚这是有意为之还是偶然出现
• 信号可能适用于多个技能

反馈相互矛盾：

• 相互矛盾的信号具有相同的置信度分数
• 用户最近的更正与已确立的模式冲突
• 不清楚应以哪条规则为准

边界判定：

• 不确定更改应归入 CLAUDE.md 还是 Skill
• 分数接近阈值（创建新技能时为 4-6 分）
• 信号可能属于项目级约定，也可能是技能特有行为

范围不确定：

• 不清楚更正适用于所有情况还是特定上下文
• 信号提到“这里”或“此情况”，但没有使用“始终/绝不”
• 需要确认是否应将该模式推广

问题示例：

"I detected two corrections about error handling:
1. 'Don't add try-catch for internal functions'
2. 'Always validate user input'

These seem contradictory. Should I:
- Add both rules with specific contexts?
- Apply different rules to internal vs external code?
- Something else?"

绝不要猜测或擅自假定——如有疑问，将置信度降至 MEDIUM 并提问。

约束

• 除非有明确指示，否则绝不删除现有规则
• 优先采用增补，而非重写
• 每次更改只涉及一个概念（便于撤销）
• 保留现有文件结构和语气
• 如有疑问，将置信度降至 MEDIUM 并提问