---
description: ユーザーのスキル変更要求を精度最大化して実装
---

変更要求: $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環境でasync関数のエラーハンドリング実装」 |
| 順序不明確 | 「以下を考慮：A、B、C」 | 「優先順：1.A（必須）、2.B（推奨）、3.C（任意）」 |
| 冗長説明 | 「型安全性を確保するため、型を定義し、型チェックを行い、型エラーを防ぐ」 | 「型安全性の確保（定義・チェック・エラー防止）」 |
| スコープ曖昧 | 「テストを書く」 | 「単体テストを書く（E2Eテストはtypescript-testingスキル参照）」 |

## 出力例

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

【ユーザー要求】
「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%以上の場合、段階的実施を提案