autoskill

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

This skill analyzes coding sessions to extract durable preferences from corrections and approvals, then proposes targeted updates to Skills that were active during the session. It acts as a learning mechanism across sessions, ensuring Claude improves based on feedback.

The user triggers autoskill after a session where Skills were used. The skill detects signals, filters for quality, maps them to the relevant Skill files, and proposes minimal, reversible edits for review.

本 Skill 可分析编码会话，从用户的修正和确认内容中提取可长期复用的偏好，然后为会话过程中激活的 Skill 提出针对性更新方案。它是跨会话的学习机制，可确保 Claude 基于用户反馈持续优化。

用户在使用过 Skill 的会话结束后可触发 autoskill 功能，该 Skill 会检测信号、过滤有效内容、映射到对应的 Skill 文件，并提出最小粒度、可回滚的编辑方案供用户审核。

Session scope

会话范围

By default, analyze only the current session (from SessionStart to now). This ensures fresh, relevant feedback without noise from old sessions.

To analyze patterns across multiple sessions, user must explicitly request: "analyze my last 5 sessions" or "look for patterns across this week".

默认情况下仅分析当前会话（从 SessionStart 到当前时间），可确保反馈新鲜且相关，不会受到旧会话内容的干扰。

如果需要分析跨多个会话的模式，用户必须明确提出请求，比如：“分析我最近5次会话”或“查找本周的共性模式”。

When to activate

何时激活

Trigger on explicit requests:

"autoskill", "learn from this session", "update skills from these corrections"
"remember this pattern", "make sure you do X next time"

Do NOT activate for one-off corrections or when the user declines skill modifications.

仅在用户明确提出以下请求时触发：

“autoskill”、“从本次会话中学习”、“根据这些修正更新 Skill”
“记住这个模式”、“下次确保要做X操作”

禁止对一次性修正或者用户拒绝修改 Skill 的场景激活本功能。

Where to apply changes

变更应用场景

Distinguish between skill-specific behavior and project-wide conventions:

Update Skills when:

Signal relates to how a specific skill should behave
Preference affects skill trigger conditions or outputs
Pattern is about the skill's decision-making process

Update CLAUDE.md when:

Project-wide conventions (naming, file structure, architecture)
Tool/library preferences that span multiple skills
Team style preferences (spacing, comments, error handling)
Domain-specific terminology used across the codebase

Example:

"Don't add error handling for internal functions" → code-simplifier skill (how to simplify)
"We use
```
cn()
```
utility for className merging" → CLAUDE.md (project convention)
"Auth logic lives in middleware, not components" → CLAUDE.md (architecture decision)

需要区分 Skill 专属行为和项目全局规范：

满足以下条件时更新 Skill：

信号与特定 Skill 的行为逻辑相关
偏好会影响 Skill 的触发条件或输出结果
模式与 Skill 的决策流程相关

满足以下条件时更新 CLAUDE.md：

项目全局规范（命名、文件结构、架构）
跨多个 Skill 的工具/库使用偏好
团队风格偏好（空格、注释、错误处理）
整个代码库通用的领域专属术语

示例：

“不要为内部函数添加错误处理” → code-simplifier Skill（和简化逻辑相关）
“我们使用
```
cn()
```
工具类合并 className” → CLAUDE.md（项目规范）
“鉴权逻辑放在 middleware 中，不要写在组件里” → CLAUDE.md（架构决策）

Signal detection

信号检测

Scan the session for:

Corrections (highest value)

"No, use X instead of Y"
"We always do it this way"
"Don't do X in this codebase"

Repeated patterns (high value)

Same feedback given 2+ times
Consistent naming/structure choices across multiple files

Approvals (supporting evidence)

"Yes, that's right"
"Perfect, keep doing it this way"

Ignore:

Context-specific one-offs ("use X here" without "always")
Ambiguous feedback

扫描会话中的以下内容：

修正内容（价值最高）

