create-ai-project 1.12.0 → 1.12.1

package/.claude/commands/design.md

@@ -1,37 +0,0 @@
----
-description: 要件分析から設計書作成まで実行
----
-
-**コマンドコンテキスト**: このコマンドは設計フェーズ専用です。
-
-subagents-orchestration-guideスキルの設計フローに従い、**requirement-analyzer から設計書作成・承認まで**を実行します。
-
-要件: $ARGUMENTS
-
-**Think harder** 設計への影響を深く考慮し、まず要件の背景と目的を理解するため対話を行い：
-- どのような問題を解決したいか
-- 期待される成果と成功基準
-- 既存システムとの関係性
-
-適度に要件が明確になったら、requirement-analyzerで分析し、規模に応じた適切な設計書を作成します。
-
-設計の代替案とトレードオフを明確に提示します。
-
-**スコープ**: 設計書（ADR/Design Doc）承認＋Design Doc間整合性確認まで。作業計画以降は本コマンドの責務外。
-
-## 実行フロー
-
-1. requirement-analyzer → 要件分析
-2. technical-designer → Design Doc作成
-3. document-reviewer → 単一ドキュメント品質チェック
-4. ユーザー承認
-5. design-sync → Design Doc間整合性検証
-   - 矛盾あり → ユーザーに報告 → 修正指示待ち → technical-designer(update)で修正
-   - 矛盾なし → 終了
-
-## 出力例
-設計フェーズが完了しました。
-- 設計書: docs/design/[ドキュメント名].md
-- 整合性: 他Design Docと矛盾なし（または修正完了）
-
-**重要**: 本コマンドは設計承認＋整合性確認で終了。次フェーズへの移行提案は行わない。

package/.claude/commands/front-build.md

