@careerchain/stdd 0.1.0

package/assets/.claude/skills/documenting-plans/SKILL.md

@@ -0,0 +1,217 @@
+---
+name: documenting-plans
+description: |-
+  PLAN ドキュメント（実装タスクリスト）の作成・管理ガイドライン。STDD 方法論において、セッションごとの実装計画を管理する。
+when_to_use: |-
+  「PLAN」「タスクリスト」「実装計画」「セッション計画」「実装開始」「STDD実装」「機能実装」に関する作業のとき。
+allowed-tools: Read, Write, Edit, Glob, Grep
+---
+
+# PLAN ドキュメントの作成・管理
+
+STDD（Spec and Test Driven Development）方法論において、セッションごとの実装タスクを管理するPLANドキュメントを作成・管理します。
+
+## Quick Start
+
+### PLANドキュメントとは
+
+**当該セッションで行う実装のタスクを、実装可能な単位に分解したタスクリスト**
+
+Claudeは実際の作業をこのタスクリストに従って進めます。
+
+### 目的
+
+**SSoT（Single Source of Truth）としてのSpecドキュメントと、フローのドキュメントを明確に分けるため**
+
+- Specドキュメント: 要件・仕様のSSoT（常に最新の状態を維持）
+- PLANドキュメント: 当該セッションの作業計画
+
+### テンプレート
+
+詳細なテンプレートは [templates/plan.md](./templates/plan.md) を参照。
+
+## ドキュメント配置ルール
+
+```
+docs/<app>/<feature-path>/plans/[yyyy-mm-dd].md
+```
+
+**例**:
+
+```
+docs/<app.id>/projects/project-list/plans/2026-01-30.md
+docs/<app.id>/profile/skills/plans/2026-01-30.md
+```
+
+## 作成タイミング
+
+### 新規機能を実装する場合（Specドキュメントを新規作成する場合）
+
+```
+1. REQUIREMENTS.md作成
+   ↓
+2. TECH_DESIGN.md作成
+   ↓
+3. ステークホルダー/アーキテクトレビュー
+   ↓
+4. ★ PLANドキュメント作成
+   - タスクはテスト・実装のみになる
+   ↓
+5. テスト作成 → 実装
+   ↓
+6. レビュー
+```
+
+### 既存機能に追加実装する場合（Specドキュメントが既に存在する場合）
+
+```
+1. ★ PLANドキュメント作成
+   - タスクの一つとしてSpecドキュメントの更新が含まれる
+   ↓
+2. Specドキュメント更新（REQUIREMENTS.md、TECH_DESIGN.md）
+   ↓
+3. テスト・実装計画の更新に基づいてPLANドキュメントも更新
+   ↓
+4. テスト作成 → 実装
+   ↓
+5. レビュー
+```
+
+## PLANドキュメントの構成
+
+PLANドキュメントには以下のセクションを含める:
+
+### 1. 実装スコープ
+
+- REQUIREMENTS.md / TECH_DESIGN.md のどの範囲を実装するか
+- P0/P1/P2 のどれを対象とするか
+
+### 2. タスクリスト
+
+テスト作成 → 実装の順序でタスクを分解:
+
+1. **Specドキュメント更新**（既存機能の場合）
+2. **テスト作成（Red状態）**: Unit → Integration → E2E
+3. **実装（Green状態）**: テストに対応する実装
+4. **テスト実行・検証**
+
+### 3. ファイル構成
+
+**目的**: 今回のセッションで作成・変更するファイルの一覧を明確にする
+
+**凡例**:
+
+- `（新規）`: 新規作成するファイル
+- `（既存修正）`: 既存ファイルを修正
+- `（既存維持）`: 変更なし（参照のみ）
+
+### 4. 実装詳細
+
+各ファイルの実装方針を簡潔に記載:
+
+- ページコンポーネント: サーバー/クライアントコンポーネントの選択理由
+- Server Actions: 処理フローの概要
+- バリデーション: 主要なバリデーションルール
+- Domain層: Entity/Repository/Serviceの役割分担
+
+**注意**: コード例は記載しない。詳細は実装ファイル自体を参照。
+
+### 5. 実装時の注意事項
+
+セッション中に把握した技術的な注意点を記録:
+
+- 認証・セッションの制約
+- エラーハンドリングの方針
+- 外部サービスとの連携方法
+
+**注意**: コード例は記載しない。詳細は実装ファイル自体を参照。
+
+### 6. 備考
+
+- セッション中に発生した課題や決定事項
+- 次回セッションへの引き継ぎ事項
+
+### 7. 既知の制限事項
+
+- 現時点での制限
+- スコープ外の項目（REQUIREMENTS.mdの「Out of Scope」と連携）
+
+## セッション開始時の確認事項
+
+**STDDにおいて、Claudeは毎セッションでPLANドキュメント作成前に以下を開発者に確認すること**:
+
+### 1. 実装スコープの確認
+
+- Specのうち一部を実装するのか、全部を実装するのか
+- 一部の場合、どの部分を今セッションで実装するのか
+
+### 2. 確認の例
+
+```
+「REQUIREMENTS.mdを確認しました。今回のセッションでは以下のどの範囲を実装しますか？
+
+A) 全てのUser Journey（P0〜P2）
+B) P0のCritical Pathsのみ
+C) 特定のJourneyのみ（指定してください）
+
+また、既存のPLANドキュメントがある場合は、そちらを継続しますか？」
+```
+
+### 3. この確認が必要な理由
+
+- 大きな機能は複数セッションに分割して実装することが多い
+- スコープを明確にすることで、PLANドキュメントの精度が上がる
+- 開発者との認識齟齬を防ぐ
+
+## タスク分解の原則
+
+**最初のタスク**: Test Strategyに従ってテストを作成（Red状態）
+
+テスト作成の順序:
+
+1. **Unit testが必要** → Unit testを作成
+2. **Integration testが必要** → Integration testを作成
+3. **E2E testが必要** → E2E testを作成
+
+実装の順序:
+
+4. **Unit testに対応する実装**を作成
+5. **Integration testに対応する実装**を作成
+6. **E2E testに対応する実装**を作成
+
+## チェックリスト
+
+### PLANドキュメント作成時
+
+```
+□ 開発者に実装スコープを確認した
+□ REQUIREMENTS.md と TECH_DESIGN.md を確認した
+□ 実装スコープを明記した
+□ ファイル構成を記載した（新規/既存修正/既存維持を区別）
+□ テスト作成タスクを優先的に配置した（Unit → Integration → E2E）
+□ 実装タスクを具体的に記載した
+```
+
+### セッション終了時
+
+```
+□ 完了したタスクにチェックを入れた
+□ 実装時の注意事項を記載した
+□ 未完了タスクがある場合、次回セッションへの引き継ぎ事項を備考に記載した
+□ 発生した課題や決定事項を備考に記載した
+□ 既知の制限事項を記載した（必要な場合）
+```
+
+## When NOT to Use This Skill
+
+以下の場合はこのスキルを使用しない:
+
+- **単純なバグ修正**: タスク分解が不要な場合
+- **ドキュメント修正のみ**: 実装を伴わない場合
+- **即時対応が必要な緊急修正**: 計画よりも実行を優先する場合
+
+## 参照ファイル
+
+- [PLANドキュメントテンプレート](./templates/plan.md)
+- [STDD開発ガイド](../../docs/spec-driven-development-guide.md)
+- [Specドキュメント作成スキル](../documenting-specifications/SKILL.md)

