ツール選択基準（測定可能な判断）

変更要求: $ARGUMENTS

Think deeply ユーザーの変更意図を汲み取り、LLMが迷わない形で実装：

適用する9つの観点

1. コンテキスト圧迫 vs 実行精度 - 最小記述で最大精度
2. 重複排除 - スキルファイル内・スキルファイル間の一貫性
3. 責務の適切な集約 - 関連内容は1ファイルにまとめる（読み込み回数最小化）
4. 判断基準明確化 - 測定可能な基準
5. NG→推奨変換 - 推奨形式（背景：NG例を含む）
6. 表記統一 - 一貫した表現
7. 前提条件の明示化 - 暗黙前提を言語化
8. 記述順序最適化 - 冒頭：最重要、末尾：例外
9. スコープ境界明示 - 扱う/扱わない範囲

実行フロー

1. 変更要求の理解

未指定時の質問テンプレート：

1. どのスキルを変更しますか？
   例: typescript-rules / coding-standards / documentation-criteria

2. 変更種別を選択：
   a) 新基準追加（新しい基準を追加）
   b) 既存基準修正（曖昧な記述を明確化）
   c) 基準削除（不要になった基準を削除）

3. 具体的な変更内容：
   例：「any型の使用を禁止する基準を追加」
   例：「エラーハンドリングの基準を明確化」
   [ユーザー入力]

2. 変更設計案の作成

対象ファイル特定と現状確認：

# ツール選択基準（測定可能な判断）
if スキル名が明示されている:
  Read: .claude/​skills/​{スキル名}/​SKILL.md を直接読み込み
else if スキル名の一部のみ判明:
  Glob: .claude/​skills/​*{キーワード}*/​SKILL.md で探索
  Read: 特定したファイルの現状確認
else:
  Glob: .claude/​skills/​*/​SKILL.md で全件確認
  ユーザーに対象スキル選択を確認

変更設計テンプレート：

【現状】
「エラーは適切に処理する」（曖昧：「適切」の基準不明）

【ユーザー要求の理解】
「エラーハンドリングを厳格化したい」→ 測定可能な基準を設定

【変更案】
「エラーハンドリング実装基準：
1. try-catch必須条件：
   - 外部API呼び出し（fetch, axios等）
   - ファイルI/​O操作（fs.readFile等）
   - JSON.parse、parseInt等の変換処理
2. エラーログ必須項目：
   - error.name（エラー種別）
   - error.stack（発生箇所）
   - タイムスタンプ（ISO 8601形式）
3. ユーザー通知基準：
   - 技術詳細を含まない（NG例：スタックトレース表示）
   - 対処法を明示（推奨：「再度お試しください」）」

この設計で進めますか？ (y/​n)

3. 3回見直しプロセス

第1回: 実行精度最大化の観点で追記【追記専用モード】

開始宣言: 「第1回：追記モードで実行。削除は一切行わない」

• 曖昧表現→測定可能基準に変換 例：「大きい」→「100行以上」「5ファイル以上」
• 暗黙前提→明示的条件として記載 例：「TypeScript環境で」「async関数内で」
• 例外ケース・エッジケースの定義 例：「null/​undefinedの場合」「空配列の場合」 報告: 追記項目数をカウント（最低5項目）

第2回: 批判的修正で冗長性を削減【実修正モード】

開始宣言: 「第2回：批判的修正モードで実行。冗長と判断した箇所を実際に削除・統合」

修正作業：

1. 第1回の追記内容を批判的に検証
2. 以下の観点で実際に修正を実施：
   • 同一概念の重複 → 統合
   • 過度に詳細な説明 → 簡潔化
   • 他スキルとの重複 → 参照に置換
3. 修正前後の差分を記録（削除理由も明記）

報告フォーマット：

修正箇所数: X件
削除・統合した内容:
- [削除前]: 「詳細な記述」
  [削除後]: 「簡潔な記述」
  [理由]: 冗長性の排除

第3回: 差分評価による精度確保【復元判定モード】

開始宣言: 「第3回：差分評価モードで実行。第2回の修正を検証し、必要なら復元」

検証作業：

1. 第2回の各修正について評価：
   • この削除で実装時に迷う可能性があるか？
   • エッジケースの考慮が漏れていないか？
2. 精度低下リスクがある削除 → 復元
3. 妥当な削除 → 維持

最終確認質問（必須回答）： 「ユーザーの変更要求を正確に実装するための必要十分条件が揃っているか？」

報告: 復元項目数と最終的な削減率

4. 承認取得

変更前後の比較を提示し、ユーザー承認を取得。

5. 実装

1. 適切なツールで変更適用（ユーザー承認後）
2. git diffで変更内容を最終確認
3. /​sync-skills 実行提案

判断基準チェックリスト

• 「if-then」形式で表現可能（「～の場合は～する」）
• 数値・個数・状態で判定可能（主観的判断を排除）
• 関連内容は1ファイルに集約（読み込み回数最小化）
• 他スキルとの関係明記（依存・参照・委譲）
• NG例を背景情報として含む
• 前提条件が全て明示されている

削減パターン例

出力例

=== 変更実装完了 ===

【ユーザー要求】
「TypeScriptのエラーハンドリング基準を厳格化したい」

【変更内容】
対象: .claude/​skills/​typescript-rules/​SKILL.md
セクション: ## エラーハンドリング

変更前:
「エラーは適切に処理する」

変更後（3回見直しプロセス完了）:
「エラーハンドリング実装基準：
1. try-catchブロック必須条件：
   - 外部API呼び出し（fetch, axios等）
   - ファイルI/​O操作（fs.readFile, fs.writeFile等）
   - JSON.parse、parseInt等の例外発生可能な処理
2. エラーログ必須項目：
   - error.name（エラー種別）
   - error.stack（発生箇所）
   - new Date().toISOString()（タイムスタンプ）
3. ユーザー向けメッセージ：
   - 技術詳細を含まない（NG例：スタックトレース表示）
   - 具体的な対処法を明示（推奨：「再度お試しください」）」

【改善指標】
- 判断基準明確度: 0% → 100%（全て測定可能）
- 曖昧表現: 1箇所 → 0箇所
- NG例を背景情報として含む

メタデータ同期のため /​sync-skills を実行してください。

実行順序

1. ユーザー要求理解
2. 現状分析
3. 9観点を適用した変更設計
4. 3回見直しプロセス
5. ユーザー承認
6. 変更適用
7. sync-skills提案

スコープ: ユーザー変更要求の理解と精度最大化実装

エラーハンドリング

• スキル未発見: 利用可能なスキル一覧を表示
• 大規模変更検出: 変更量50%以上の場合、段階的実施を提案