yodogawa 2.1.3 → 2.3.0

package/skills/c-002-update-documentation/SKILL.md

@@ -1,159 +1,159 @@
----
-name: c-002-update-documentation
-description: 実装完了後にタスクドキュメント（a-definition / b-research / c-implementation）とプロジェクトドキュメント（要件・ドメイン・API・データモデル等）を実装結果に合わせて更新する。実装完了後、ドキュメントと実コードの整合を取る際に使用。
-disable-model-invocation: true
-allowed-tools: Read, Write, Edit, Bash, Grep, Glob
-argument-hint: "[task-id]"
----
-
-# UpdateDocumentation (c-002)
-
-## 目的
-
-- 実装完了後にタスクレベルのドキュメント（a-definition.md, b-research.md, c-implementation.md）を実装内容に合わせて更新する。
-- プロジェクトレベルのドキュメント（要件・ドメイン・データモデル・API・画面設計等）を実装済み機能に合わせて更新する。
-- 計画時と実装時の差異を記録し、次のタスクへのフィードバックとする。
-- コードとドキュメントの一貫性を保ち、ドキュメント腐敗を防止する。
-
-## 前提
-
-- `/c-001-implement-task` で実装が完了していること
-- タスクディレクトリ `docs/tasks/task000001-{スラッグ}/` とタスクドキュメントが存在すること
-- 実装タスクリストの全ステップが完了していること
-- プロジェクトドキュメント構造（`docs/01-requirements/`, `docs/03-domain/`, `docs/04-design/` など）が存在すること
-
-## 手順
-
-`$ARGUMENTS` が指定されている場合は `task{ID}-{SLUG}`（例: `task000003-auth-login`）として使用する。未指定の場合はユーザーに対象タスクを確認する。
-
-### 1. 実装完了の確認
-
-**タスクID を確認**し、以下を検証：
-
-- [ ] `c-implementation.md` の全ステップが `[x]`
-- [ ] 全フェーズの受け入れ基準が満たされている
-- [ ] テストが全て通っている
-- [ ] PR/MR が作成されている（該当する場合）
-
-未完了なら「タスク {task-id} の実装がまだ完了していません。先に `/c-001-implement-task` を実行してください。」と案内する。
-
-### 2. 実装内容の確認
-
-**変更ファイルの特定**:
-
-```bash
-git diff main..HEAD --name-only
-git log --name-only --oneline main..HEAD
-```
-
-確認対象: 新規/変更/削除ファイル、依存関係（package.json 等）、マイグレーション、環境変数。
-
-**計画との差異**:
-
-- 計画通りに実装されたステップ / 変更/追加/スキップしたステップ
-- 技術スタック・アーキテクチャ・データモデル・API・画面遷移の変更点
-
-### 3. タスクドキュメントの更新
-
-#### 3.1. `a-definition.md`
-
-- 実装内容・受け入れ基準の更新
-- `## 実装時の技術的決定` セクションの追加（必要に応じて）
-- `## 実装結果` セクションの追加（実装日、実装者、ブランチ、PR/MR、テスト結果、デプロイ）
-
-記載例: [examples/task-doc-updates.md](examples/task-doc-updates.md)
-
-#### 3.2. `b-research.md`
-
-- 技術選定の更新（計画時と実際の差異、理由）
-- `## 実装時に発見したベストプラクティス` の追記
-- `## 技術的リスクの結果` の追記（計画時リスクの結果）
-
-#### 3.3. `c-implementation.md`
-
-- 全ステップのチェックボックスが `[x]` か確認
-- 各ステップに `**実装メモ**` を追記（必要に応じて）
-- 各フェーズに `**実装時間**` を記録
-- `## 振り返り` セクション（うまくいったこと／改善すべきこと／次のタスクへのフィードバック）を追加
-
-### 4. プロジェクトドキュメントの更新
-
-実装内容に応じて以下を更新（記載例は [examples/project-doc-updates.md](examples/project-doc-updates.md) を参照）：
-
-**要件** (`docs/01-requirements/`):
-
-- [ ] `02-features-implemented.md`: 実装済み機能リストに追加
-- [ ] `03-features-planned.md`: 計画中機能リストから削除
-- [ ] `05-user-stories.md`: ユーザーストーリーのステータス更新
-
-**ドメイン** (`docs/03-domain/`):
-
-- [ ] `01-domain-model.md`: エンティティ・値オブジェクトの追加
-- [ ] `02-ubiquitous-language.md`: 新しいドメイン用語の追加
-
-**設計** (`docs/04-design/`):
-
-- [ ] `03-screen-design.md`: 新しい画面・UI コンポーネント
-- [ ] `04-data-model.md`: 新しいテーブル・カラム
-- [ ] `05-api-spec.md`: 新しい API エンドポイント
-- [ ] `06-architecture.md`: アーキテクチャ変更
-
-**その他**:
-
-- [ ] `README.md`: セットアップ手順、機能一覧、API ドキュメントリンク
-- [ ] `CHANGELOG.md`: 変更履歴
-- [ ] `.env.example`: 新しい環境変数
-
-### 5. ドキュメント整合性の検証
-
-- クロスリファレンス確認（要件 ↔ ドメイン ↔ データモデル ↔ API ↔ 実装）
-- 用語の一貫性確認（ubiquitous-language.md との整合）
-- リンク切れの確認
-
-詳細なチェック項目は [reference/doc-structure-and-checks.md](reference/doc-structure-and-checks.md) を参照。
-
-### 6. Git コミット
-
-```bash
-git status
-git diff docs/
-git add docs/tasks/task{id}-{スラッグ}/ docs/01-requirements/ docs/03-domain/ docs/04-design/
-git add README.md CHANGELOG.md .env.example
-```
-
-コミットメッセージのテンプレートは [reference/doc-structure-and-checks.md](reference/doc-structure-and-checks.md#コミットメッセージのテンプレート) を参照。
-
-### 7. PR への反映とレビュー依頼
-
-- 既存 PR の場合: `git push origin task/{task-id}-{スラッグ}`
-- 未作成の場合: `gh pr create` で作成
-- レビュー観点（正確性・完全性・明確性・一貫性・最新性）は [reference/doc-structure-and-checks.md](reference/doc-structure-and-checks.md#ドキュメント品質のレビュー観点) を参照
-
-### 8. 次のタスクへのフィードバック
-
-- `c-implementation.md` の振り返りから共通化候補を特定
-- ベストプラクティスを次タスクのリサーチ入力として記録
-- 必要に応じてタスクテンプレート (`templates/tasks/task-template/`) を改善
-
-## 完了条件
-
-- [ ] 実装完了が確認されている
-- [ ] タスクドキュメントが更新されている（a-definition / b-research / c-implementation）
-- [ ] プロジェクトドキュメントが更新されている（要件・ドメイン・設計・README・CHANGELOG・.env.example）
-- [ ] ドキュメント間の整合性が確認されている
-- [ ] ドキュメント更新がコミットされている
-- [ ] 次のタスクへのフィードバックが記録されている
-
-## エスカレーション
-
-- **実装未完了**: 「タスクの実装がまだ完了していません。先に `/c-001-implement-task` を実行してください。」
-- **計画との差異が大きい**: 差異の理由と影響範囲を明確化し、関係者に共有。必要ならアーキテクチャレビューを実施。
-- **ドキュメント更新が複雑**: 段階的更新を推奨（タスクドキュメント → プロジェクトドキュメント、重要度順）。
-- **用語の不一致**: `ubiquitous-language.md` で用語を統一し、既存ドキュメントを一括修正。
-- **コードとドキュメントの乖離**: どちらが正しいかを確認し、コードまたはドキュメントを修正。
-
-## 参考
-
-- [examples/task-doc-updates.md](examples/task-doc-updates.md) — a-definition/b-research/c-implementation への追記サンプル
-- [examples/project-doc-updates.md](examples/project-doc-updates.md) — features/domain/data/api/screen/README/CHANGELOG/env の更新サンプル
-- [reference/doc-structure-and-checks.md](reference/doc-structure-and-checks.md) — 整合性チェック項目、ベストプラクティス、ドキュメント構造、コミットテンプレート
+---
+name: c-002-update-documentation
+description: 実装完了後にタスクドキュメント（a-definition / b-research / c-implementation）とプロジェクトドキュメント（要件・ドメイン・API・データモデル等）を実装結果に合わせて更新する。実装完了後、ドキュメントと実コードの整合を取る際に使用。
+disable-model-invocation: true
+allowed-tools: Read, Write, Edit, Bash, Grep, Glob
+argument-hint: "[task-id]"
+---
+
+# UpdateDocumentation (c-002)
+
+## 目的
+
+- 実装完了後にタスクレベルのドキュメント（a-definition.md, b-research.md, c-implementation.md）を実装内容に合わせて更新する。
+- プロジェクトレベルのドキュメント（要件・ドメイン・データモデル・API・画面設計等）を実装済み機能に合わせて更新する。
+- 計画時と実装時の差異を記録し、次のタスクへのフィードバックとする。
+- コードとドキュメントの一貫性を保ち、ドキュメント腐敗を防止する。
+
+## 前提
+
+- `/c-001-implement-task` で実装が完了していること
+- タスクディレクトリ `docs/tasks/task000001-{スラッグ}/` とタスクドキュメントが存在すること
+- 実装タスクリストの全ステップが完了していること
+- プロジェクトドキュメント構造（`docs/01-requirements/`, `docs/03-domain/`, `docs/04-design/` など）が存在すること
+
+## 手順
+
+`$ARGUMENTS` が指定されている場合は `task{ID}-{SLUG}`（例: `task000003-auth-login`）として使用する。未指定の場合はユーザーに対象タスクを確認する。
+
+### 1. 実装完了の確認
+
+**タスクID を確認**し、以下を検証：
+
+- [ ] `c-implementation.md` の全ステップが `[x]`
+- [ ] 全フェーズの受け入れ基準が満たされている
+- [ ] テストが全て通っている
+- [ ] PR/MR が作成されている（該当する場合）
+
+未完了なら「タスク {task-id} の実装がまだ完了していません。先に `/c-001-implement-task` を実行してください。」と案内する。
+
+### 2. 実装内容の確認
+
+**変更ファイルの特定**:
+
+```bash
+git diff main..HEAD --name-only
+git log --name-only --oneline main..HEAD
+```
+
+確認対象: 新規/変更/削除ファイル、依存関係（package.json 等）、マイグレーション、環境変数。
+
+**計画との差異**:
+
+- 計画通りに実装されたステップ / 変更/追加/スキップしたステップ
+- 技術スタック・アーキテクチャ・データモデル・API・画面遷移の変更点
+
+### 3. タスクドキュメントの更新
+
+#### 3.1. `a-definition.md`
+
+- 実装内容・受け入れ基準の更新
+- `## 実装時の技術的決定` セクションの追加（必要に応じて）
+- `## 実装結果` セクションの追加（実装日、実装者、ブランチ、PR/MR、テスト結果、デプロイ）
+
+記載例: [examples/task-doc-updates.md](examples/task-doc-updates.md)
+
+#### 3.2. `b-research.md`
+
+- 技術選定の更新（計画時と実際の差異、理由）
+- `## 実装時に発見したベストプラクティス` の追記
+- `## 技術的リスクの結果` の追記（計画時リスクの結果）
+
+#### 3.3. `c-implementation.md`
+
+- 全ステップのチェックボックスが `[x]` か確認
+- 各ステップに `**実装メモ**` を追記（必要に応じて）
+- 各フェーズに `**実装時間**` を記録
+- `## 振り返り` セクション（うまくいったこと／改善すべきこと／次のタスクへのフィードバック）を追加
+
+### 4. プロジェクトドキュメントの更新
+
+実装内容に応じて以下を更新（記載例は [examples/project-doc-updates.md](examples/project-doc-updates.md) を参照）：
+
+**要件** (`docs/01-requirements/`):
+
+- [ ] `06-features-implemented.md`: 実装済み機能リストに追加（existing モードのみ）
+- [ ] `03-parking-lot.md`: 実装した（または不要判断した）アイデアを backlog から削除
+- [ ] `05-user-stories.md`: ユーザーストーリーのステータス更新
+
+**ドメイン** (`docs/03-domain/`):
+
+- [ ] `01-domain-sketch.md`: 中核エンティティ・重要ルールの更新（Full DDD 採用時は `01-domain-model.md`）
+- [ ] `02-ubiquitous-language.md`: 新しいドメイン用語の追加
+
+**設計** (`docs/04-design/`):
+
+- [ ] `03-screen-design.md`: 新しい画面・UI コンポーネント
+- [ ] `04-data-model.md`: 新しいテーブル・カラム
+- [ ] `05-api-spec.md`: 新しい API エンドポイント
+- [ ] `06-architecture.md`: アーキテクチャ変更
+
+**その他**:
+
+- [ ] `README.md`: セットアップ手順、機能一覧、API ドキュメントリンク
+- [ ] `CHANGELOG.md`: 変更履歴
+- [ ] `.env.example`: 新しい環境変数
+
+### 5. ドキュメント整合性の検証
+
+- クロスリファレンス確認（要件 ↔ ドメイン ↔ データモデル ↔ API ↔ 実装）
+- 用語の一貫性確認（ubiquitous-language.md との整合）
+- リンク切れの確認
+
+詳細なチェック項目は [reference/doc-structure-and-checks.md](reference/doc-structure-and-checks.md) を参照。
+
+### 6. Git コミット
+
+```bash
+git status
+git diff docs/
+git add docs/tasks/task{id}-{スラッグ}/ docs/01-requirements/ docs/03-domain/ docs/04-design/
+git add README.md CHANGELOG.md .env.example
+```
+
+コミットメッセージのテンプレートは [reference/doc-structure-and-checks.md](reference/doc-structure-and-checks.md#コミットメッセージのテンプレート) を参照。
+
+### 7. PR への反映とレビュー依頼
+
+- 既存 PR の場合: `git push origin task/{task-id}-{スラッグ}`
+- 未作成の場合: `gh pr create` で作成
+- レビュー観点（正確性・完全性・明確性・一貫性・最新性）は [reference/doc-structure-and-checks.md](reference/doc-structure-and-checks.md#ドキュメント品質のレビュー観点) を参照
+
+### 8. 次のタスクへのフィードバック
+
+- `c-implementation.md` の振り返りから共通化候補を特定
+- ベストプラクティスを次タスクのリサーチ入力として記録
+- 必要に応じてタスクテンプレート (`templates/tasks/task-template/`) を改善
+
+## 完了条件
+
+- [ ] 実装完了が確認されている
+- [ ] タスクドキュメントが更新されている（a-definition / b-research / c-implementation）
+- [ ] プロジェクトドキュメントが更新されている（要件・ドメイン・設計・README・CHANGELOG・.env.example）
+- [ ] ドキュメント間の整合性が確認されている
+- [ ] ドキュメント更新がコミットされている
+- [ ] 次のタスクへのフィードバックが記録されている
+
+## エスカレーション
+
+- **実装未完了**: 「タスクの実装がまだ完了していません。先に `/c-001-implement-task` を実行してください。」
+- **計画との差異が大きい**: 差異の理由と影響範囲を明確化し、関係者に共有。必要ならアーキテクチャレビューを実施。
+- **ドキュメント更新が複雑**: 段階的更新を推奨（タスクドキュメント → プロジェクトドキュメント、重要度順）。
+- **用語の不一致**: `ubiquitous-language.md` で用語を統一し、既存ドキュメントを一括修正。
+- **コードとドキュメントの乖離**: どちらが正しいかを確認し、コードまたはドキュメントを修正。
+
+## 参考
+
+- [examples/task-doc-updates.md](examples/task-doc-updates.md) — a-definition/b-research/c-implementation への追記サンプル
+- [examples/project-doc-updates.md](examples/project-doc-updates.md) — features/domain/data/api/screen/README/CHANGELOG/env の更新サンプル
+- [reference/doc-structure-and-checks.md](reference/doc-structure-and-checks.md) — 整合性チェック項目、ベストプラクティス、ドキュメント構造、コミットテンプレート

package/skills/c-002-update-documentation/examples/project-doc-updates.md

@@ -2,7 +2,7 @@
 
 SKILL.md 手順4で使うテンプレート。要件・ドメイン・設計・README など各ドキュメントに追記するサンプル。
 
-## features-implemented.md
+## 06-features-implemented.md
 
 ```markdown
 ## ユーザー認証・認可
@@ -27,10 +27,10 @@ SKILL.md 手順4で使うテンプレート。要件・ドメイン・設計・R
 **PR/MR**: #123
 ```
 
-## features-planned.md
+## 03-parking-lot.md
 
-- 実装完了した機能をリストから削除
-- または、ステータスを「実装済み」に変更し `02-features-implemented.md` への参照を追加
+- 実装完了した（または不要判断した）アイデアを backlog から削除
+- または、ステータスを「実装済み」に変更し `06-features-implemented.md` への参照を追加
 
 ## domain-model.md
 

package/skills/c-002-update-documentation/reference/doc-structure-and-checks.md

@@ -1,97 +1,99 @@
-# ドキュメント構造と整合性チェック
-
-SKILL.md 手順5（整合性検証）とベストプラクティスで参照する詳細資料。
-
-## ドキュメント整合性の検証項目
-
-### クロスリファレンスの確認
-
-- [ ] **要件 ↔ ドメインモデル**: features-implemented.md の機能が domain-model.md に反映されているか
-- [ ] **ドメインモデル ↔ データモデル**: domain-model.md のエンティティが data-model.md のテーブルに対応しているか
-- [ ] **ドメインモデル ↔ API 仕様**: domain-model.md の振る舞いが api-spec.md のエンドポイントに対応しているか
-- [ ] **API 仕様 ↔ 実装**: api-spec.md のエンドポイントが実際に実装されているか
-- [ ] **データモデル ↔ 実装**: data-model.md のテーブル定義がマイグレーションファイルと一致しているか
-
-### 用語の一貫性確認
-
-- [ ] ドキュメント全体で同じ用語を使用しているか
-- [ ] ubiquitous-language.md に記載された用語が各ドキュメントで使用されているか
-- [ ] コード内のクラス名・変数名がドメイン用語と一致しているか
-
-### リンク切れの確認
-
-- [ ] 内部リンクが正しいパスを指しているか
-- [ ] 参照先のドキュメント・セクションが存在するか
-
-## ドキュメント品質のレビュー観点
-
-- [ ] **正確性**: 実装内容と一致しているか
-- [ ] **完全性**: すべての変更が記載されているか
-- [ ] **明確性**: 第三者が理解できる内容か
-- [ ] **一貫性**: ドキュメント間で用語・形式が統一されているか
-- [ ] **最新性**: 古い情報が削除されているか
-
-## ベストプラクティス
-
-- **実装直後に更新**: 記憶が新しいうちに記録する
-- **差異を記録**: 計画と実装の差異は必ず記録し、次のタスクへのフィードバックとする
-- **スクリーンショット活用**: UI 変更の場合、スクリーンショットを添付して視覚的に記録
-- **リンクを活用**: ドキュメント間でリンクを張り、関連情報にすぐアクセスできるようにする
-- **バージョン管理**: ドキュメントもコードと同様に Git で管理
-- **段階的更新**: 大規模な更新は段階的に行い、一度に全てを更新しない
-- **レビューを受ける**: 重要な更新はチームレビューで正確性を担保
-- **テンプレート活用**: 繰り返し更新するドキュメントはテンプレート化
-- **自動化**: 可能な部分は自動化（API ドキュメント生成、データモデル図生成など）
-- **定期的な棚卸し**: ドキュメント全体を定期的にレビューし古い情報を削除
-
-## ドキュメント構造の参考
-
-### タスクレベル（`docs/tasks/task{id}-{スラッグ}/`）
-
-- `a-definition.md`: タスク定義（目的、ユーザーストーリー、受け入れ基準）
-- `b-research.md`: リサーチ（ベストプラクティス、技術選定）
-- `c-implementation.md`: 実装タスクリスト（フェーズ、ステップ）
-
-### プロジェクトレベル（`docs/`）
-
-- `01-requirements/`: 要件定義
-  - `02-features-implemented.md`: 実装済み機能
-  - `03-features-planned.md`: 計画中機能
-  - `05-user-stories.md`: ユーザーストーリー
-- `03-domain/`: ドメイン
-  - `01-domain-model.md`: ドメインモデル
-  - `02-ubiquitous-language.md`: ユビキタス言語
-- `04-design/`: 設計
-  - `03-screen-design.md`: 画面設計
-  - `04-data-model.md`: データモデル
-  - `05-api-spec.md`: API 仕様
-  - `06-architecture.md`: アーキテクチャ
-
-### その他
-
-- `README.md`: プロジェクト概要、セットアップ手順
-- `CHANGELOG.md`: 変更履歴
-- `.env.example`: 環境変数テンプレート
-
-## 自動化のヒント
-
-将来的に、コミットログからの変更抽出やコードからの API 仕様生成などで、ドキュメント更新を一部自動化することを検討。
-
-## コミットメッセージのテンプレート
-
-```
-docs(task-{task-id}): update documentation for {機能名}
-
-Task-level documentation:
-- Update a-definition.md with implementation results
-- Update b-research.md with discovered best practices
-- Update c-implementation.md with implementation notes and retrospective
-
-Project-level documentation:
-- Add {機能名} to features-implemented.md
-- Update domain-model.md / data-model.md / api-spec.md
-- Update README.md with setup instructions
-- Add changelog entry
-
-Related: task{task-id}-{スラッグ}
-```
+# ドキュメント構造と整合性チェック
+
+SKILL.md 手順5（整合性検証）とベストプラクティスで参照する詳細資料。
+
+## ドキュメント整合性の検証項目
+
+### クロスリファレンスの確認
+
+- [ ] **要件 ↔ ドメインモデル**: 06-features-implemented.md の機能が domain-model.md に反映されているか
+- [ ] **ドメインモデル ↔ データモデル**: domain-model.md のエンティティが data-model.md のテーブルに対応しているか
+- [ ] **ドメインモデル ↔ API 仕様**: domain-model.md の振る舞いが api-spec.md のエンドポイントに対応しているか
+- [ ] **API 仕様 ↔ 実装**: api-spec.md のエンドポイントが実際に実装されているか
+- [ ] **データモデル ↔ 実装**: data-model.md のテーブル定義がマイグレーションファイルと一致しているか
+
+### 用語の一貫性確認
+
+- [ ] ドキュメント全体で同じ用語を使用しているか
+- [ ] ubiquitous-language.md に記載された用語が各ドキュメントで使用されているか
+- [ ] コード内のクラス名・変数名がドメイン用語と一致しているか
+
+### リンク切れの確認
+
+- [ ] 内部リンクが正しいパスを指しているか
+- [ ] 参照先のドキュメント・セクションが存在するか
+
+## ドキュメント品質のレビュー観点
+
+- [ ] **正確性**: 実装内容と一致しているか
+- [ ] **完全性**: すべての変更が記載されているか
+- [ ] **明確性**: 第三者が理解できる内容か
+- [ ] **一貫性**: ドキュメント間で用語・形式が統一されているか
+- [ ] **最新性**: 古い情報が削除されているか
+
+## ベストプラクティス
+
+- **実装直後に更新**: 記憶が新しいうちに記録する
+- **差異を記録**: 計画と実装の差異は必ず記録し、次のタスクへのフィードバックとする
+- **スクリーンショット活用**: UI 変更の場合、スクリーンショットを添付して視覚的に記録
+- **リンクを活用**: ドキュメント間でリンクを張り、関連情報にすぐアクセスできるようにする
+- **バージョン管理**: ドキュメントもコードと同様に Git で管理
+- **段階的更新**: 大規模な更新は段階的に行い、一度に全てを更新しない
+- **レビューを受ける**: 重要な更新はチームレビューで正確性を担保
+- **テンプレート活用**: 繰り返し更新するドキュメントはテンプレート化
+- **自動化**: 可能な部分は自動化（API ドキュメント生成、データモデル図生成など）
+- **定期的な棚卸し**: ドキュメント全体を定期的にレビューし古い情報を削除
+
+## ドキュメント構造の参考
+
+### タスクレベル（`docs/tasks/task{id}-{スラッグ}/`）
+
+- `a-definition.md`: タスク定義（目的、ユーザーストーリー、受け入れ基準）
+- `b-research.md`: リサーチ（ベストプラクティス、技術選定）
+- `c-implementation.md`: 実装タスクリスト（フェーズ、ステップ）
+
+### プロジェクトレベル（`docs/`）
+
+- `01-requirements/`: 要件定義
+  - `01-product-brief.md`: Product Brief
+  - `02-mvp-scope.md`: MVP スコープ（Must / Not Now / Won't）
+  - `03-parking-lot.md`: アイデア backlog
+  - `05-user-stories.md`: ユーザーストーリー
+  - `06-features-implemented.md`: 実装済み機能（existing モード）
+- `03-domain/`: ドメイン
+  - `01-domain-sketch.md`: ドメイン（Full DDD 採用時は `01-domain-model.md`）
+  - `02-ubiquitous-language.md`: ユビキタス言語
+- `04-design/`: 設計
+  - `03-screen-design.md`: 画面設計
+  - `04-data-model.md`: データモデル
+  - `05-api-spec.md`: API 仕様
+  - `06-architecture.md`: アーキテクチャ
+
+### その他
+
+- `README.md`: プロジェクト概要、セットアップ手順
+- `CHANGELOG.md`: 変更履歴
+- `.env.example`: 環境変数テンプレート
+
+## 自動化のヒント
+
+将来的に、コミットログからの変更抽出やコードからの API 仕様生成などで、ドキュメント更新を一部自動化することを検討。
+
+## コミットメッセージのテンプレート
+
+```
+docs(task-{task-id}): update documentation for {機能名}
+
+Task-level documentation:
+- Update a-definition.md with implementation results
+- Update b-research.md with discovered best practices
+- Update c-implementation.md with implementation notes and retrospective
+
+Project-level documentation:
+- Add {機能名} to 06-features-implemented.md
+- Update domain-model.md / data-model.md / api-spec.md
+- Update README.md with setup instructions
+- Add changelog entry
+
+Related: task{task-id}-{スラッグ}
+```

package/skills/d-001-review-retrospective/SKILL.md

@@ -0,0 +1,93 @@
+---
+name: d-001-review-retrospective
+description: A〜Cシリーズ（または1タスク分のb/cサイクル）完了後、成果物ドキュメント（振り返り・ベストプラクティス・レビューレポート）から摩擦点を収集し、対象SKILL.mdへの修正案をdiff形式で提示、docs/LESSONS.mdに汎用的な学びを記録する。A〜Cシリーズ完了後の振り返りタイミングで使用。
+disable-model-invocation: true
+argument-hint: "[task-id ...]"
+context: fork
+allowed-tools: Read, Grep, Glob, Write, Bash
+---
+
+# ReviewRetrospective (d-001)
+
+## 目的
+
+- A〜Cシリーズ（または1タスク分のb/cサイクル）の実行経験から摩擦点（詰まった・脱線した・手戻りした箇所）を成果物ドキュメントから収集する。
+- 摩擦点をスキル・手順単位にマッピングし、対象 SKILL.md への具体的な修正案を diff 形式で提示する（適用はユーザー承認制。SKILL.md自体は編集しない）。
+- 汎用的な学びを `docs/LESSONS.md` に追記し、次のタスクのリサーチ（`b-003`）が参照できるようにする。
+
+## 前提
+
+- 対象タスクの成果物ドキュメント（`a-definition.md` / `b-research.md` / `c-implementation.md`）が `docs/tasks/task{ID}-{SLUG}/` に存在すること。特に `c-implementation.md` の `## 振り返り` セクションが記入済みであること。
+- `b-005-review-task` を実施済みなら `docs/tasks/task{ID}-{SLUG}/TASK-REVIEW-REPORT.md` も入力として使う（無ければスキップ）。
+- 修正案の永続化先: `docs/tasks/task{ID}-{SLUG}/RETROSPECTIVE-REPORT.md`
+- 汎用的な学びの蓄積先: `docs/LESSONS.md`（無ければこのスキルが `../../templates/LESSONS.md` から新規作成——スキル配置ディレクトリ起点の相対参照）
+- **注記**: `docs/LESSONS.md` は意図的に `docs/project/` の外に置く。`yodogawa doctor` の `id-trace`/`placeholder` は `docs/project/` 配下を無条件に走査し、`US-`/`FN-` 等のID風文字列を trace 切れとして誤検知しうるため（過去タスクで言及したIDが後日リナンバー・削除されると発生する）。
+
+## 手順
+
+`$ARGUMENTS` に1つ以上の `task{ID}-{SLUG}` があればそれを対象にする。未指定ならユーザーに対象範囲（直近のA〜Cシリーズ全体 or 特定タスク群）を確認する。
+
+### 1. 対象タスクの成果物収集
+
+対象タスクごとに:
+
+```bash
+ls -d docs/tasks/task*
+```
+
+- `c-implementation.md` の `## 振り返り` セクション（うまくいったこと／改善すべきこと／次のタスクへのフィードバック）を Read。
+- `b-research.md` の `## 実装時に発見したベストプラクティス` `## 技術的リスクの結果` を Read。
+- `TASK-REVIEW-REPORT.md` があれば `## 所見` の改善点・推奨事項を Read。
+
+未記入・未存在なら該当タスクをスキップし、理由を記録する。
+
+### 2. 摩擦点の抽出とスキル・手順へのマッピング
+
+収集した記述から摩擦点候補を洗い出し、原因となったスキル・手順を Read/Grep で特定する（例:「b-003の手順4で外部調査に時間がかかった」→ `skills/b-003-create-task-research/SKILL.md` の該当手順）。
+分類基準・マッピング方法の詳細は [reference/friction-point-mapping.md](reference/friction-point-mapping.md) を参照。
+
+### 3. 対象 SKILL.md への修正案の作成
+
+対象 SKILL.md を Read し、摩擦点を解消する具体的な修正案を diff 形式（`-`/`+` 行）で作成する。**SKILL.mdファイル自体は編集しない**（Writeツールはこの手順では使わない。適用要否はユーザーが判断する）。
+
+### 4. レポート作成
+
+`docs/tasks/task{ID}-{SLUG}/RETROSPECTIVE-REPORT.md` に摩擦点一覧・SKILL.md修正案（diff）を記入する（詳細版テンプレートは [examples/retrospective-report-template.md](examples/retrospective-report-template.md) を参照）。複数タスクを対象にした場合は1レポートに集約する。
+
+### 5. LESSONS.md への記録
+
+個別スキルへの修正提案にとどまらない汎用的な学び（複数スキルに共通するパターン、プロジェクト固有の注意点等）を抽出する。
+`docs/LESSONS.md` を Read し、同一 task-id の見出し（`### YYYY-MM-DD — task{ID}: ...`）が既に無いか Grep で確認する。既にあればスキップして重複を報告する。無ければ末尾に新規エントリを追記する（Write）。
+
+### 6. レポート出力
+
+チャットに以下を出力する:
+
+- 摩擦点一覧（タスクID・該当スキル・根拠file:line）
+- 対象SKILL.mdごとの修正案（diff形式。手順4で保存したレポートへのパスも明記）
+- LESSONS.mdへの追記内容のサマリ（スキップした場合はその旨）
+
+### 7. Git への追加（任意）
+
+```bash
+git add docs/tasks/task{ID}-{SLUG}/RETROSPECTIVE-REPORT.md docs/LESSONS.md
+git commit -m "docs(retrospective): 振り返りレポート作成 task{ID}"
+```
+
+## 完了条件
+
+- 対象タスクの成果物ドキュメントを全て読み込んでいる（未記入タスクはスキップ理由を記録）。
+- 摩擦点ごとに file:line の根拠付きで SKILL.md 修正案（diff形式）が提示されている（チャット＋`RETROSPECTIVE-REPORT.md`）。
+- `docs/LESSONS.md` への追記が完了している（新規作成含む。重複時はスキップ）。
+- **SKILL.md自体は書き換えられていない**（提示のみ）。
+
+## エスカレーション
+
+- **成果物ドキュメントが不十分**: 「振り返りセクションが記入されていません。`c-002-update-documentation` で振り返りを記入してから再実行してください。」
+- **摩擦点が見つからない**: 「今回の対象タスクでは明確な摩擦点が見つかりませんでした。」と報告して終了する（無理に指摘を作らない）。
+- **修正案が複数スキルにまたがる／大規模**: 優先度（頻度・影響度）を付けて提示し、一度に大量の変更を提案しない。
+
+## 参考
+
+- [reference/friction-point-mapping.md](reference/friction-point-mapping.md) — 摩擦点の分類基準・スキル手順へのマッピング方法
+- [examples/retrospective-report-template.md](examples/retrospective-report-template.md) — RETROSPECTIVE-REPORT.md詳細テンプレート