watany-dev · watany-dev · Apr 9, 2026 · Apr 9, 2026
diff --git a/.claude/settings.json b/.claude/settings.json
@@ -1 +1,34 @@
-{}
+{
+  "effortLevel": "high",
+  "language": "japanese",
+  "autoMemoryEnabled": false,
+  "env": {
+    "CLAUDE_CODE_DISABLE_1M_CONTEXT": "1"
+  },
+  "hooks": {
+    "SessionStart": [
+      {
+        "hooks": [
+          {
+            "type": "command",
+            "command": "bun install --frozen-lockfile"
+          }
+        ]
+      }
+    ]
+  },
+  "permissions": {
+    "allow": [
+      "Bash(bun run build:*)",
+      "Bash(bun run test:*)",
+      "Bash(bun run lint:*)",
+      "Bash(bun run format:*)",
+      "Bash(bun run check:*)",
+      "Bash(bun run dead-code:*)",
+      "Bash(bun run audit:*)",
+      "Bash(bun run ci:*)",
+      "Bash(bun install:*)",
+      "Bash(git:*)"
+    ]
+  }
+}
diff --git a/.claude/skills/update-plan/SKILL.md b/.claude/skills/update-plan/SKILL.md
@@ -0,0 +1,195 @@
+---
+description: プランモードでプラン完了直前に発動し、設計書・ロードマップ・要件定義との整合性を検証してプランの品質を高めるスキル（update-design の上位互換）
+---
+
+# update-plan
+
+プランモードで実装計画を完成させた直後、ユーザーに提示する直前に発動する統合検証・改善スキル。
+update-design の全機能（設計書品質評価）を内包しつつ、ロードマップ・要件定義との横断的整合性チェックと、プラン自体の改善を行う。
+
+## 発動タイミング
+
+**プランモードでプラン完了と判断した直後、`ExitPlanMode` を呼ぶ直前**に本スキルを実行する。
+
+フロー:
+1. ユーザーが実装タスクを依頼する
+2. Claude がプランモードで調査・計画を作成する
+3. プランが完成した時点で **本スキルを発動**
+4. 本スキルの検証結果に基づきプランを改善する
+5. 改善済みプランで `ExitPlanMode` を呼ぶ
+
+---
+
+## Phase 1: コンテキスト収集
+
+1. 作成中のプランファイルの内容を把握し、対象の機能・Phase・モジュールを特定する
+2. プランに関連する `docs/design-*.md`、`docs/roadmap.md`、`docs/requirements.md` を読み込む
+3. プランが対象とするモジュールの `src/` 配下のソースコードを読み込む
+   - `src/components/` — Inkコンポーネント
+   - `src/hooks/` — カスタムReactフック
+   - `src/services/` — AWS CodeCommit SDKサービス層
+   - `src/utils/` — ユーティリティ関数
+
+---
+
+## Phase 2: 10カテゴリ評価（update-design 完全互換）
+
+プランが関連する設計書を以下の10カテゴリ × 10点満点で評価する。
+
+### 評価カテゴリ
+
+| # | カテゴリ | 配点 | 評価観点 |
+|---|---------|------|---------|
+| 1 | **基本構造** | 10点 | 必須セクション（概要・コンポーネント設計・実装詳細・テスト・セキュリティ）が揃っているか |
+| 2 | **目的・スコープの明確性** | 10点 | 何を実装するか、何を実装しないかが明確か。読み手が迷わないか |
+| 3 | **コンポーネント設計の完全性** | 10点 | Inkコンポーネントの Props 型定義、状態管理、レンダリングロジックが網羅されているか |
+| 4 | **AWS SDK連携設計** | 10点 | CodeCommit API呼び出し、認証フロー、エラーハンドリング、モック方針が明記されているか |
+| 5 | **内部アーキテクチャ** | 10点 | ファイル構成、コンポーネント階層、データフロー等が記述されているか |
+| 6 | **エッジケース・異常系** | 10点 | 境界条件、エラー処理、不正入力への対処が考慮されているか |
+| 7 | **テスト戦略** | 10点 | ユニットテスト・スナップショットテストの方針と具体的なテストケースがあるか |
+| 8 | **セキュリティ考慮** | 10点 | AWS認証情報の取り扱い、入力検証、権限管理等が検討されているか |
+| 9 | **技術選定の根拠** | 10点 | Ink・React・AWS SDK v3の活用方針、採用・不採用の理由が明記されているか |
+| 10 | **実装計画** | 10点 | Phase/Iteration分割、ファイル構成、依存関係が具体的か |
+
+### 採点基準（各カテゴリ共通）
+
+| 点数 | 基準 |
+|------|------|
+| 9-10 | **模範的**。実装着手に必要な情報が全て揃っている。追加すべき内容がない |
+| 7-8 | 良好。軽微な追記で完成する |
+| 5-6 | 普通。重要な情報が一部欠けている |
+| 3-4 | 不十分。大幅な追記が必要 |
+| 1-2 | 骨格のみ。ほぼ未記述 |
+| 0 | セクション自体が存在しない |
+
+### 評価結果の出力
+
+```markdown
+## 自己評価結果
+
+| # | カテゴリ | 点数 | 評価コメント |
+|---|---------|------|-------------|
+| 1 | 基本構造 | X/10 | ... |
+| 2 | 目的・スコープの明確性 | X/10 | ... |
+| 3 | コンポーネント設計の完全性 | X/10 | ... |
+| 4 | AWS SDK連携設計 | X/10 | ... |
+| 5 | 内部アーキテクチャ | X/10 | ... |
+| 6 | エッジケース・異常系 | X/10 | ... |
+| 7 | テスト戦略 | X/10 | ... |
+| 8 | セキュリティ考慮 | X/10 | ... |
+| 9 | 技術選定の根拠 | X/10 | ... |
+| 10 | 実装計画 | X/10 | ... |
+| | **合計** | **XX/100** | |
+```
+
+### 重要度による分類
+
+8点未満のカテゴリを改善対象として抽出し、優先度を付ける:
+
+- **Critical（0-4点）**: 設計書として機能しない。即座に対応が必要
+- **Major（5-6点）**: 実装着手に支障あり。改善が強く推奨される
+- **Minor（7点）**: 品質向上のため推奨。なくても実装は可能
+
+---
+
+## Phase 3: 整合性チェック
+
+設計書・ロードマップ・要件定義・ソースコード間の不整合を検出する。
+
+### 3-1. 設計書 ↔ ソースコード
+
+1. 設計書に記載されたコンポーネント・Props型・関数シグネチャが実装と一致しているか確認する
+2. 設計書に記載されているが未実装の機能を特定する
+3. 実装されているが設計書に記載されていない機能を特定する
+
+### 3-2. ロードマップ ↔ 設計書 ↔ 要件定義
+
+1. プランが対象とするバージョン/Phaseに対応する設計書が存在するか確認する
+2. プランが対象とする機能が要件定義の機能スコープに含まれているか確認する
+3. 要件定義のステータス（✅ / 🔲）がロードマップのステータスと一致しているか確認する
+4. ドキュメント間で言及されているがカバーされていない機能・要件を特定する
+
+### 3-3. CLAUDE.md との整合性
+
+1. TDDサイクル（Red → Green → Refactor）に従ったイテレーション構成になっているか
+2. Tidy First? の原則（構造的変更と機能的変更の分離）が考慮されているか
+3. テスト品質（カバレッジ95%以上）が計画に含まれているか
+
+### 3-4. ソースコード規約との整合性
+
+1. コンポーネント名・ファイルパスが既存の `src/components/`, `src/hooks/`, `src/services/`, `src/utils/` の構成に従っているか
+2. Props型が既存のコンポーネントパターンと一貫しているか
+3. AWS SDK使用パターンが `src/services/codecommit.ts` の既存パターンと一致しているか
+4. テスト戦略が Vitest + ink-testing-library + カバレッジ95% の方針と一致しているか
+
+---
+
+## Phase 4: プラン改善と出力
+
+Phase 2〜3 の結果に基づき、プランを改善する。
+
+### 4-1. プランの検証
+
+1. **Tidy First?**: 構造的変更と機能的変更が分離されているか
+2. **イテレーション単位**: 各ステップが最小単位で分割されているか
+3. **影響範囲**: プランが変更するモジュールに依存する他のモジュールへの影響が考慮されているか
+4. **設計書提案**: プランが対象とする機能に設計書が存在しない場合、既存設計書の標準セクション構成（概要→コンポーネント設計→実装詳細→テスト→セキュリティ→実装計画）に従ったアウトラインをプランに追加する
+
+### 4-2. フィードバック反映
+
+発見した問題を優先度付きでプランに反映する:
+
+- **P0（必須修正）**: スコア50未満のカテゴリが1つでもある場合、設計書との矛盾、要件定義に存在しない機能の追加
+- **P1（推奨修正）**: スコア50-69のカテゴリがある場合、イテレーション分割の改善、影響範囲の追加記載
+- **P2（情報提供）**: スコア70-89のカテゴリがある場合、既存設計書の改善余地、将来Phaseへの影響（90以上は指摘なし）
+
+### 4-3. 検証サマリの出力
+
+プランファイルの末尾に以下の検証サマリを追記する:
+
+```markdown
+## update-plan 検証結果
+
+### 設計書品質評価
+| # | カテゴリ | 点数 | コメント |
+|---|---------|------|---------|
+| 1 | 基本構造 | X/10 | ... |
+| ... | ... | ... | ... |
+| | **合計** | **XX/100** | |
+
+**総合判定**: 🟢/🟡/🟠/🔴 [判定テキスト]
+
+総合判定の基準:
+- 🟢 実装着手可能: 合計 90 以上
+- 🟡 軽微な改善後に着手可能: 合計 70-89
+- 🟠 改善必要: 合計 50-69
+- 🔴 大幅改善必要: 合計 50 未満
+
+### 整合性チェック
+| チェック項目 | 結果 | 詳細 |
+|-------------|------|------|
+| 設計書 ↔ ソースコード | ✅/⚠️ | [詳細] |
+| ロードマップ ↔ 設計書 ↔ 要件定義 | ✅/⚠️ | [詳細] |
+| CLAUDE.md との整合性 | ✅/⚠️ | [詳細] |
+| ソースコード規約 | ✅/⚠️ | [詳細] |
+
+### 修正事項
+- **P0**: [必須修正の一覧]
+- **P1**: [推奨修正の一覧]
+- **P2**: [情報提供の一覧]
+```
+
+### 4-4. 完了アクション
+
+1. P0・P1 の修正をプランに反映する
+2. 検証サマリを付加した状態で `ExitPlanMode` を実行する
+
+---
+
+## 記述ルール
+
+- コード例はTypeScriptで記述すること
+- 設計書・レポートは日本語で記述すること
+- コンポーネント名はPascalCase、関数名・変数名はcamelCaseに従うこと
+- ロードマップ・要件定義のステータスは実装の実態に基づき、推測で変更しないこと
+- プランの修正は根拠（設計書・要件定義・CLAUDE.md の該当箇所）を明示すること