yodogawa 2.1.0 → 2.1.3

package/skills/b-001-create-task-directory/SKILL.md

@@ -1,68 +1,68 @@
----
-name: b-001-create-task-directory
-description: docs/tasks/ 配下に連番タスク ID 付きディレクトリ（a-definition.md / b-research.md / c-implementation.md）を作成する。新しい実装タスクに着手する最初の手順として使用。
-disable-model-invocation: true
-argument-hint: "[slug]"
-allowed-tools: Read, Write, Bash, Glob
----
-
-# CreateTaskDirectory (b-001)
-
-## 目的
-
-- 新しいタスク専用のディレクトリを作成する。
-- タスク ID の採番ルール（`taskXXXXXX`）を統一し、管理しやすくする。
-- **注意**: このスキルはディレクトリ作成のみ。タスク定義書などのドキュメント作成は後続のスキル（`/b-002-create-task-definition` など）で実施。
-
-## 前提
-
-- `docs/tasks/` ディレクトリが存在すること
-
-## 手順
-
-### 1. 既存タスクの確認と ID 採番
-
-```bash
-ls -d docs/tasks/task*
-```
-
-採番ルールとスラッグ命名は [examples/naming-convention.md](examples/naming-convention.md) を参照。
-
-### 2. タスク名の決定
-
-`$ARGUMENTS` が指定されている場合はそれをスラッグとして使用する。未指定の場合のみユーザーに質問:
-
-- 「タスクの内容を 3〜5 語の英数字とハイフンで表現してください（例: `user-profile-edit`）。」
-
-### 3. ディレクトリの作成
-
-```bash
-mkdir -p docs/tasks/task{ID}-{SLUG}
-# 例
-mkdir -p docs/tasks/task000001-email-auth
-```
-
-### 4. 作成確認
-
-```bash
-ls -ld docs/tasks/task{ID}-{SLUG} && echo "OK" || echo "FAILED"
-```
-
-### 5. 次のステップの案内
-
-- 「ディレクトリ `docs/tasks/task{ID}-{SLUG}` を作成しました。」
-- 「続いてタスク定義書を作成しますか？（`/b-002-create-task-definition`）」
-
-## 完了条件
-
-- `docs/tasks/task{ID}-{SLUG}/` ディレクトリが作成されている
-- ユーザーにディレクトリパスが報告されている
-
-## エスカレーション
-
-- **`docs/tasks/` が見つからない**: `mkdir -p docs/tasks` を実行するか、`/a-001-setup-doc-structure` の確認を促す
-- **命名規則違反**: タスク名にスペースや特殊文字が含まれる場合、修正を求める
-
-## 参考
-
-- [examples/naming-convention.md](examples/naming-convention.md) — タスク ID の採番ルールとスラッグ命名規則
+---
+name: b-001-create-task-directory
+description: docs/tasks/ 配下に連番タスク ID 付きディレクトリを作成する。新しい実装タスクに着手する最初の手順として使用。
+disable-model-invocation: true
+argument-hint: "[slug]"
+allowed-tools: Read, Write, Bash, Glob
+---
+
+# CreateTaskDirectory (b-001)
+
+## 目的
+
+- 新しいタスク専用のディレクトリを作成する（ID は自動採番）。
+- タスク ID の採番ルール（`taskXXXXXX`）を統一し、管理しやすくする。
+- **注意**: このスキルはディレクトリ作成のみ。タスク定義書などのドキュメント作成は後続のスキル（`/b-002-create-task-definition` など）で実施。
+
+## 前提
+
+- `docs/tasks/` ディレクトリが存在すること（未作成なら `/a-001-setup-doc-structure` を先に実行）
+
+## 手順
+
+### 1. スラッグの決定
+
+`$ARGUMENTS` が指定されている場合はそれをスラッグとして使用する。未指定の場合のみユーザーに質問:
+
+- 「タスクの内容を 3〜5 語の英数字とハイフンで表現してください（例: `user-profile-edit`）。」
+
+命名規則の詳細は [examples/naming-convention.md](examples/naming-convention.md) を参照。
+
+### 2. タスク ID の採番とディレクトリ作成
+
+決定したスラッグについて、次を順に行う。
+
+1. **形式チェック**: スラッグが正規表現 `^[a-z0-9]+(-[a-z0-9]+)*$`（英小文字・数字・ハイフンのみ、連続ハイフン禁止）に一致するか確認。3〜5 語を推奨（範囲外は警告のみで続行）。違反時はエスカレーション参照。
+2. **ID の採番**: `docs/tasks/` 配下の `task{6桁数字}-*` ディレクトリから最大 ID を求め、+1 を 6 桁ゼロ詰めした `task{ID}`（例: `task000003`）とする。タスクが無ければ `task000001`。
+3. **ディレクトリ作成**: `docs/tasks/task{ID}-{SLUG}` を作成する。
+
+```bash
+# 既存タスクを確認して最大 ID を把握
+ls -d docs/tasks/task* 2>/dev/null
+
+# 採番した ID とスラッグでディレクトリを作成（{ID}/{SLUG} は実値に置換）
+mkdir -p "docs/tasks/task{ID}-{SLUG}"
+```
+
+### 3. 結果の確認
+
+作成パス（`docs/tasks/task{ID}-{SLUG}`）が生成されたことを確認。
+
+### 4. 次のステップの案内
+
+- 「タスクディレクトリ `docs/tasks/task{ID}-{SLUG}` を作成しました。」
+- 「続いてタスク定義書を作成しますか？（`/b-002-create-task-definition`）」
+
+## 完了条件
+
+- `docs/tasks/task{ID}-{SLUG}/` ディレクトリが作成されている
+- ユーザーに作成されたディレクトリパスが報告されている
+
+## エスカレーション
+
+- **`docs/tasks/` が見つからない**: ディレクトリが無い場合は `/a-001-setup-doc-structure` の実行を促す
+- **スラッグ形式違反**: 英小文字・数字・ハイフンのみ（連続ハイフン禁止）で再入力を求める
+
+## 参考
+
+- [examples/naming-convention.md](examples/naming-convention.md) — タスク ID の採番ルールとスラッグ命名規則

