autoskill

このスキルはコーディングセッションを分析し、修正や承認から長期的に有効な好みを抽出したうえで、セッション中に有効だったスキルに対する的を絞った更新を提案します。セッションをまたいで学習する仕組みとして機能し、フィードバックに基づいて Claude が改善できるようにします。

ユーザーは、スキルを使用したセッションの後に autoskill を実行します。このスキルはシグナルを検出して品質を基準に絞り込み、関連するスキルファイルに対応付け、レビュー用に最小限で取り消し可能な編集を提案します。

セッションの範囲

デフォルトでは、現在のセッション（SessionStart から現在まで）のみを分析します。これにより、過去のセッションによるノイズを避け、直近の関連性の高いフィードバックを得られます。

複数のセッションにまたがるパターンを分析するには、ユーザーが「直近5回のセッションを分析して」や「今週の傾向を探して」と明示的に依頼する必要があります。

起動するタイミング

明示的な依頼があった場合に起動します。

• 「autoskill」「このセッションから学習して」「これらの修正をもとにスキルを更新して」
• 「このパターンを覚えておいて」「次回は必ず X をして」

単発の修正や、ユーザーがスキルの変更を望まない場合は起動しないでください。

変更の適用先

スキル固有の動作と、プロジェクト全体の規約を区別します。

スキルを更新する場合：

• シグナルが特定のスキルの動作に関するもの
• 好みがスキルの起動条件や出力に影響する
• パターンがスキルの意思決定プロセスに関するもの

CLAUDE.md を更新する場合：

• プロジェクト全体の規約（命名、ファイル構成、アーキテクチャ）
• 複数のスキルにまたがるツールやライブラリの好み
• チームのスタイルに関する好み（スペース、コメント、エラー処理）
• コードベース全体で使用されるドメイン固有の用語

例：

• 「内部関数にはエラー処理を追加しないでください」→ code-simplifier スキル（簡素化の方法）
• 「className の結合には cn() ユーティリティを使います」→ CLAUDE.md（プロジェクトの規約）
• 「認証ロジックはコンポーネントではなくミドルウェアに置きます」→ CLAUDE.md（アーキテクチャ上の決定）

シグナルの検出

セッション内で次の内容を調べます。

修正（最も価値が高い）

• 「いいえ、Y ではなく X を使ってください」
• 「常にこの方法で行います」
• 「このコードベースでは X をしないでください」

繰り返し見られるパターン（価値が高い）

• 同じフィードバックが2回以上ある
• 複数のファイルにわたって一貫した命名や構成の選択が見られる

承認（補助的な根拠）

• 「はい、そのとおりです」
• 「完璧です。この方法を続けてください」

無視する内容：

• 文脈に依存する単発の指示（「ここでは X を使って」など、「常に」が伴わないもの）
• 曖昧なフィードバック

競合の解決

シグナルが矛盾する場合は、次の優先順位で解決します。

1. 新しさ：より新しいシグナルを優先します（現在のセッション > 過去のセッション）
2. 明確さ：直接的な修正（「いいえ、代わりに X をしてください」）は、承認（「よさそうです」）より優先します
3. 反復性：3回以上繰り返されたパターンは、単発の修正より優先します
4. 確信度の採点：
   • 「常に／決して」を伴う明示的な修正：5点
   • 繰り返し見られるパターン（2回以上）：3点
   • 単発の修正：2点
   • 承認／確認：1点

矛盾するシグナルの点数が同じ場合は、変更を提案する前にユーザーに確認してください。

競合の例：

• セッション1：「どこでもエラー処理を追加して」（2点）
• セッション3（現在）：「内部関数にはエラー処理を追加しないでください」（5点。「しないで」による明示的な指示）
• 解決：現在のセッションの明示的なルールを採用します

シグナルの品質フィルター

変更を提案する前に、次の点を確認します。

1. この修正は繰り返されましたか。それとも一般的なルールとして述べられましたか。
2. 今後のセッションにも当てはまりますか。それともこのタスクだけに限られますか。
3. 実行可能な内容として十分に具体的ですか。
4. すでに把握している内容ではない、新しい情報ですか。

4つの条件をすべて満たす変更のみを提案してください。

「新しい情報」とは何か

記録する価値があるもの：

• プロジェクト固有の規約（「ここでは clsx() ではなく cn() を使う」）
• カスタムコンポーネント／ユーティリティの場所（「ボタンは @/components/ui にある」）
• デフォルトとは異なるチームの好み（「明示的な return を好む」）
• ドメイン固有の用語やパターン
• 一見してわかりにくいアーキテクチャ上の決定（「認証ロジックはコンポーネントではなくミドルウェアにある」）
• このスタック固有の連携や API の癖

記録する価値がないもの（これはすでに把握しています）：

• 一般的なベストプラクティス（DRY、関心の分離）
• 言語／フレームワークの規約（React のフックのルール、TypeScript の基礎）
• 一般的なライブラリの使い方（標準的な Tailwind クラス、よくある Next.js のパターン）
• 普遍的なセキュリティ対策（入力検証、SQL インジェクションの防止）
• 標準的なアクセシビリティガイドライン

どのプロジェクトにも同じアドバイスをするなら、スキルに含めるべきではありません。

シグナルとスキルの対応付け

各シグナルを、セッション中に有効で関連性のあったスキルに対応付けます。

既存のスキルを更新する場合：

• シグナルがセッション中に使用されたスキルに関連している
• そのスキルの合計信頼度スコアが 3 ポイント以上
• シグナルがスキルの動作や起動条件に影響する

新しいスキルを提案する場合：

• 複数の関連シグナル（合計スコアが 5 ポイント以上）が、現在有効なスキルに当てはまらない
• 一貫した動作パターンが複数のセッションにわたって見られる
• シグナルが、再利用可能で明確に定義された機能を示している

代わりに CLAUDE.md を更新する場合：

• シグナルがスキルの動作ではなく、プロジェクトの規約を示している
• 新しいスキルを作成する場合の合計スコアが 5 ポイント未満
• パターンが特定の状況に限定されすぎている

シグナルを無視する場合：

• セッション中に使用されたスキルのいずれにも対応付けられない
• 合計信頼度スコアが 2 ポイント未満
• 十分な根拠なしに、既存の確立されたパターンと矛盾している

スコアリング例：

• エラー処理に関する明示的な修正が 2 件（2×2=4 ポイント）→ code-simplifier を更新
• 命名に関する承認が 1 件＋パターンが 1 件（1+3=4 ポイント）→ 追加のシグナルが 1 件必要、または信頼度を高める必要があります
• 認証フローに関する修正が 3 件（3×2=6 ポイント）→ auth-specialist スキルを新規提案できる可能性があります

変更の提案

編集を提案するたびに、以下を提示します。

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 の使用中に、ユーザーがエラー処理について 2 回修正しました

検出されたシグナル：

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 を更新（まずプロジェクトのコンテキストを整える）
5. 使用頻度の高い順にスキルを更新（最もよく使われるスキルから）

順序の例：

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 に下げて質問してください