yodogawa 2.1.3 → 2.2.0

package/skills/b-003-create-task-research/SKILL.md

@@ -1,128 +1,128 @@
----
-name: b-003-create-task-research
-description: タスク実装前に既存コード・ベストプラクティス・再利用候補・リスクを調査し b-research.md に記録する。タスク定義確定後、実装計画作成前に使用。
-disable-model-invocation: true
-allowed-tools: Read, Write, Edit, Bash, Grep, Glob
-argument-hint: "[task-id]"
----
-
-# CreateTaskResearch (b-003)
-
-## 目的
-
-- 実装に着手する前に、最適なアプローチ・技術・注意点を整理する。
-- 既存コードやコンポーネントを把握し、重複実装や手戻りを防止する。
-- 技術選定・リスク・参考資料を記録し、実装計画 (b-004) の入力とする。
-
-## 前提
-
-- `CreateTaskDefinition (b-002)` が完了し、`a-definition.md` に目的・変更内容が記載されている。
-- タスクディレクトリ: `docs/tasks/task{ID}-{SLUG}/`
-- テンプレート: `../../templates/tasks/task-template/b-research.md`（スキル配置ディレクトリ起点の相対参照）
-
-## 手順
-
-`$ARGUMENTS` が指定されている場合は `task{ID}-{SLUG}`（例: `task000003-auth-login`）として使用する。未指定の場合はユーザーに対象タスクを確認する。
-
-### 1. ドキュメントとテンプレートの準備
-
-対象タスクディレクトリを確認する。
-
-```bash
-ls -d docs/tasks/task*
-```
-
-このスキルの配置ディレクトリ（`skills/b-003-create-task-research/`）を起点に、相対パス `../../templates/tasks/task-template/b-research.md` を Read で読み込み、`docs/tasks/task{ID}-{SLUG}/b-research.md` へ Write する。出力先が既に存在する場合は上書きせずスキップして報告する（冪等）。
-
-### 2. 調査計画の立案
-
-- `a-definition.md` を読み、変更対象・技術要件・制約を抽出。
-- 調査する観点を整理：例）類似実装、利用ライブラリ、外部API仕様、セキュリティ要件。
-- 調査メモを残しながら進めると、ドキュメント作成がスムーズ。
-
-### 3. 既存実装と再利用候補の調査
-
-- コードベースを検索し、類似ロジックやコンポーネントを洗い出す。
-- 再利用できるファイル・モジュール・カスタムフック・APIクライアントをリスト化。
-- 参考にできる実装パターン（バリデーション、エラーハンドリング等）と課題点を併記。
-- 詳細な調査観点・分析項目は [reference/investigation-guide.md](reference/investigation-guide.md) を参照。
-
-### 4. ベストプラクティス・外部情報の調査
-
-- 公式ドキュメント、信頼できる記事、社内ナレッジを確認し、採用すべきパターン/アンチパターンを整理。
-- 調査内容（タイトル、要点、URL）を記録。例）フォームバリデーション、非同期通信、セキュリティガイドライン。
-
-### 5. 技術選定と比較（必要時）
-
-- 新規導入・置き換え候補のライブラリ/サービスを比較。
-- 比較観点: メンテ状況、TypeScript対応、バンドルサイズ、コスト、既存スタックとの親和性。
-- 選定理由と却下理由を記録。チーム合意が必要な場合はその旨も記載。
-- 詳細な比較観点は [reference/investigation-guide.md](reference/investigation-guide.md) を参照。
-
-### 6. 技術的リスクと対策
-
-- パフォーマンス、セキュリティ、スケーラビリティ、依存サービス等のリスクを洗い出す。
-- 影響度と優先度（高/中/低）を付与し、軽減策やPoCの必要有無を記載。
-- リスクカテゴリ一覧とセキュリティチェック項目は [reference/investigation-guide.md](reference/investigation-guide.md) を参照。
-
-### 7. ドキュメントへの反映
-
-1. `docs/tasks/task{ID}-{SLUG}/b-research.md` を編集し、以下を記入：
-   - ベストプラクティス / 参考リンク
-   - 既存コード・再利用コンポーネント
-   - 技術選定（比較表含む）
-   - 技術的リスク・制約
-   - メモ / 次に確認すべき事項
-2. HTMLコメントはガイドとして残す。
-3. 各セクションの表テンプレートは [examples/research-tables.md](examples/research-tables.md) を参照。
-
-### 8. 構造チェック
-
-```bash
-grep "## ベストプラクティス" docs/tasks/task{ID}-{SLUG}/b-research.md \
- && grep "## 既存コード調査" docs/tasks/task{ID}-{SLUG}/b-research.md \
- && grep "## 技術選定" docs/tasks/task{ID}-{SLUG}/b-research.md \
- && grep "## 技術的リスク" docs/tasks/task{ID}-{SLUG}/b-research.md \
- && echo "OK" || echo "MISSING SECTION"
-```
-
-チェックリスト:
-
-- [ ] 参考リンク・出典が記載されている
-- [ ] 再利用できるコード/コンポーネントが明確
-- [ ] 技術選定理由と代替案が整理されている
-- [ ] リスクに軽減策と優先度が付与されている
-
-### 9. Git への追加（任意）
-
-```bash
-git add docs/tasks/task{ID}-{SLUG}/b-research.md
-git commit -m "docs(task): 技術調査メモの作成 task{ID}"
-```
-
-## 完了条件
-
-- `b-research.md` に以下が網羅されている：
-  - ベストプラクティス／参考資料
-  - 既存コード・再利用コンポーネント
-  - 技術選定と比較（必要に応じて）
-  - 技術的リスクと対策
-  - 追加のメモ／未解決事項
-- 実装計画 (b-004) に渡せるレベルで情報が整理されている。
-- 関係者が内容を確認し、疑問があれば解消済み。
-
-## エスカレーション
-
-- **既存コードが見つからない**: 「コードベースを検索しても見つからない場合、他メンバーに確認し、再利用可否を判断してください。」
-- **ライブラリ選定で決め手がない**: 「評価軸を追加（保守実績、サポート、コストなど）し、比較表を拡張してください。」
-- **リスクが高い**: 「影響が重大なリスクは PoC や専門チーム相談を提案し、スケジュールに反映してください。」
-- **外部サービス依存がある**: 「SLA・レート制限・コストを確認し、代替案やフォールバックを検討してください。」
-- **ドキュメントが不足**: 「ベストプラクティスや参考資料の記載が不十分です。公式ドキュメントや社内ナレッジを追加してください。」
-- **セキュリティリスクが見落とされている**: 「入力バリデーション／XSS/CSRF/SQLi／認証・認可／暗号化／レート制限の観点で再調査してください。」
-- **パフォーマンスリスクが見落とされている**: 「大量データや高負荷時の動作を検討してください。」
-- **新ライブラリ導入がチーム未合意**: 「チームリーダーやメンバーとレビュー・合意を取ってください。」
-
-## 参考
-
-- [reference/investigation-guide.md](reference/investigation-guide.md) — 調査観点・分析項目・リスクカテゴリの詳細
-- [examples/research-tables.md](examples/research-tables.md) — 各セクションの表テンプレート例
+---
+name: b-003-create-task-research
+description: タスク実装前に既存コード・ベストプラクティス・再利用候補・リスクを調査し b-research.md に記録する。タスク定義確定後、実装計画作成前に使用。
+disable-model-invocation: true
+allowed-tools: Read, Write, Edit, Bash, Grep, Glob
+argument-hint: "[task-id]"
+---
+
+# CreateTaskResearch (b-003)
+
+## 目的
+
+- 実装に着手する前に、最適なアプローチ・技術・注意点を整理する。
+- 既存コードやコンポーネントを把握し、重複実装や手戻りを防止する。
+- 技術選定・リスク・参考資料を記録し、実装計画 (b-004) の入力とする。
+
+## 前提
+
+- `CreateTaskDefinition (b-002)` が完了し、`a-definition.md` に目的・変更内容が記載されている。
+- タスクディレクトリ: `docs/tasks/task{ID}-{SLUG}/`
+- テンプレート: `../../templates/tasks/task-template/b-research.md`（スキル配置ディレクトリ起点の相対参照）
+
+## 手順
+
+`$ARGUMENTS` が指定されている場合は `task{ID}-{SLUG}`（例: `task000003-auth-login`）として使用する。未指定の場合はユーザーに対象タスクを確認する。
+
+### 1. ドキュメントとテンプレートの準備
+
+対象タスクディレクトリを確認する。
+
+```bash
+ls -d docs/tasks/task*
+```
+
+このスキルの配置ディレクトリ（`skills/b-003-create-task-research/`）を起点に、相対パス `../../templates/tasks/task-template/b-research.md` を Read で読み込み、`docs/tasks/task{ID}-{SLUG}/b-research.md` へ Write する。出力先が既に存在する場合は上書きせずスキップして報告する（冪等）。
+
+### 2. 調査計画の立案
+
+- `a-definition.md` を読み、変更対象・技術要件・制約を抽出。
+- 調査する観点を整理：例）類似実装、利用ライブラリ、外部API仕様、セキュリティ要件。
+- 調査メモを残しながら進めると、ドキュメント作成がスムーズ。
+
+### 3. 既存実装と再利用候補の調査
+
+- コードベースを検索し、類似ロジックやコンポーネントを洗い出す。
+- 再利用できるファイル・モジュール・カスタムフック・APIクライアントをリスト化。
+- 参考にできる実装パターン（バリデーション、エラーハンドリング等）と課題点を併記。
+- 詳細な調査観点・分析項目は [reference/investigation-guide.md](reference/investigation-guide.md) を参照。
+
+### 4. ベストプラクティス・外部情報の調査
+
+- 公式ドキュメント、信頼できる記事、社内ナレッジを確認し、採用すべきパターン/アンチパターンを整理。
+- 調査内容（タイトル、要点、URL）を記録。例）フォームバリデーション、非同期通信、セキュリティガイドライン。
+
+### 5. 技術選定と比較（必要時）
+
+- 新規導入・置き換え候補のライブラリ/サービスを比較。
+- 比較観点: メンテ状況、TypeScript対応、バンドルサイズ、コスト、既存スタックとの親和性。
+- 選定理由と却下理由を記録。チーム合意が必要な場合はその旨も記載。
+- 詳細な比較観点は [reference/investigation-guide.md](reference/investigation-guide.md) を参照。
+
+### 6. 技術的リスクと対策
+
+- パフォーマンス、セキュリティ、スケーラビリティ、依存サービス等のリスクを洗い出す。
+- 影響度と優先度（高/中/低）を付与し、軽減策やPoCの必要有無を記載。
+- リスクカテゴリ一覧とセキュリティチェック項目は [reference/investigation-guide.md](reference/investigation-guide.md) を参照。
+
+### 7. ドキュメントへの反映
+
+1. `docs/tasks/task{ID}-{SLUG}/b-research.md` を編集し、以下を記入：
+   - ベストプラクティス / 参考リンク
+   - 既存コード・再利用コンポーネント
+   - 技術選定（比較表含む）
+   - 技術的リスク・制約
+   - メモ / 次に確認すべき事項
+2. HTMLコメントはガイドとして残す。
+3. 各セクションの表テンプレートは [examples/research-tables.md](examples/research-tables.md) を参照。
+
+### 8. 構造チェック
+
+```bash
+grep "## ベストプラクティス" docs/tasks/task{ID}-{SLUG}/b-research.md \
+ && grep "## 既存コード調査" docs/tasks/task{ID}-{SLUG}/b-research.md \
+ && grep "## 技術選定" docs/tasks/task{ID}-{SLUG}/b-research.md \
+ && grep "## 技術的リスク" docs/tasks/task{ID}-{SLUG}/b-research.md \
+ && echo "OK" || echo "MISSING SECTION"
+```
+
+チェックリスト:
+
+- [ ] 参考リンク・出典が記載されている
+- [ ] 再利用できるコード/コンポーネントが明確
+- [ ] 技術選定理由と代替案が整理されている
+- [ ] リスクに軽減策と優先度が付与されている
+
+### 9. Git への追加（任意）
+
+```bash
+git add docs/tasks/task{ID}-{SLUG}/b-research.md
+git commit -m "docs(task): 技術調査メモの作成 task{ID}"
+```
+
+## 完了条件
+
+- `b-research.md` に以下が網羅されている：
+  - ベストプラクティス／参考資料
+  - 既存コード・再利用コンポーネント
+  - 技術選定と比較（必要に応じて）
+  - 技術的リスクと対策
+  - 追加のメモ／未解決事項
+- 実装計画 (b-004) に渡せるレベルで情報が整理されている。
+- 関係者が内容を確認し、疑問があれば解消済み。
+
+## エスカレーション
+
+- **既存コードが見つからない**: 「コードベースを検索しても見つからない場合、他メンバーに確認し、再利用可否を判断してください。」
+- **ライブラリ選定で決め手がない**: 「評価軸を追加（保守実績、サポート、コストなど）し、比較表を拡張してください。」
+- **リスクが高い**: 「影響が重大なリスクは PoC や専門チーム相談を提案し、スケジュールに反映してください。」
+- **外部サービス依存がある**: 「SLA・レート制限・コストを確認し、代替案やフォールバックを検討してください。」
+- **ドキュメントが不足**: 「ベストプラクティスや参考資料の記載が不十分です。公式ドキュメントや社内ナレッジを追加してください。」
+- **セキュリティリスクが見落とされている**: 「入力バリデーション／XSS/CSRF/SQLi／認証・認可／暗号化／レート制限の観点で再調査してください。」
+- **パフォーマンスリスクが見落とされている**: 「大量データや高負荷時の動作を検討してください。」
+- **新ライブラリ導入がチーム未合意**: 「チームリーダーやメンバーとレビュー・合意を取ってください。」
+
+## 参考
+
+- [reference/investigation-guide.md](reference/investigation-guide.md) — 調査観点・分析項目・リスクカテゴリの詳細
+- [examples/research-tables.md](examples/research-tables.md) — 各セクションの表テンプレート例