“不对，用X代替Y”
“我们一直是这么做的”
“不要在这个代码库里做X操作”

重复模式（价值很高）

相同的反馈出现2次及以上
多个文件中存在一致的命名/结构选择

确认内容（辅助证据）

“对，就是这样”
“完美，以后就这么做”

忽略以下内容：

特定上下文的一次性要求（仅说“这里用X”没有加“总是”）
模糊的反馈

Conflict resolution

冲突解决

When signals contradict each other, resolve using this priority order:

Recency: More recent signals override older ones (current session > past sessions)
Explicitness: Direct corrections ("No, do X instead") outweigh approvals ("looks good")
Repetition: Patterns repeated 3+ times outweigh single corrections
Confidence scoring:
- Explicit correction with "always/never": 5 points
- Repeated pattern (2+ occurrences): 3 points
- Single correction: 2 points
- Approval/confirmation: 1 point

If contradictory signals have equal scores, ask user for clarification before proposing changes.

Example conflict:

Session 1: "Add error handling everywhere" (2 points)
Session 3 (current): "Don't add error handling for internal functions" (5 points - explicit + "don't")
Resolution: Use current session's explicit rule

当信号之间存在矛盾时，按以下优先级解决：

新鲜度：更新的信号覆盖旧信号（当前会话 > 历史会话）
明确度：直接修正（“不对，应该做X”）优先级高于确认内容（“看起来不错”）
重复度：重复3次及以上的模式优先级高于单次修正
置信度评分：
- 带“总是/从不”的明确修正：5分
- 重复模式（出现2次及以上）：3分
- 单次修正：2分
- 确认/认可：1分

如果矛盾的信号得分相同，在提出变更前先询问用户明确需求。

冲突示例：

会话1：“所有地方都要加错误处理”（2分）
会话3（当前）：“不要为内部函数添加错误处理”（5分 - 明确修正 + “不要”）
解决方案：采用当前会话的明确规则

Signal quality filter

信号质量过滤

Before proposing any change, ask:

Was this correction repeated, or stated as a general rule?
Would this apply to future sessions, or just this task?
Is it specific enough to be actionable?
Is this new information I wouldn't already know?

Only propose changes that pass all four.

在提出任何变更前，先确认以下问题：

这个修正是否重复出现，或者被明确说明是通用规则？
这个规则是否适用于未来的会话，还是仅针对当前任务？
规则是否足够具体可落地？
这是不是我本来不知道的新信息？

只有全部满足以上条件的变更才需要提出。

What counts as "new information"

什么属于“新信息”

Worth capturing:

