yodogawa 2.1.0 → 2.1.3

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

@@ -1,97 +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}/`
-- テンプレート: `{IDE_DIR}/templates/tasks/task-template/c-implementation.md`
-
-## 手順
-
-`$ARGUMENTS` が指定されている場合は `task{ID}-{SLUG}`（例: `task000003-auth-login`）として使用する。未指定の場合はユーザーに対象タスクを確認する。
-
-### 1. ドキュメント確認とテンプレート準備
-
-```bash
-ls -d docs/tasks/task*
-SCRIPT_DIR=$(for d in .agent .cursor .claude .codex; do [ -d "$d" ] && echo "$d" && break; done)
-cp "$SCRIPT_DIR/templates/tasks/task-template/c-implementation.md" \
-   "docs/tasks/task{ID}-{SLUG}/c-implementation.md"
-```
-
-`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-ImplementTask` を実行してください。」
-- 総合評価が「可」の場合：「Error を修正後、実装を開始してください。」
-- 総合評価が「不可」の場合：「タスクドキュメント全体の見直しが必要です。チームでレビュー会議を実施することを推奨します。」
-
-## 修正ガイダンス
-
-検出された問題について、修正方法を提案：
-
-- Errorが検出された場合：「以下の問題を優先的に修正してください：」
-- 修正すべきドキュメントとスキルを案内：
-  - 例：「ユーザーストーリーUS-002に対応する実装ステップがありません → `/b-003-CreateTaskImplementation` で実装計画を更新」
-  - 例：「受け入れ基準が一致していません → `/b-001-CreateTaskDefinition` でタスク定義を見直し」
-
-ユーザーに確認：「今すぐ修正作業を開始しますか？それとも後で個別に修正しますか？」
-
-## ベストプラクティス
-
-- **実装開始前に必ず実行**: 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 は実装開始前の「最後の砦」として、タスクの品質と実現可能性を保証する重要な役割を果たします。