package/skills/b-002-create-task-definition/SKILL.md

@@ -1,115 +1,114 @@
----
-name: b-002-create-task-definition
-description: 対話を通じてタスク定義（目的・変更内容・受け入れ基準）を a-definition.md に記録する。タスクディレクトリ作成後、仕様を確定する際に使用。
-disable-model-invocation: true
-allowed-tools: Read, Write, Edit, Bash, Grep, Glob
-argument-hint: "[task-id]"
----
-
-# CreateTaskDefinition (b-002)
-
-## 目的
-
-- 新しいタスクの背景・目的・スコープを明確化する。
-- ユーザーストーリーと変更内容を整理し、後続のリサーチ・実装計画に渡す。
-- 測定可能な受け入れ基準を定義し、完了条件を共有する。
-
-## 前提
-
-- `docs/tasks/task{ID}-{SLUG}/` が `/b-001-create-task-directory` で作成済み
-- テンプレート: `{IDE_DIR}/templates/tasks/task-template/a-definition.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/a-definition.md" \
-   "docs/tasks/task{ID}-{SLUG}/a-definition.md"
-```
-
-### 2. 目的・背景のヒアリング
-
-現状の課題、困っている人、完了後の価値/KPI を具体的に確認。質問例は [examples/hearing-and-criteria.md](examples/hearing-and-criteria.md#目的背景のヒアリング) を参照。
-
-### 3. ユーザーストーリーの整理
-
-形式「[役割]として、[目的]がしたい。なぜなら[理由]だから」で作成。優先度と関連 ID（US-001 等）を付与。詳細は [examples/hearing-and-criteria.md](examples/hearing-and-criteria.md#ユーザーストーリー) を参照。
-
-### 4. 変更内容の洗い出し
-
-カテゴリ別（画面/UI、API/サービス、データモデル/DB、その他）に列挙。ファイル名・エンドポイント・テーブル名を具体的に記載。カテゴリ詳細: [examples/hearing-and-criteria.md](examples/hearing-and-criteria.md#変更内容のカテゴリ)
-
-### 5. 受け入れ基準の策定
-
-観点: 正常系、異常系・エラー表示、性能・セキュリティ、テスト要件。具体例は [examples/hearing-and-criteria.md](examples/hearing-and-criteria.md#受け入れ基準の観点) を参照。
-
-### 6. ドキュメントへの反映
-
-`docs/tasks/task{ID}-{SLUG}/a-definition.md` に以下を順に埋める:
-
-- 目的・背景
-- ユーザーストーリー一覧
-- 変更内容一覧
-- 受け入れ基準
-- メモ/補足情報（関連 Issue・制約等）
-
-HTML コメントは削除せず、テンプレートのガイドとして残す。
-
-### 7. 構造チェック
-
-```bash
-grep "## 目的" docs/tasks/task{ID}-{SLUG}/a-definition.md \
-  && grep "## ユーザーストーリー" docs/tasks/task{ID}-{SLUG}/a-definition.md \
-  && grep "## 変更内容" docs/tasks/task{ID}-{SLUG}/a-definition.md \
-  && grep "## 受け入れ基準" docs/tasks/task{ID}-{SLUG}/a-definition.md \
-  && echo "OK" || echo "MISSING SECTION"
-```
-
-詳細チェックリストは [reference/structure-check.md](reference/structure-check.md#チェックリスト) を参照。
-
-### 8. レビューと確認
-
-完成したドキュメントをユーザーに提示し、目的の明確さ・変更内容の網羅性・受け入れ基準の測定可能性を確認。質問例は [reference/structure-check.md](reference/structure-check.md#レビュー確認質問) を参照。
-
-### 9. Git への追加（任意）と次のステップ
-
-```bash
-git add docs/tasks/task{ID}-{SLUG}/a-definition.md
-git commit -m "docs(task): タスク定義書の作成 task{ID}"
-```
-
-次は `/b-003-create-task-research` でリサーチドキュメント作成を提案。
-
-## 完了条件
-
-- `docs/tasks/task{ID}-{SLUG}/a-definition.md` が作成されている
-- 以下のセクションがすべて記載:
-  - 目的（解決する問題、提供する価値）
-  - ユーザーストーリー一覧（最低1個以上）
-  - 変更内容一覧（該当カテゴリがすべて含まれる）
-  - 受け入れ基準（正常系、異常系、テスト要件）
-- 目的が具体的で測定可能、ストーリーは役割/目的/理由形式
-- 変更内容が具体的なファイル名・コンポーネント名を含む
-- ユーザーが内容を確認し承認している
-
-## エスカレーション
-
-- **タスクの目的が曖昧**: 「具体的な問題と解決後の状態を明確にしてください。」
-- **変更内容が不明確**: 「具体的なファイル名・コンポーネント名・カラム名を含めてください。」
-- **受け入れ基準が曖昧**: 「テスト可能な基準を定義してください。」（例: 「使いやすい」→「登録完了まで3クリック以内」）
-- **ユーザーストーリーが技術的すぎる**: ユーザー視点の価値を記載（例: 「React Hook Form を使用したい」→「入力エラーを即座に確認したい」）
-- **スコープが大きすぎる**: 複数タスクへの分割を推奨（1タスクは1〜5日で完了できる粒度が理想）
-- **セキュリティ要件が欠けている**: [reference/structure-check.md](reference/structure-check.md#セキュリティ要件の確認観点) の観点を提示
-
-## 参考
-
-- [examples/hearing-and-criteria.md](examples/hearing-and-criteria.md) — ヒアリング質問、ユーザーストーリー形式、変更内容カテゴリ、受け入れ基準例
-- [reference/structure-check.md](reference/structure-check.md) — 構造確認コマンド、チェックリスト、レビュー観点、セキュリティ観点
+---
+name: b-002-create-task-definition
+description: 対話を通じてタスク定義（目的・変更内容・受け入れ基準）を a-definition.md に記録する。タスクディレクトリ作成後、仕様を確定する際に使用。
+disable-model-invocation: true
+allowed-tools: Read, Write, Edit, Bash, Grep, Glob
+argument-hint: "[task-id]"
+---
+
+# CreateTaskDefinition (b-002)
+
+## 目的
+
+- 新しいタスクの背景・目的・スコープを明確化する。
+- ユーザーストーリーと変更内容を整理し、後続のリサーチ・実装計画に渡す。
+- 測定可能な受け入れ基準を定義し、完了条件を共有する。
+
+## 前提
+
+- `docs/tasks/task{ID}-{SLUG}/` が `/b-001-create-task-directory` で作成済み
+- テンプレート: `../../templates/tasks/task-template/a-definition.md`（スキル配置ディレクトリ起点の相対参照）
+- タスクの概要が関係者と共有済み
+
+## 手順
+
+`$ARGUMENTS` が指定されている場合は `task{ID}-{SLUG}`（例: `task000003-auth-login`）として使用する。未指定の場合はユーザーに対象タスクを確認する。
+
+### 1. タスクディレクトリとテンプレートの確認
+
+対象タスクディレクトリを確認する。
+
+```bash
+ls -d docs/tasks/task*
+```
+
+このスキルの配置ディレクトリ（`skills/b-002-create-task-definition/`）を起点に、相対パス `../../templates/tasks/task-template/a-definition.md` を Read で読み込み、`docs/tasks/task{ID}-{SLUG}/a-definition.md` へ Write する。出力先が既に存在する場合は上書きせずスキップして報告する（冪等）。
+
+### 2. 目的・背景のヒアリング
+
+現状の課題、困っている人、完了後の価値/KPI を具体的に確認。質問例は [examples/hearing-and-criteria.md](examples/hearing-and-criteria.md#目的背景のヒアリング) を参照。
+
+### 3. ユーザーストーリーの整理
+
+形式「[役割]として、[目的]がしたい。なぜなら[理由]だから」で作成。優先度と関連 ID（US-001 等）を付与。詳細は [examples/hearing-and-criteria.md](examples/hearing-and-criteria.md#ユーザーストーリー) を参照。
+
+### 4. 変更内容の洗い出し
+
+カテゴリ別（画面/UI、API/サービス、データモデル/DB、その他）に列挙。ファイル名・エンドポイント・テーブル名を具体的に記載。カテゴリ詳細: [examples/hearing-and-criteria.md](examples/hearing-and-criteria.md#変更内容のカテゴリ)
+
+### 5. 受け入れ基準の策定
+
+観点: 正常系、異常系・エラー表示、性能・セキュリティ、テスト要件。具体例は [examples/hearing-and-criteria.md](examples/hearing-and-criteria.md#受け入れ基準の観点) を参照。
+
+### 6. ドキュメントへの反映
+
+`docs/tasks/task{ID}-{SLUG}/a-definition.md` に以下を順に埋める:
+
+- 目的・背景
+- ユーザーストーリー一覧
+- 変更内容一覧
+- 受け入れ基準
+- メモ/補足情報（関連 Issue・制約等）
+
+HTML コメントは削除せず、テンプレートのガイドとして残す。
+
+### 7. 構造チェック
+
+```bash
+grep "## 目的" docs/tasks/task{ID}-{SLUG}/a-definition.md \
+  && grep "## ユーザーストーリー" docs/tasks/task{ID}-{SLUG}/a-definition.md \
+  && grep "## 変更内容" docs/tasks/task{ID}-{SLUG}/a-definition.md \
+  && grep "## 受け入れ基準" docs/tasks/task{ID}-{SLUG}/a-definition.md \
+  && echo "OK" || echo "MISSING SECTION"
+```
+
+詳細チェックリストは [reference/structure-check.md](reference/structure-check.md#チェックリスト) を参照。
+
+### 8. レビューと確認
+
+完成したドキュメントをユーザーに提示し、目的の明確さ・変更内容の網羅性・受け入れ基準の測定可能性を確認。質問例は [reference/structure-check.md](reference/structure-check.md#レビュー確認質問) を参照。
+
+### 9. Git への追加（任意）と次のステップ
+
+```bash
+git add docs/tasks/task{ID}-{SLUG}/a-definition.md
+git commit -m "docs(task): タスク定義書の作成 task{ID}"
+```
+
+次は `/b-003-create-task-research` でリサーチドキュメント作成を提案。
+
+## 完了条件
+
+- `docs/tasks/task{ID}-{SLUG}/a-definition.md` が作成されている
+- 以下のセクションがすべて記載:
+  - 目的（解決する問題、提供する価値）
+  - ユーザーストーリー一覧（最低1個以上）
+  - 変更内容一覧（該当カテゴリがすべて含まれる）
+  - 受け入れ基準（正常系、異常系、テスト要件）
+- 目的が具体的で測定可能、ストーリーは役割/目的/理由形式
+- 変更内容が具体的なファイル名・コンポーネント名を含む
+- ユーザーが内容を確認し承認している
+
+## エスカレーション
+
+- **タスクの目的が曖昧**: 「具体的な問題と解決後の状態を明確にしてください。」
+- **変更内容が不明確**: 「具体的なファイル名・コンポーネント名・カラム名を含めてください。」
+- **受け入れ基準が曖昧**: 「テスト可能な基準を定義してください。」（例: 「使いやすい」→「登録完了まで3クリック以内」）
+- **ユーザーストーリーが技術的すぎる**: ユーザー視点の価値を記載（例: 「React Hook Form を使用したい」→「入力エラーを即座に確認したい」）
+- **スコープが大きすぎる**: 複数タスクへの分割を推奨（1タスクは1〜5日で完了できる粒度が理想）
+- **セキュリティ要件が欠けている**: [reference/structure-check.md](reference/structure-check.md#セキュリティ要件の確認観点) の観点を提示
+
+## 参考
+
+- [examples/hearing-and-criteria.md](examples/hearing-and-criteria.md) — ヒアリング質問、ユーザーストーリー形式、変更内容カテゴリ、受け入れ基準例
+- [reference/structure-check.md](reference/structure-check.md) — 構造確認コマンド、チェックリスト、レビュー観点、セキュリティ観点

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

@@ -1,130 +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}/`
-- テンプレート: `{IDE_DIR}/templates/tasks/task-template/b-research.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/b-research.md" \
-   "docs/tasks/task{ID}-{SLUG}/b-research.md"
-```
-
-### 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) — 各セクションの表テンプレート例