Project-specific conventions ("we use
```
cn()
```
not
```
clsx()
```
here")
Custom component/utility locations ("buttons are in
```
@/components/ui
```
")
Team preferences that differ from defaults ("we prefer explicit returns")
Domain-specific terminology or patterns
Non-obvious architectural decisions ("auth logic lives in middleware, not components")
Integrations and API quirks specific to this stack

NOT worth capturing (I already know this):

General best practices (DRY, separation of concerns)
Language/framework conventions (React hooks rules, TypeScript basics)
Common library usage (standard Tailwind classes, typical Next.js patterns)
Universal security practices (input validation, SQL injection prevention)
Standard accessibility guidelines

If I'd give the same advice to any project, it doesn't belong in a skill.

值得记录：

项目专属规范（“我们这里用
```
cn()
```
不用
```
clsx()
```
”）
自定义组件/工具类的位置（“按钮放在
```
@/components/ui
```
目录下”）
和默认规则不同的团队偏好（“我们偏好显式 return”）
领域专属术语或模式
不直观的架构决策（“鉴权逻辑放在 middleware 中，不要写在组件里”）
当前技术栈专属的集成和API特性

不值得记录（我本来就知道）：

通用最佳实践（DRY、关注点分离）
语言/框架规范（React 钩子规则、TypeScript 基础）
常用库用法（标准 Tailwind 类、典型 Next.js 模式）
通用安全实践（输入校验、SQL 注入防护）
标准无障碍指南

如果是我对任何项目都会给出的相同建议，就不需要写到 Skill 里。

Mapping signals to Skills

信号与 Skill 映射

Match each signal to the Skill that was active and relevant during the session:

Update existing Skill when:

Signal relates to a Skill that was used in the session
Total confidence score for that Skill ≥ 3 points
Signal affects how the skill should behave or trigger

Propose new Skill when:

Multiple related signals (total score ≥ 5 points) don't fit any active Skill
Pattern spans multiple sessions with consistent behavior
Signals describe a reusable, well-defined capability

Update CLAUDE.md instead when:

Signals describe project conventions, not skill behavior
Total score < 5 points for new skill creation
Pattern is too specific to one context

Ignore signals when:

Don't map to any Skill used in the session
Total confidence score < 2 points
Contradict existing, well-established patterns without strong justification

Scoring example:

2 explicit corrections about error handling (2×2=4 points) → Update code-simplifier
1 approval + 1 pattern about naming (1+3=4 points) → Needs one more signal or higher confidence
3 corrections about auth flow (3×2=6 points) → Could propose new auth-specialist 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

Proposing changes

提出变更方案

For each proposed edit, provide:

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]

Group proposals by file. Present HIGH confidence changes first.

每个提议的变更都需要包含以下内容：

File: path/to/SKILL.md
Section: [现有章节名称或 "new section: X"]
Confidence: HIGH | MEDIUM
Score: [置信度得分]

Signal: "[用户原话或意译]"

Current text (if modifying):
> 现有内容

Proposed text:
> 更新后的内容

Rationale: [一句话说明理由]

按文件分组展示变更，高置信度的变更放在最前面。

Concrete example

具体示例

Session context: User corrected error handling twice during code-simplifier usage

Detected signals:

"Don't add try-catch blocks for internal functions" (explicit correction: 5 points)
Removed error handling from internal utility functions (pattern: 3 points)
Total: 8 points → HIGH confidence

Proposed change:

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

会话上下文： 用户在使用 code-simplifier 期间两次修正了错误处理相关的内容

检测到的信号：

“不要为内部函数添加 try-catch 块”（明确修正：5分）
移除内部工具函数的错误处理（模式：3分）
总计：8分 → 高置信度

提议的变更：

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

Review flow

审核流程

Always present changes for review before applying. Format:

undefined

应用变更前必须先展示方案供用户审核，格式如下：

undefined

autoskill summary

Detected [N] durable preferences from this session.

HIGH confidence (recommended to apply)

[change 1] - Score: X points
[change 2] - Score: X points

[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]


Wait for explicit approval before editing any file.

[change 3] - Score: X points

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


编辑任何文件前必须等待用户明确同意。

Processing order when multiple updates needed

多更新需求的处理顺序

When proposing changes to multiple files:

Process HIGH confidence first (score ≥ 7 points)
Group by file to minimize context switches
Flag potential conflicts between proposed changes
CLAUDE.md updates before Skill updates (project context first)
Skill updates in order of usage frequency (most-used skills first)

Example order:

CLAUDE.md: Add
```
cn()
```
utility convention (HIGH, 8 points)
code-simplifier: Error handling rule (HIGH, 8 points)
code-simplifier: Variable naming pattern (MEDIUM, 4 points)
typescript-pro: Type annotation preference (MEDIUM, 5 points)

当需要提议多个文件的变更时：

优先处理高置信度变更（得分 ≥ 7分）
按文件分组减少上下文切换
标记变更之间可能存在的冲突
先更新 CLAUDE.md 再更新 Skill（优先处理项目上下文）
按使用频率排序 Skill 更新（最常用的 Skill 优先）

示例顺序：

CLAUDE.md：新增
```
cn()
```
工具类规范（高置信度，8分）
code-simplifier：错误处理规则（高置信度，8分）
code-simplifier：变量命名模式（中置信度，4分）
typescript-pro：类型注解偏好（中置信度，5分）

Applying changes

应用变更

When approved:

Edit the target file with minimal, focused changes
If git is available, commit with message:
```
chore(autoskill): [brief description]
```
Report what was changed

获得用户同意后：

对目标文件做最小粒度的聚焦修改
如果可用 git，提交信息格式为：
```
chore(autoskill): [简要描述]
```
告知用户变更内容

Rollback guidance

回滚指南

All autoskill changes are reversible:

If git is available:

Find commit:
```
git log --grep="autoskill" --oneline
```
Revert specific commit:
```
git revert <commit-hash>
```

Or revert all autoskill changes:

git log --grep="autoskill" --format="%H" | xargs -n1 git revert

Manual rollback:

Each edit is minimal and focused (easy to identify)
Use git diff to see exact changes:
```
git show <commit-hash>
```
Manually undo the specific section that caused issues

Prevention:

Always commit each skill change separately (never batch)

Use descriptive commit messages:

chore(autoskill): add error handling rule to code-simplifier

Test after each change before proceeding to next

所有 autoskill 变更都支持回滚：

可用 git 时：

查找提交：
```
git log --grep="autoskill" --oneline
```
回滚特定提交：
```
git revert <commit-hash>
```

或者回滚所有 autoskill 变更：

git log --grep="autoskill" --format="%H" | xargs -n1 git revert

手动回滚：

每个变更都是最小粒度聚焦修改（很容易识别）
使用 git diff 查看具体变更：
```
git show <commit-hash>
```
手动撤销导致问题的特定章节

预防措施：

每个 Skill 变更单独提交（永远不要批量提交）

使用描述性提交信息：

chore(autoskill): add error handling rule to code-simplifier

每次变更后先测试再进行下一个变更

When to ask for clarification

何时需要明确询问用户

Use the AskUserQuestion tool when:

Ambiguous signals:

Correction doesn't clearly specify what to do instead
Pattern observed but unclear if intentional or coincidental
Signal could apply to multiple skills

Contradictory feedback:

Equal confidence scores for contradicting signals
User's recent correction conflicts with established pattern
Unclear which rule should take precedence

Boundary decisions:

Uncertain whether change belongs in CLAUDE.md or Skill
Score is near threshold (4-6 points for new skill creation)
Signal could be project-wide convention OR skill-specific behavior

Scope uncertainty:

Unclear if correction applies to all cases or specific context
Signal mentions "here" or "this case" without "always/never"
Need to verify if pattern should be generalized

Example questions:

"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?"

Never guess or assume - when in doubt, downgrade to MEDIUM confidence and ask.

出现以下情况时使用 AskUserQuestion 工具：

信号模糊：

修正没有明确说明应该怎么做
观察到模式但不确定是有意还是巧合
信号可能适用于多个 Skill

反馈矛盾：

矛盾信号的置信度得分相同
用户最近的修正和已建立的模式冲突
不清楚哪个规则优先级更高

边界决策：

不确定变更应该放在 CLAUDE.md 还是 Skill 里
得分接近阈值（新增 Skill 得分为4-6分）
信号可能是项目全局规范 OR Skill 专属行为

范围不确定：

不清楚修正是适用于所有场景还是特定上下文
信号提到“这里”或“这个情况”但没有加“总是/从不”
需要确认模式是否可以通用化

示例问题：

"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?"

永远不要猜测或假设——有疑问时降级为中置信度并询问用户。

Constraints

约束

Never delete existing rules without explicit instruction
Prefer additive changes over rewrites
One concept per change (easy to revert)
Preserve existing file structure and tone
When uncertain, downgrade to MEDIUM confidence and ask

没有明确指令永远不要删除现有规则
优先做新增变更而非重写
每个变更只包含一个概念（方便回滚）
保留现有文件结构和风格
有疑问时降级为中置信度并询问用户