package/assets/.claude/skills/documenting-plans/templates/plan.md

@@ -0,0 +1,182 @@
+# PLANドキュメント テンプレート
+
+**目的**: セッションごとの実装タスクを管理し、作業計画を明確化する
+
+**配置**: `docs/<app>/<feature-path>/plans/[yyyy-mm-dd].md`
+
+## テンプレート構造
+
+```markdown
+# PLAN: [機能名] - [日付]
+
+## 実装スコープ
+
+**対象**: REQUIREMENTS.md / TECH_DESIGN.md のどの範囲を実装するか
+
+- [ ] P0: Critical Paths（全て / 一部を指定）
+- [ ] P1: Important（全て / 一部を指定）
+- [ ] P2: Nice to Have（全て / 一部を指定）
+
+**除外**: 今回のセッションでは実装しないもの
+
+---
+
+## タスクリスト
+
+### 1. Specドキュメント更新（既存機能の場合）
+
+- [ ] REQUIREMENTS.md の更新
+- [ ] TECH_DESIGN.md の更新
+
+### 2. テスト作成（Red状態）
+
+**Unit Test**:
+- [ ] `lib/validation/<schema>/index.test.ts` - バリデーションテスト（N件）
+
+**Integration Test**:
+- [ ] `components/<feature>/<Component>/index.test.tsx` - コンポーネントテスト（N件）
+
+**E2E Test（P0のみ）**:
+- [ ] `e2e/tests/<app>/<feature>.spec.ts` - E2Eテスト（N件）
+
+### 3. 実装（Green状態）
+
+**Unit testに対応する実装**:
+- [ ] `lib/validation/<schema>/index.ts` - バリデーションスキーマ
+
+**Integration testに対応する実装**:
+- [ ] `actions/<feature>-actions/index.ts` - Server Actions
+- [ ] `components/<feature>/<Component>/index.tsx` - コンポーネント
+
+**E2E testに対応する実装**:
+- [ ] `app/<feature>/page.tsx` - ページ
+
+### 4. テスト実行・検証
+
+- [ ] Unit test 通過確認
+- [ ] Integration test 通過確認
+- [ ] E2E test 通過確認
+- [ ] `commands.typecheck`（`.stdd.config.yml`）型チェック通過
+
+---
+
+## ファイル構成
+
+今回のセッションで作成・変更するファイルの一覧。
+
+```
+<app>/
+├── app/
+│   └── <feature>/
+│       └── page.tsx                    # ページコンポーネント（新規/既存修正）
+├── components/
+│   └── <feature>/
+│       ├── <Component>/
+│       │   ├── index.tsx               # コンポーネント（新規/既存修正）
+│       │   └── index.test.tsx          # Integration test
+├── lib/
+│   └── validation/
+│       └── <schema>/
+│           ├── index.ts                # Zodバリデーションスキーマ
+│           └── index.test.ts           # Unit test
+├── actions/
+│   └── <feature>-actions/
+│       ├── index.ts                    # Server Actions
+│       └── index.test.ts               # Server Actions テスト
+└── domain/
+    ├── models/
+    │   └── <entity>.ts                 # Entity定義
+    ├── repository/
+    │   └── <entity>.ts                 # Repository
+    └── services/
+        └── <entity>Service.ts          # Service
+```
+
+**凡例**:
+- `（新規）`: 新規作成するファイル
+- `（既存修正）`: 既存ファイルを修正
+- `（既存維持）`: 変更なし（参照のみ）
+
+### 実装詳細
+
+各ファイルの実装詳細を記載。
+
+- **ページコンポーネント**: サーバーコンポーネント/クライアントコンポーネントの選択理由
+- **Server Actions**: 処理フローの概要
+- **バリデーション**: 主要なバリデーションルール
+- **Domain層**: Entity/Repository/Serviceの役割分担
+
+---
+
+## 実装時の注意事項
+
+セッション中に把握した実装上の注意点を記録。
+
+### 認証・セッション
+
+- （例）`/set-password`ページはSupabase認証後のリダイレクト時のみ機能
+- （例）セッションはリロードやブラウザ再起動後には維持されない
+
+### エラーハンドリング
+
+- （例）エラー表示: 「認証エラー」タイトルと具体的なメッセージ
+- （例）ユーザー対応: フローを最初からやり直す導線を提供
+
+### 外部サービス連携
+
+- （例）Resendを使用したメール送信
+- （例）Supabase Authのトークン検証フロー
+
+---
+
+## 備考
+
+セッション中に発生した課題や決定事項を記録。
+
+- （例）XXの実装方針についてYYに変更
+- （例）次回セッションへの引き継ぎ事項
+
+---
+
+## 既知の制限事項
+
+現時点での制限や、Out of Scopeの項目。
+
+- （例）パスワードリセット: 未実装（Out of Scope）
+- （例）セッション無効化: JWT戦略のため即座の無効化が不可（最大24時間）
+```
+
+## 重要なポイント
+
+### ファイル構成セクションについて
+
+**目的**: TECH_DESIGN.mdの「Implementation Notes」に記載されていた内容をPLANドキュメントに移動
+
+- どのファイルを作成/変更するかを明確にする
+- 各ファイルの役割と対応するテストを明記
+- 凡例で「新規」「既存修正」「既存維持」を区別
+
+### 実装詳細セクションについて
+
+**目的**: 各ファイルの実装方針を簡潔に記載
+
+- コード例は記載しない
+- 処理フローの概要や設計判断のポイントを記載
+- 詳細は実装ファイル自体を参照
+
+### 実装時の注意事項セクションについて
+
+**目的**: 実装中に把握した技術的な注意点を記録
+
+- 認証・セッションの制約
+- エラーハンドリングの方針
+- 外部サービスとの連携方法
+
+**注意**: コード例は記載しない。コードの詳細は実装ファイル自体を参照。
+
+### 既知の制限事項セクションについて
+
+**目的**: 現時点での制限や、スコープ外の項目を明記
+
+- REQUIREMENTS.mdの「Out of Scope」と重複する場合は、REQUIREMENTS.mdを参照する形でも可
+- セッション中に発見された新たな制限は、ここに記録後、必要に応じてREQUIREMENTS.mdに反映