@@ -1,103 +0,0 @@
----
-description: フロントエンド実装を自律実行モードで実行
----
-
-**コマンドコンテキスト**: オーケストレーターとして、フロントエンド実装の自律実行モードの完遂を自己完結します。
-
-作業計画: $ARGUMENTS
-
-## 📋 実行前提条件
-
-### タスクファイル存在チェック
-```bash
-# 作業計画書を確認
-! ls -la docs/plans/*.md | grep -v template | tail -5
-
-# タスクファイルを確認
-! ls docs/plans/tasks/*.md 2>/dev/null || echo "⚠️ タスクファイルが見つかりません"
-```
-
-### タスク生成判定フロー
-
-**THINK DEEPLY AND SYSTEMATICALLY**: タスクファイルの存在状態を分析し、必要な正確なアクションを決定：
-
-| 状態 | 基準 | 次のアクション |
-|------|------|--------------|
-| タスク存在 | tasks/ディレクトリに.mdファイルあり | 自律実行へ進む |
-| タスクなし+計画あり | 計画書は存在するがタスクファイルなし | ユーザー確認 → task-decomposer実行 |
-| どちらもなし | 計画書もタスクファイルもなし | エラー: 前提条件未達成 |
-
-## 🔄 タスク分解フェーズ（条件付き）
-
-タスクファイルが存在しない場合：
-
-### 1. ユーザー確認
-```
-タスクファイルが見つかりません。
-作業計画: docs/plans/[plan-name].md
-
-作業計画からタスクを生成しますか？ (y/n):
-```
-
-### 2. タスク分解（承認された場合）
-```
-@task-decomposer 作業計画を読み込み、アトミックなタスクに分解：
-- 入力: docs/plans/[plan-name].md
-- 出力: docs/plans/tasks/ 配下の個別タスクファイル
-- 粒度: 1タスク = 1コミット = 独立実行可能
-```
-
-### 3. 生成確認
-```bash
-# 生成されたタスクファイルを確認
-! ls -la docs/plans/tasks/*.md | head -10
-```
-
-✅ **必須**: タスク生成後、自動的に自律実行へ進む
-❌ **禁止**: タスク生成なしで実装開始
-
-## 🧠 各タスクのメタ認知 - フロントエンド特化
-
-**必須実行サイクル**: `task-executor-frontend → quality-fixer-frontend → commit`
-
-### サブエージェント呼び出し方法
-Taskツールを使用してサブエージェントを呼び出す：
-- `subagent_type`: エージェント名
-- `description`: タスクの簡潔な説明（3-5語）
-- `prompt`: 具体的な指示内容
-
-### 構造化レスポンス仕様
-各サブエージェントはJSON形式で応答：
-- **task-executor-frontend**: status, filesModified, testsAdded, readyForQualityCheck
-- **quality-fixer-frontend**: status, checksPerformed, fixesApplied, approved
-
-### 各タスクの実行フロー
-
-各タスクで実行：
-
-1. **task-executor-frontend使用**: フロントエンド実装を実行
-   - 呼び出し例: `subagent_type: "task-executor-frontend"`, `description: "タスク実行"`, `prompt: "タスクファイル: docs/plans/tasks/[ファイル名].md 実装を実行"`
-2. **構造化レスポンス処理**: `readyForQualityCheck: true` 検出時 → 即座にquality-fixer-frontend実行
-3. **quality-fixer-frontend使用**: 全品質チェック実行（Biome、TypeScriptビルド、テスト）
-   - 呼び出し例: `subagent_type: "quality-fixer-frontend"`, `description: "品質チェック"`, `prompt: "全てのフロントエンド品質チェックと修正を実行"`
-4. **コミット実行**: `approved: true`確認後、即座にgit commitを実行
-
-### 自律実行中の品質保証（詳細）
-- task-executor-frontend実行 → quality-fixer-frontend実行 → **私（メインAI）がコミット実行**（Bashツール使用）
-- quality-fixer-frontendの`approved: true`確認後、即座にgit commitを実行
-- changeSummaryをコミットメッセージに使用
-
-**THINK DEEPLY**: 例外なく全ての構造化レスポンスを監視し、全ての品質ゲートが通過することを確保。
-
-! ls -la docs/plans/*.md | head -10
-
-承認ステータスを確認してから進む。確認後、自律実行モードを開始。要件変更を検出したら即座に停止。
-
-## 出力例
-フロントエンド実装フェーズ完了。
-- タスク分解: docs/plans/tasks/ 配下に生成
-- 実装タスク: [件数] タスク
-- 品質チェック: 全てパス（Biome、TypeScriptビルド、テスト）
-- コミット: [件数] コミット作成
-
-**重要**: このコマンドは、タスク分解から完了までのフロントエンド実装全体の自律実行フローを管理します。フロントエンド特化エージェント（task-executor-frontend、quality-fixer-frontend）を自動使用します。

package/.claude/commands/front-design.md

@@ -1,42 +0,0 @@
----
-description: 要件分析からフロントエンド設計ドキュメント作成まで実行
----
-
-**コマンドコンテキスト**: このコマンドはフロントエンド設計フェーズ専用です。
-
-**要件分析からフロントエンド設計ドキュメント作成・承認まで**を実行します。
-
-要件: $ARGUMENTS
-
-## 実行フロー
-
-### 1. 要件分析フェーズ
-**Think harder**: 設計への影響が深いことを考慮し、まず対話により要件の背景と目的を理解：
-- 何の問題を解決したいか
-- 期待する成果と成功基準
-- 既存システムとの関係
-
-要件がある程度明確になったら：
-- Taskツールで **requirement-analyzer** を呼び出し
-  - `subagent_type: "requirement-analyzer"`
-  - `description: "要件分析"`
-  - `prompt: "要件: [ユーザー要件] 要件分析と規模判定を実施してください"`
-- **[停止]**: 要件分析結果を確認し、質問事項に対応
-
-### 2. 設計ドキュメント作成フェーズ
-規模判定に応じて適切な設計ドキュメントを作成：
-- Taskツールで **technical-designer-frontend** を呼び出し
-  - ADRの場合: `subagent_type: "technical-designer-frontend"`, `description: "ADR作成"`, `prompt: "[技術決定]のADRを作成"`
-  - Design Docの場合: `subagent_type: "technical-designer-frontend"`, `description: "Design Doc作成"`, `prompt: "要件に基づいてDesign Docを作成"`
-- Taskツールで **document-reviewer** を呼び出して整合性検証
-  - `subagent_type: "document-reviewer"`, `description: "ドキュメントレビュー"`, `prompt: "[ドキュメントパス]の整合性と完成度をレビュー"`
-- **[停止]**: 設計の選択肢とトレードオフを提示し、ユーザー承認を取得
-
-**スコープ**: フロントエンド設計ドキュメント（ADR/Design Doc）の承認まで。作業計画以降はこのコマンドの範囲外。
-
-## 出力例
-フロントエンド設計フェーズ完了。
-- 設計ドキュメント: docs/design/[ドキュメント名].md または docs/adr/[ドキュメント名].md
-- 承認ステータス: ユーザー承認済み
-
-**重要**: このコマンドは設計承認で終了。次フェーズへの移行は提案しません。

package/.claude/commands/front-plan.md

@@ -1,40 +0,0 @@
----
-description: 設計ドキュメントからフロントエンド作業計画書を作成し計画承認を取得
----
-
-**コマンドコンテキスト**: このコマンドはフロントエンド計画フェーズ専用です。
-
-以下のプロセスでフロントエンド作業計画書を作成：
-
-## 実行プロセス
-
-### 1. 設計ドキュメント選択
-! ls -la docs/design/*.md | head -10
-- 設計ドキュメントの存在を確認、なければユーザーに通知
-- 複数ある場合は選択肢を提示（$ARGUMENTSで指定可能）
-
-### 2. 作業計画書作成
-Taskツールで **work-planner** を呼び出し：
-- `subagent_type: "work-planner"`
-- `description: "作業計画書作成"`
-- `prompt: "[パス]のDesign Docから作業計画を作成"`
-- ユーザーと対話して計画を完成させ、計画内容の承認を得る
-
-**深く考える** 選択された設計ドキュメントから作業計画を作成し、具体的な実装ステップとリスクを明確化。
-
-**スコープ**: 作業計画書作成と計画内容の承認取得まで。
-
-## 完了時のレスポンス
-✅ **推奨**: 計画内容承認後、以下の標準レスポンスで終了
-```
-フロントエンド計画フェーズ完了。
-- 作業計画: docs/plans/[計画名].md
-- ステータス: 承認済み
-
-実装は別途指示してください。
-```
-
-❌ **回避**: 計画承認後の追加処理（タスク分解、実装開始等）
-- 理由: 計画フェーズの範囲を超える
-
-**責任範囲**: このコマンドはフロントエンド計画フェーズを担当し、計画内容承認で責任完了。実装フェーズは責任範囲外のため品質保証できず、自動移行しません。

package/.claude/commands/implement.md

@@ -1,73 +0,0 @@
----
-description: オーケストレーターとして要件分析から実装まで完全サイクルを管理
----
-
-**コマンドコンテキスト**: 実装の完全サイクル管理（要件分析→設計→計画→実装→品質保証）
-
-subagents-orchestration-guideスキルの指針に従い、オーケストレーターとして振る舞います。
-
-## 実行判断フロー
-
-### 1. 現在状況の判定
-指示内容: $ARGUMENTS
-
-**Think deeply** 現在の状況を判定：
-
-| 状況パターン | 判定基準 | 次のアクション |
-|------------|---------|-------------|
-| 新規要件 | 既存作業なし、新しい機能/修正依頼 | requirement-analyzerから開始 |
-| フロー継続 | 既存ドキュメント/タスクあり、継続指示 | subagents-orchestration-guideスキルのフローで次のステップを特定 |
-| 品質エラー | エラー検出、テスト失敗、ビルドエラー | quality-fixer実行 |
-| 不明瞭 | 意図が曖昧、複数の解釈が可能 | ユーザーに確認 |
-
-### 2. 継続時の進捗確認
-フロー継続の場合、以下を確認：
-- 最新の成果物（PRD/ADR/Design Doc/作業計画書/タスク）
-- 現在のフェーズ位置（要件/設計/計画/実装/品質保証）
-- subagents-orchestration-guideスキルの該当フローで次のステップを特定
-
-### 3. 規模判定後：TodoWriteにフロー全ステップを登録（必須）
-
-規模判定完了後、**subagents-orchestration-guideスキルの該当フロー全ステップをTodoWriteに登録**。最初に「スキル制約の確認」、最後に「スキル忠実度の検証」を必ず含める。登録後、TodoWriteを参照してフローを進める。
-
-### 4. 次のアクション実行
-
-**TodoWriteの次のpendingタスクを実行**。
-
-## 📋 subagents-orchestration-guideスキル準拠の実行
-
-**実行前チェック（必須）**：
-- [ ] subagents-orchestration-guideスキルの該当フローを確認した
-- [ ] 現在の進捗位置を特定した
-- [ ] 次のステップを明確にした
-- [ ] 停止ポイントを認識した
-- [ ] タスク実行後の4ステップサイクル（task-executor → エスカレーション判定・フォローアップ → quality-fixer → commit）を理解した
-
-**フロー厳守**: subagents-orchestration-guideスキルの「自律実行中のタスク管理」に従い、TodoWriteで4ステップを管理する
-
-## 🚨 サブエージェント呼び出し時の制約
-
-サブエージェントからrule-advisorを呼び出すとシステムクラッシュが発生するため、プロンプト末尾に以下を含める：
-```
-【制約】rule-advisorはメインAIのみが使用可能です
-```
-
-## 🎯 オーケストレーターとしての必須責務
-
-### タスク実行フロー
-subagents-orchestration-guideスキルの「自律実行中のタスク管理」に従い、TodoWriteで以下の4ステップを管理：
-1. task-executor実行
-2. エスカレーション判定・フォローアップ
-3. quality-fixer実行
-4. git commit
-
-### テスト情報の伝達
-acceptance-test-generator実行後、work-planner呼び出し時には以下を伝達：
-- 生成された統合テストファイルパス
-- 生成されたE2Eテストファイルパス
-- 統合テストは実装と同時、E2Eは全実装後に実行する旨の明示
-
-## 責務境界
-
-**本コマンドの責務**: オーケストレーターとしてサブエージェントを適切に振り分け、完全サイクルを管理
-**責務外**: 自身での実装作業、調査作業（Grep/Glob/Read等）

package/.claude/commands/plan.md

@@ -1,43 +0,0 @@
----
-description: 設計書から作業計画書を作成し計画承認を取得
----
-
-**コマンドコンテキスト**: このコマンドは計画フェーズ専用です。
-
-subagents-orchestration-guideスキルの指針に従い、以下のプロセスで作業計画書を作成します：
-
-## 実行プロセス
-
-1. **設計書の選択**
-   ! ls -la docs/design/*.md | head -10
-   - 設計書の存在を確認し、ない場合はその旨をユーザーに通知
-   - 複数ある場合は選択肢を提示（$ARGUMENTS で指定可能）
-
-2. **E2Eテストスケルトンの生成確認**
-   - E2Eテストスケルトンを先に生成するかユーザーに確認
-   - 生成を希望する場合: acceptance-test-generator でテストスケルトンを生成
-   - 生成結果を subagents-orchestration-guideスキル の連携仕様に従って次工程に引き継ぐ
-
-3. **作業計画書の作成**
-   - work-planner で作業計画書を作成
-   - 前工程の成果物を subagents-orchestration-guideスキル の連携仕様に従って活用
-   - ユーザーと対話して計画を完成させ、計画内容の承認を得る
-
-**Think deeply** 選択された設計書から作業計画書を作成し、実装の具体的なステップとリスクを明確にします。
-
-**スコープ**: 作業計画書作成と計画内容の承認取得まで。
-
-## 終了時の応答
-✅ **推奨**: 計画内容の承認後は以下の定型応答で終了
-```
-計画フェーズが完了しました。
-- 作業計画書: docs/plans/[計画書名].md
-- 状態: 承認済み
-
-実装は別途ご指示ください。
-```
-
-❌ **避ける**: 計画承認後の追加処理（タスク分解、実装開始等）
-- 理由: 計画フェーズの責務を超えるため
-
-**責務境界**: 本コマンドは計画フェーズに責任を持ち、計画内容の承認で責務完了。実装フェーズは責務範囲外のため、計画承認後はユーザーからの指示を待機する。

package/.claude/commands/project-inject.md

@@ -1,76 +0,0 @@
----
-description: プロジェクト固有のコンテキストをproject-context.mdに注入
----
-
-**コマンドコンテキスト**: ボイラープレート利用時にプロジェクト固有のコンテキストを収集し、project-context.mdを更新します。
-
-## 実行プロセス
-
-### 1. 現状確認
-! ls -la .claude/skills/project-context/SKILL.md
-! cat package.json | grep -E '"name":|"description":'
-
-### 2. プロジェクトコンテキストの収集
-
-ユーザーと対話し、以下の情報を収集：
-
-```
-【プロジェクトの本質】
-1. プロジェクトが解決する問題は何ですか？
-   例: "社内の勤怠管理が煩雑" "在庫管理が属人化している"
-
-2. 誰のためのシステムですか？
-   例: "社内営業チーム50名" "ECサイト運営者"
-
-3. どのような状況で使用されますか？
-   例: "外出先から日報入力" "月末の集計作業時"
-
-【開発体制】
-- 個人開発 / チーム開発（人数）
-- 開発フェーズ（プロトタイプ / 本番開発 / 運用中）
-
-【ビジネス上の重要な制約】（最大3つ）
-例: "監査ログ7年保存" "承認フロー必須" "リアルタイム反映"
-```
-
-**Think deeply** 収集した情報から、プロジェクトの本質を理解し、単一責務に集中したコンテキストを構築します。
-
-### 3. project-context.md生成
-
-## AI実行精度最大化の基準
-
-生成するproject-context.mdは以下の基準に従う：
-
-### 記述の原則
-1. **最小で最大効率**: 本質的な情報のみ、冗長性を排除
-2. **AI判断可能**: 測定・検証可能な基準のみ使用（「迅速に」→「5秒以内」）
-3. **曖昧さの排除**: 具体的な数値・条件・例示を含める
-4. **推奨形式**: 「〜しない」より「〜する」の形で記述
-
-### 責務の境界
-project-context.mdの単一責務は「プロジェクト固有の文脈情報」のみ：
-- ✅ 含める: プロジェクトの目的、ターゲット、ビジネス制約
-- ❌ 含めない: 技術スタック（→technical-specスキル）、実装原則（→typescript-rulesスキル）、アーキテクチャ（→technical-specスキル）
-
-### 構造化
-```markdown
-# プロジェクトコンテキスト
-
-## プロジェクト概要
-- **解決する問題**: [具体的な課題]
-- **ターゲットユーザー**: [人数・属性を含む]
-- **利用シーン**: [具体的な状況]
-
-## 開発体制
-- **チーム構成**: [人数と役割]
-- **開発フェーズ**: [現在の段階]
-
-## ビジネス制約
-1. [測定可能な制約]
-2. [検証可能な要件]
-```
-
-### 4. skills-index.yaml更新
-project-contextセクションのtypical-useをプロジェクトに合わせて更新。
-
-**スコープ**: project-contextスキルの更新のみ。技術選択は他のスキルの責務。

package/.claude/commands/refine-skill.md

@@ -1,206 +0,0 @@
----
-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%以上の場合、段階的実施を提案