package/skills/b-004-create-task-implementation/SKILL.md

@@ -1,98 +1,98 @@
----
-name: b-004-create-task-implementation
-description: タスクをステップ単位に分割し、各ステップの成果物・受け入れ基準を c-implementation.md に定義する。リサーチ完了後、実装着手前に使用。
-disable-model-invocation: true
-allowed-tools: Read, Write, Edit, Bash, Grep, Glob
-argument-hint: "[task-id]"
----
-
-# CreateTaskImplementation (b-004)
-
-## 目的
-
-- タスクを実行可能なフェーズとステップに分割し、作業順序と依存関係を明確にする。
-- 各ステップの成果物と受け入れ基準を定義し、作業完了の判断基準を共有する。
-- 実装開始前にテスト計画や懸念点を洗い出し、品質リスクを低減する。
-
-## 前提
-
-- `a-definition.md`（b-002）と `b-research.md`（b-003）が作成済み
-- タスクディレクトリ: `docs/tasks/task{ID}-{SLUG}/`
-- テンプレート: `../../templates/tasks/task-template/c-implementation.md`（スキル配置ディレクトリ起点の相対参照）
-
-## 手順
-
-`$ARGUMENTS` が指定されている場合は `task{ID}-{SLUG}`（例: `task000003-auth-login`）として使用する。未指定の場合はユーザーに対象タスクを確認する。
-
-### 1. ドキュメント確認とテンプレート準備
-
-対象タスクディレクトリを確認する。
-
-```bash
-ls -d docs/tasks/task*
-```
-
-このスキルの配置ディレクトリ（`skills/b-004-create-task-implementation/`）を起点に、相対パス `../../templates/tasks/task-template/c-implementation.md` を Read で読み込み、`docs/tasks/task{ID}-{SLUG}/c-implementation.md` へ Write する。出力先が既に存在する場合は上書きせずスキップして報告する（冪等）。
-
-`a-definition.md` から目的・変更内容・受け入れ基準を、`b-research.md` から技術方針・ライブラリ選定・リスクを読み取る。
-
-### 2. フェーズ設計
-
-タスクを 2〜4 フェーズに分割（1 フェーズ = 1〜3 日規模）。分割の考え方と例は [examples/phase-step-template.md](examples/phase-step-template.md#フェーズ分割の目安) を参照。
-
-### 3. ステップ分解
-
-各フェーズを 1〜3 時間で完了できるステップに分割し、Title / Details / Deliverables / Verification を定義。記載例は [examples/phase-step-template.md](examples/phase-step-template.md#ステップ分解のテンプレート) を参照。
-
-### 4. テスト計画
-
-フェーズ／ステップ単位で必要なテスト（ユニット、API、UI、E2E、負荷）とカバレッジ目標、検証コマンド（`npm test`, `playwright test` 等）を記載。例は [examples/phase-step-template.md](examples/phase-step-template.md#テスト計画の記載例) を参照。
-
-### 5. ドキュメント反映
-
-`docs/tasks/task{ID}-{SLUG}/c-implementation.md` に以下を記入:
-
-1. フェーズ一覧（目的、完了条件、依存関係）
-2. フェーズ内ステップ（Title/Details/Deliverables/Verification）
-3. テスト計画
-4. メモ・補足（懸念点、要確認事項、リファクタ案）
-
-HTML コメントは削除せずガイドとして残す。
-
-### 6. 構造チェック
-
-```bash
-grep "## 実装フェーズ" docs/tasks/task{ID}-{SLUG}/c-implementation.md \
-  && grep "## ステップ一覧" docs/tasks/task{ID}-{SLUG}/c-implementation.md \
-  && grep "## テスト計画" docs/tasks/task{ID}-{SLUG}/c-implementation.md \
-  && echo "OK" || echo "MISSING SECTION"
-```
-
-チェックリストは [reference/structure-check.md](reference/structure-check.md#チェックリスト) を参照。
-
-### 7. Git への追加（任意）
-
-```bash
-git add docs/tasks/task{ID}-{SLUG}/c-implementation.md
-git commit -m "docs(task): 実装計画の作成 task{ID}"
-```
-
-## 完了条件
-
-- `c-implementation.md` にフェーズ／ステップ／テスト／メモが記載されている
-- ステップの粒度が適切（1〜3 時間）で、成果物が明確
-- フェーズ順序と依存関係が示されている
-- 関係者レビューで疑問がない状態
-
-## エスカレーション
-
-- **フェーズが大きすぎる**: 「1 フェーズが 3 日以上になりそうです。分割してください。」
-- **ステップが抽象的**: 「成果物が特定できません。ファイル名や検証手順を明記してください。」
-- **テスト計画不足**: 「対象機能のテスト戦略が不足しています。ユニット/統合/E2E を再検討してください。」
-- **リスク対策未反映**: 「b-003 で挙げたリスクへの対策ステップがありません。計画に組み込んでください。」
-- **依存関係不明**: 「並行実行可能なフェーズと、順序が必要なフェーズを明示してください。」
-
-## 参考
-
-- [examples/phase-step-template.md](examples/phase-step-template.md) — フェーズ分割、ステップ分解、テスト計画の記載例
-- [reference/structure-check.md](reference/structure-check.md) — 構造確認コマンド、チェックリスト、レビュー観点
+---
+name: b-004-create-task-implementation
+description: タスクをステップ単位に分割し、各ステップの成果物・受け入れ基準を c-implementation.md に定義する。リサーチ完了後、実装着手前に使用。
+disable-model-invocation: true
+allowed-tools: Read, Write, Edit, Bash, Grep, Glob
+argument-hint: "[task-id]"
+---
+
+# CreateTaskImplementation (b-004)
+
+## 目的
+
+- タスクを実行可能なフェーズとステップに分割し、作業順序と依存関係を明確にする。
+- 各ステップの成果物と受け入れ基準を定義し、作業完了の判断基準を共有する。
+- 実装開始前にテスト計画や懸念点を洗い出し、品質リスクを低減する。
+
+## 前提
+
+- `a-definition.md`（b-002）と `b-research.md`（b-003）が作成済み
+- タスクディレクトリ: `docs/tasks/task{ID}-{SLUG}/`
+- テンプレート: `../../templates/tasks/task-template/c-implementation.md`（スキル配置ディレクトリ起点の相対参照）
+
+## 手順
+
+`$ARGUMENTS` が指定されている場合は `task{ID}-{SLUG}`（例: `task000003-auth-login`）として使用する。未指定の場合はユーザーに対象タスクを確認する。
+
+### 1. ドキュメント確認とテンプレート準備
+
+対象タスクディレクトリを確認する。
+
+```bash
+ls -d docs/tasks/task*
+```
+
+このスキルの配置ディレクトリ（`skills/b-004-create-task-implementation/`）を起点に、相対パス `../../templates/tasks/task-template/c-implementation.md` を Read で読み込み、`docs/tasks/task{ID}-{SLUG}/c-implementation.md` へ Write する。出力先が既に存在する場合は上書きせずスキップして報告する（冪等）。
+
+`a-definition.md` から目的・変更内容・受け入れ基準を、`b-research.md` から技術方針・ライブラリ選定・リスクを読み取る。
+
+### 2. フェーズ設計
+
+タスクを 2〜4 フェーズに分割（1 フェーズ = 1〜3 日規模）。分割の考え方と例は [examples/phase-step-template.md](examples/phase-step-template.md#フェーズ分割の目安) を参照。
+
+### 3. ステップ分解
+
+各フェーズを 1〜3 時間で完了できるステップに分割し、Title / Details / Deliverables / Verification を定義。記載例は [examples/phase-step-template.md](examples/phase-step-template.md#ステップ分解のテンプレート) を参照。
+
+### 4. テスト計画
+
+フェーズ／ステップ単位で必要なテスト（ユニット、API、UI、E2E、負荷）とカバレッジ目標、検証コマンド（`npm test`, `playwright test` 等）を記載。例は [examples/phase-step-template.md](examples/phase-step-template.md#テスト計画の記載例) を参照。
+
+### 5. ドキュメント反映
+
+`docs/tasks/task{ID}-{SLUG}/c-implementation.md` に以下を記入:
+
+1. フェーズ一覧（目的、完了条件、依存関係）
+2. フェーズ内ステップ（Title/Details/Deliverables/Verification）
+3. テスト計画
+4. メモ・補足（懸念点、要確認事項、リファクタ案）
+
+HTML コメントは削除せずガイドとして残す。
+
+### 6. 構造チェック
+
+```bash
+grep "## 実装フェーズ" docs/tasks/task{ID}-{SLUG}/c-implementation.md \
+  && grep "## ステップ一覧" docs/tasks/task{ID}-{SLUG}/c-implementation.md \
+  && grep "## テスト計画" docs/tasks/task{ID}-{SLUG}/c-implementation.md \
+  && echo "OK" || echo "MISSING SECTION"
+```
+
+チェックリストは [reference/structure-check.md](reference/structure-check.md#チェックリスト) を参照。
+
+### 7. Git への追加（任意）
+
+```bash
+git add docs/tasks/task{ID}-{SLUG}/c-implementation.md
+git commit -m "docs(task): 実装計画の作成 task{ID}"
+```
+
+## 完了条件
+
+- `c-implementation.md` にフェーズ／ステップ／テスト／メモが記載されている
+- ステップの粒度が適切（1〜3 時間）で、成果物が明確
+- フェーズ順序と依存関係が示されている
+- 関係者レビューで疑問がない状態
+
+## エスカレーション
+
+- **フェーズが大きすぎる**: 「1 フェーズが 3 日以上になりそうです。分割してください。」
+- **ステップが抽象的**: 「成果物が特定できません。ファイル名や検証手順を明記してください。」
+- **テスト計画不足**: 「対象機能のテスト戦略が不足しています。ユニット/統合/E2E を再検討してください。」
+- **リスク対策未反映**: 「b-003 で挙げたリスクへの対策ステップがありません。計画に組み込んでください。」
+- **依存関係不明**: 「並行実行可能なフェーズと、順序が必要なフェーズを明示してください。」
+
+## 参考
+
+- [examples/phase-step-template.md](examples/phase-step-template.md) — フェーズ分割、ステップ分解、テスト計画の記載例
+- [reference/structure-check.md](reference/structure-check.md) — 構造確認コマンド、チェックリスト、レビュー観点

package/skills/b-005-review-task/reference/assessment-criteria.md

@@ -1,79 +1,79 @@
-# 評価基準・修正ガイダンス
-
-SKILL.md 手順5「実装開始可否の判定」で参照する基準とアクション。
-
-## 総合評価の基準
-
-- **優（実装開始OK）**: Error 0件、Warning 3件以下
-- **良（軽微な修正後に実装開始）**: Error 0件、Warning 4-10件
-- **可（修正後に実装開始）**: Error 1-3件、または Warning 11件以上
-- **不可（大幅な見直しが必要）**: Error 4件以上
-
-## 推奨アクション
-
-- 総合評価が「優」「良」の場合：「実装開始可能です。`/c-001-implement-task` を実行してください。」
-- 総合評価が「可」の場合：「Error を修正後、実装を開始してください。」
-- 総合評価が「不可」の場合：「タスクドキュメント全体の見直しが必要です。チームでレビュー会議を実施することを推奨します。」
-
-## 修正ガイダンス
-
-検出された問題について、修正方法を提案：
-
-- Errorが検出された場合：「以下の問題を優先的に修正してください：」
-- 修正すべきドキュメントとスキルを案内：
-  - 例：「ユーザーストーリーUS-002に対応する実装ステップがありません → `/b-004-create-task-implementation` で実装計画を更新」
-  - 例：「受け入れ基準が一致していません → `/b-002-create-task-definition` でタスク定義を見直し」
-
-ユーザーに確認：「今すぐ修正作業を開始しますか？それとも後で個別に修正しますか？」
-
-## ベストプラクティス
-
-- **実装開始前に必ず実行**: c-001 実行前に b-005 でレビューし、問題を早期発見
-- **段階的レビュー**: b-001完了後、b-002完了後、b-003完了後の各段階で部分レビューを実施
-- **チームレビュー**: 重要なタスクや大規模なタスクはチーム全体でレビュー会議を実施
-- **継続的更新**: 実装中に新しい発見があれば、ドキュメントを更新し、再レビュー
-- **メトリクス記録**: レビュー結果（Error数、Warning数）を記録し、タスク品質を追跡
-- **フィードバックループ**: レビュー結果を基にテンプレートや次のタスクを改善
-
-## 参考: レビュー対象ドキュメント構造
-
-**a-definition.md（タスク定義）**:
-
-- 目的（解決する問題、提供する価値）
-- ユーザーストーリー一覧
-- 変更内容一覧（画面、データモデル、API、その他）
-- 受け入れ基準
-
-**b-research.md（リサーチ）**:
-
-- ベストプラクティス
-- 既存コードの調査
-- 再利用可能なコンポーネント
-- 技術選定
-- 技術的リスクと制約
-
-**c-implementation.md（実装計画）**:
-
-- フェーズ（目的、完了条件）
-- ステップ（成果物、詳細）
-- 受け入れ基準
-
-## 参考: タスクライフサイクルにおける位置づけ
-
-```
-b-001: タスクディレクトリ作成
-  ↓
-b-002: タスク定義作成
-  ↓
-b-003: リサーチ実施
-  ↓
-b-004: 実装計画作成
-  ↓
-b-005: タスクレビュー ← このスキル
-  ↓
-c-001: 実装実行
-  ↓
-c-002: ドキュメント更新
-```
-
-b-005 は実装開始前の「最後の砦」として、タスクの品質と実現可能性を保証する重要な役割を果たします。
+# 評価基準・修正ガイダンス
+
+SKILL.md 手順5「実装開始可否の判定」で参照する基準とアクション。
+
+## 総合評価の基準
+
+- **優（実装開始OK）**: Error 0件、Warning 3件以下
+- **良（軽微な修正後に実装開始）**: Error 0件、Warning 4-10件
+- **可（修正後に実装開始）**: Error 1-3件、または Warning 11件以上
+- **不可（大幅な見直しが必要）**: Error 4件以上
+
+## 推奨アクション
+
+- 総合評価が「優」「良」の場合：「実装開始可能です。`/c-001-implement-task` を実行してください。」
+- 総合評価が「可」の場合：「Error を修正後、実装を開始してください。」
+- 総合評価が「不可」の場合：「タスクドキュメント全体の見直しが必要です。チームでレビュー会議を実施することを推奨します。」
+
+## 修正ガイダンス
+
+検出された問題について、修正方法を提案：
+
+- Errorが検出された場合：「以下の問題を優先的に修正してください：」
+- 修正すべきドキュメントとスキルを案内：
+  - 例：「ユーザーストーリーUS-002に対応する実装ステップがありません → `/b-004-create-task-implementation` で実装計画を更新」
+  - 例：「受け入れ基準が一致していません → `/b-002-create-task-definition` でタスク定義を見直し」
+
+ユーザーに確認：「今すぐ修正作業を開始しますか？それとも後で個別に修正しますか？」
+
+## ベストプラクティス
+
+- **実装開始前に必ず実行**: c-001 実行前に b-005 でレビューし、問題を早期発見
+- **段階的レビュー**: b-001完了後、b-002完了後、b-003完了後の各段階で部分レビューを実施
+- **チームレビュー**: 重要なタスクや大規模なタスクはチーム全体でレビュー会議を実施
+- **継続的更新**: 実装中に新しい発見があれば、ドキュメントを更新し、再レビュー
+- **メトリクス記録**: レビュー結果（Error数、Warning数）を記録し、タスク品質を追跡
+- **フィードバックループ**: レビュー結果を基にテンプレートや次のタスクを改善
+
+## 参考: レビュー対象ドキュメント構造
+
+**a-definition.md（タスク定義）**:
+
+- 目的（解決する問題、提供する価値）
+- ユーザーストーリー一覧
+- 変更内容一覧（画面、データモデル、API、その他）
+- 受け入れ基準
+
+**b-research.md（リサーチ）**:
+
+- ベストプラクティス
+- 既存コードの調査
+- 再利用可能なコンポーネント
+- 技術選定
+- 技術的リスクと制約
+
+**c-implementation.md（実装計画）**:
+
+- フェーズ（目的、完了条件）
+- ステップ（成果物、詳細）
+- 受け入れ基準
+
+## 参考: タスクライフサイクルにおける位置づけ
+
+```
+b-001: タスクディレクトリ作成
+  ↓
+b-002: タスク定義作成
+  ↓
+b-003: リサーチ実施
+  ↓
+b-004: 実装計画作成
+  ↓
+b-005: タスクレビュー ← このスキル
+  ↓
+c-001: 実装実行
+  ↓
+c-002: ドキュメント更新
+```
+
+b-005 は実装開始前の「最後の砦」として、タスクの品質と実現可能性を保証する重要な役割を果たします。