package/assets/.claude/skills/documenting-specifications/SKILL.md

@@ -0,0 +1,300 @@
+---
+name: documenting-specifications
+description: |-
+  REQUIREMENTS.md（ビジネス要件・ユーザージャーニー）と TECH_DESIGN.md（技術設計・テスト戦略）のテンプレートとガイドラインを提供する。STDD 方法論に従った仕様ドキュメントの作成・更新を支援する。
+when_to_use: |-
+  「spec」「仕様書」「設計書」「要件定義」「REQUIREMENTS.md」「TECH_DESIGN.md」「Spec and Test Driven Development」「STDD」「仕様駆動」に関する作業のとき。
+allowed-tools: Read, Write, Edit, Glob, Grep
+---
+
+# 仕様ドキュメント（REQUIREMENTS / TECH_DESIGN）の作成
+
+STDD（Spec and Test Driven Development）方法論に従って、REQUIREMENTS.md と TECH_DESIGN.md を作成・更新します。
+
+## Quick Start
+
+### 新機能の仕様書を作成する場合
+
+1. **REQUIREMENTS.md を作成**
+
+   ```
+   docs/<app>/<path>/REQUIREMENTS.md
+   ```
+
+   - ビジネス要件、ユーザージャーニー（P0/P1/P2 の優先度付き）を記述
+   - [テンプレート](templates/requirements.md) を参照
+
+2. **ワイヤーフレーム（WF）を生成**（UI を持つ機能の場合）
+
+   ```
+   docs/<app>/<path>/wireframes/
+   ```
+
+   - REQUIREMENTS.md のジャーニーから HTML ワイヤーフレームを生成（低忠実度・主要文言は実値）
+   - [generating-wireframes Skill](../generating-wireframes/SKILL.md) を参照
+   - 生成後、REQUIREMENTS.md「3. UI/UX デザイン」から `./wireframes/index.html` にリンクする
+
+3. **TECH_DESIGN.md を作成**
+
+   ```
+   docs/<app>/<path>/TECH_DESIGN.md
+   ```
+
+   - 技術設計、テスト戦略（ジャーニーを E2E/Integration/Unit にマッピング）を記述
+   - [テンプレート](templates/tech-design.md) を参照
+
+4. **SCREEN_ITEMS_DEFINITION.md を作成（オプション）**
+
+   ```
+   docs/<app>/<path>/SCREEN_ITEMS_DEFINITION.md
+   ```
+
+   - 画面項目定義（フォーム項目、バリデーション、表示形式）を記述
+   - REQUIREMENTS.md の派生ドキュメントとして、UI詳細が必要な場合に作成
+
+### 既存機能の仕様書を更新する場合
+
+1. 対応する REQUIREMENTS.md と TECH_DESIGN.md を確認
+2. 変更内容に応じて両方を更新
+3. テスト戦略（テスト総数・内訳）を更新
+
+## Spec の 2 ティア構造（common / feature）
+
+本スキルが扱う REQUIREMENTS.md / TECH_DESIGN.md は **feature ティア**（機能単位）の spec である。
+その上位に、プロジェクト全体を俯瞰する **common ティア** が存在する。
+
+| ティア      | What / Why                | How                       | 配置例                                |
+| ----------- | ------------------------- | ------------------------- | ------------------------------------- |
+| **common**  | `REQUIREMENTS.md` (全体版) | `ARCHITECTURE.md` (全体版) | `docs/common/`                        |
+| **feature** | `REQUIREMENTS.md`         | `TECH_DESIGN.md`          | `docs/<app>/<feature>/`               |
+
+- feature spec は common ティア（サービス目的・アクター・システム構成・レイヤ規約・データモデル）を**前提とする**。common と矛盾しないこと。
+- 全体版テンプレートは `packages/core/templates/common/` を参照。既存実装からの common spec 作成は `reverse-engineering-common-spec` スキルを参照。
+- 詳細は `packages/core/docs/stdd-methodology.md` §3.0 を参照。
+
+## ドキュメント配置ルール
+
+| 実装ファイル                  | ドキュメント配置先                                                                                                                                                   |
+| ----------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `<app>/app/<path>/page.tsx`   | `docs/<app>/<path>/REQUIREMENTS.md`<br>`docs/<app>/<path>/TECH_DESIGN.md`<br>`docs/<app>/<path>/SCREEN_ITEMS_DEFINITION.md`（任意）                                  |
+| `<app>/components/<name>.tsx` | `docs/<app>/components/<name>/REQUIREMENTS.md`<br>`docs/<app>/components/<name>/TECH_DESIGN.md`<br>`docs/<app>/components/<name>/SCREEN_ITEMS_DEFINITION.md`（任意） |
+
+**例**:
+
+- 実装: `<app.path>/app/login/page.tsx`（`app.path` は `.stdd.config.yml` の `apps[].path`）
+- ドキュメント（`docs.layout.*` テンプレートに従う。`<app.id>` は `apps[].id`）:
+  - `docs/<app.id>/login/REQUIREMENTS.md`（必須）
+  - `docs/<app.id>/login/TECH_DESIGN.md`（必須）
+  - `docs/<app.id>/login/SCREEN_ITEMS_DEFINITION.md`（任意）
+
+## 絶対ルール: SSOT原則（最優先）
+
+⚠️ **Specドキュメントは「現在の最新仕様」だけを記述するSingle Source of Truth（SSOT）である**。履歴・経緯・対応中のissue・「今回の変更」は一切書かないこと。読者は「いま何が正しいか」だけを知りたい。履歴はgit log・PR description・issueに任せる。
+
+### 禁止事項
+
+以下は **REQUIREMENTS.md / TECH_DESIGN.md / SCREEN_ITEMS_DEFINITION.md のいずれでも禁止**:
+
+1. **issueへの言及**: `issue #123 で対応`, `#456 にて追加`, `本issueでは`, `Closes #...` 等
+2. **経緯・履歴の記載**: `変更前` / `変更後` / `更新前` / `更新後` / `変更理由` / `削除理由` / `旧仕様` / `〜だったが〜に変更` 等
+3. **過程に関する記載**: `今回追加`, `今回変更`, `新たに`, `既存`, `実装済み`, `新規追加`, `今回のスコープ`, `本対応で` 等
+4. **作成プロセスの注記**: `このドキュメントはリバースエンジニアリングで作成`, `〜を参考に作成`, `下記をベースに作成` 等
+5. **比較形式の記述**: `Before / After`, `旧 / 新`, `変更前後の差分` の形式
+
+### 違反例と修正例
+
+❌ **悪い例（履歴・経緯を記述）**:
+
+```markdown
+### メール送信実装
+
+**変更前**: Supabase Auth経由でメール送信
+**変更後**: Resend経由でHTMLメール送信
+**変更理由**: テンプレートのカスタマイズ性のため
+```
+
+✅ **良い例（現在の仕様のみ）**:
+
+```markdown
+### メール送信実装
+
+`admin.generateLink()` でリンクを生成し、Resend経由でHTMLメールを送信する。
+HTMLテンプレートは `lib/email/templates/` で管理。
+```
+
+❌ **悪い例（issue・今回への言及）**:
+
+```markdown
+## ユーザージャーニー
+
+### 新規ユーザー登録（issue #1234 で追加）
+
+今回のリリースで対応する新規登録フロー。
+```
+
+✅ **良い例**:
+
+```markdown
+## ユーザージャーニー
+
+### 新規ユーザー登録
+
+**Priority**: P0
+```
+
+### Self-check（コミット前に必ず実行）
+
+書き終えたら以下の禁止語を grep し、ヒットしたら必ず除去すること:
+
+```
+# 履歴・経緯・過程の記述
+今回 | 既存 | 新規追加 | 実装済み | 変更前 | 変更後 | 更新前 | 更新後
+変更理由 | 削除理由 | 旧仕様 | issue # | Closes # | リバースエンジニアリング
+本対応 | 本issue | 今回のスコープ | 今回の変更
+
+# テスト/ジャーニー再構成の履歴を暗示するフレーミング
+に統合 | を統合 | に集約 | を集約 | にまとめ | をまとめ | にマージ | をマージ
+別テストに分割 | テストを分けた | 元々は | 当初は | 以前は
+```
+
+「ジャーニー名」や「アーキテクチャ判断の理由」など現在仕様の説明として正当な「理由」は問題ない。禁止しているのは**変更そのものの理由**（なぜ仕様を変えたか）と、**過去構成からの再編を暗示するフレーミング**。
+
+> 特に注意: テスト戦略表で `✅ (更新に統合)` `2 ケースに集約` `1 テストにまとめる方針` のように「以前は別だったが今はまとめてある」ことを匂わせる表現は SSOT 違反。常に**現在の構成事実のみ**を記述し（例: `プロフィール情報を更新する テスト内のステップとして検証`）、設計判断の理由は注記/設計判断セクションで「**この構成を採る**理由」として書く。
+
+---
+
+## 基本原則
+
+### REQUIREMENTS.md（要件定義書）
+
+**目的**: ビジネス要件とユーザージャーニーをステークホルダー視点で定義
+
+**記述する内容**:
+
+- ユーザー視点（What & Why）
+- **ユーザーから見える挙動のみ**
+- すべてのユーザージャーニーに Priority（P0/P1/P2）を付与
+- UI/UX デザイン（HTML ワイヤーフレームへのリンク） … `generating-wireframes` スキルで生成
+
+**記述しない内容**:
+
+- 技術的な詳細（テーブル名、セッション管理、実装ファイルへの参照等）
+- テスト実装の詳細（TECH_DESIGN.md に記載）
+
+### TECH_DESIGN.md（設計書）
+
+**目的**: 機能実装のための技術設計とテスト戦略
+
+**記述する内容**:
+
+- 技術視点（How）
+- テスト戦略: 各ジャーニーをテストレベルにマッピング
+- アーキテクチャ、API 設計、エラーハンドリング
+- **テスト総数と内訳**（例: 合計 33 件 - Unit 18 件, Integration 9 件, E2E 6 件）
+
+**記述しない内容**:
+
+- 実装例・コード例（関数・メソッドの実装、Server Actions の実装、処理フローのコード）
+- ただし、**型定義・インターフェース**（Entity型、UI型、Request/Response型）や **データモデル**（ER図）はコードブロックで記述可
+
+### SCREEN_ITEMS_DEFINITION.md（画面項目定義書）- オプション
+
+**目的**: 画面の入力項目・表示項目の詳細定義
+
+**作成タイミング**: 以下の場合に作成を検討
+
+- フォーム項目が多い画面
+- 複雑なバリデーションルールがある
+- 表示形式（フォーマット、単位など）の定義が必要
+
+**記述する内容**:
+
+- 項目ID、項目名、データ型
+- 入力/表示の区分
+- バリデーションルール（必須、桁数、形式など）
+- 表示形式（日付フォーマット、通貨フォーマットなど）
+- 初期値、選択肢
+
+**記述しない内容**:
+
+- ユーザージャーニー（REQUIREMENTS.md に記載）
+- 技術設計・実装詳細（TECH_DESIGN.md に記載）
+
+### Priority（優先度）ガイドライン
+
+| Priority | 定義                                                     | テスト戦略                 |
+| -------- | -------------------------------------------------------- | -------------------------- |
+| **P0**   | Critical Path - ビジネスに直結、高頻度、複数システム統合 | E2E 必須 + Integration     |
+| **P1**   | Important - 重要だが Critical Path ではない              | E2E 検討、Integration 必須 |
+| **P2**   | Nice to Have - エッジケース、低頻度                      | Integration または Unit    |
+
+## 次のステップ
+
+Specドキュメント（REQUIREMENTS.md + TECH_DESIGN.md）の作成・レビュー完了後:
+
+1. **PLANドキュメントを作成** → [documenting-plans Skill](../documenting-plans/SKILL.md)
+2. PLANドキュメントに従ってテスト作成・実装を進める
+
+## 参照ファイル
+
+詳細なテンプレートとガイドは以下を参照:
+
+- **テンプレート**
+  - [REQUIREMENTS.md テンプレート](templates/requirements.md)
+  - [TECH_DESIGN.md テンプレート](templates/tech-design.md)
+  - [SCREEN_ITEMS_DEFINITION.md テンプレート](templates/screen-items-definition.md) ← 画面項目定義（オプション）
+- **関連スキル**
+  - [generating-wireframes Skill](../generating-wireframes/SKILL.md) ← UI を持つ機能の WF 生成
+- **ガイド**
+  - [STDD違反例と対策](guides/stdd-violations.md) ← 実装開始前に必読
+  - [エラーハンドリングガイド](guides/error-handling.md)
+- **次のステップ**
+  - [PLANドキュメント作成スキル](../documenting-plans/SKILL.md)
+
+## When NOT to Use This Skill
+
+以下の場合はこのスキルを使用しない:
+
+- **単純なバグ修正**: 仕様変更を伴わない場合
+- **リファクタリング**: 外部から見える挙動が変わらない場合
+- **ドキュメント修正のみ**: README や CLAUDE.md の更新
+- **テストの追加のみ**: 既存仕様に基づくテスト追加（ただし TECH_DESIGN.md のテスト総数は更新が必要）
+
+## チェックリスト
+
+### REQUIREMENTS.md 作成時
+
+```
+□ 概要（解決する問題、対象ユーザー、ビジネス目標）
+□ すべてのユーザージャーニーに Priority（P0/P1/P2）を付与
+□ UI/UX デザイン（HTML ワイヤーフレームを生成し「3. UI/UX デザイン」からリンク）→ generating-wireframes Skill
+□ エッジケース
+□ スコープ外
+□ SCREEN_ITEMS_DEFINITION.md が必要か検討（フォーム項目が多い場合）
+```
+
+### TECH_DESIGN.md 作成時
+
+```
+□ アーキテクチャ図（Mermaid）
+□ 主要な設計判断（Decision）- 選択と理由を明記
+□ データモデル（ER 図、TypeScript 型定義）
+□ API 設計（エンドポイント、型定義）
+□ エラーハンドリング戦略
+□ テスト戦略（ジャーニー別テストマッピング）
+□ テスト総数と内訳（Unit/Integration/E2E）
+□ 実装例・コード例が含まれていないことを確認（型定義・I/F は除く）
+□ SCREEN_ITEMS_DEFINITION.md が存在する場合、整合性を確認
+```
+
+### SCREEN_ITEMS_DEFINITION.md 作成時（任意）
+
+```
+□ 画面単位で項目を整理
+□ 各項目に一意のIDを付与
+□ データ型を明記（string, number, date, select など）
+□ バリデーションルール（必須、桁数、形式、範囲）
+□ 表示形式（日付フォーマット、通貨、単位など）
+□ 選択肢がある場合はすべての選択肢を列挙
+□ REQUIREMENTS.md の UI/UX デザインと整合性を確認
+```