@careerchain/stdd 0.1.0 → 0.1.2

package/assets/.claude/skills/documenting-specifications/templates/tech-design.md

@@ -1,241 +1,168 @@
-# TECH_DESIGN.md テンプレート
+# TECH_DESIGN.md テンプレート（feature）
 
-**目的**: 機能実装のための技術設計とテスト戦略
+**目的**: 機能（画面単位）の技術設計。実装者（人 / AI）が**ロジックを起こせる粒度**で、概要・設計判断・画面項目・ロジック設計・エラーハンドリング・非機能要件を定義する。
 
-**配置**: `docs/<app>/<path>/TECH_DESIGN.md`
+**配置**: `docs/<app>/<path>/TECH_DESIGN.md`（`.stdd.config.yml` の `docs.layout.tech_design` に従う）
 
-## テンプレート構造
-
-```markdown
-# [機能名] - 技術設計書
+## 章立ての骨格
 
----
+| 章 | 内容 | 適用 |
+| --- | --- | --- |
+| 1. 概要 | 目的・スコープ・**対応ユースケース**・**使用 API**・参照 | 常に |
+| 2. 主要な設計判断 | この機能**特有**の判断（選択＋理由） | 任意（なければ章ごと省略） |
+| 3. 画面項目定義 | UI × バリデーション × DB マッピング ＋ 画面状態 | 画面 feature は必須 / 非画面は省略 |
+| 4. ロジック設計 | ユースケース別ロジック（常に）＋ その他処理フロー（任意） | 常に（コア） |
+| 5. エラーハンドリング戦略 | API / 処理の失敗を本機能がどう捌くか | 常に |
+| 6. 非機能要件 | 性能・セキュリティ等の実現方法 | 任意（REQUIREMENTS に記載がある場合のみ） |
 
-# Part 1: 技術設計
+**横断要素は common を参照**（再定義しない）:
 
-## 1. 機能固有アーキテクチャ
+- データ構造 → [`TABLE_DEFINITION.md`](../../common/TABLE_DEFINITION.md)
+- API 契約 → [`API_SPEC.md`](../../common/API_SPEC.md)
+- 全体構成・スタック → [`ARCHITECTURE.md`](../../common/ARCHITECTURE.md)
 
-（この機能固有のアーキテクチャ図とデータフロー）
-
-```mermaid
-graph TD
-    A[ユーザー] --> B[ページコンポーネント]
-    B --> C[APIエンドポイント]
-    C --> D[サービス層]
-    D --> E[リポジトリ]
-    E --> F[(データベース)]
-```
+**テスト戦略は本書に書かない** → 同階層の [`TEST_PLAN.md`](./test-plan.md) に置く。
 
----
+## 実装コードについて
 
-## 2. 主要な設計判断
+**実コード（関数 / コンポーネント / Server Action の実装）は書かない**。ただし設計情報としての擬似コード・型シグネチャ・I/F・式は可。ロジック設計は「手順・擬似コード・計算式」で表現する。
 
-### 判断1: [技術選定]
+## テンプレート構造
 
-**選択**: ...
-**理由**: ...
+不要な章（2 / 3 / 6 など適用条件付き）は削除する。
 
-### 判断2: [アーキテクチャパターン]
+````markdown
+# [機能名] 技術設計書
 
-**選択**: ...
-**理由**: ...
+> ビジネス要件は [`REQUIREMENTS.md`](./REQUIREMENTS.md)、テスト戦略は [`TEST_PLAN.md`](./TEST_PLAN.md) を参照。
+> データ構造は [`TABLE_DEFINITION.md`](../../common/TABLE_DEFINITION.md)、API は [`API_SPEC.md`](../../common/API_SPEC.md) を参照。
 
----
+## 1. 概要
 
-## 3. データモデル
+- **目的**: （この機能が何を実現するか）
+- **スコープ**: （対象 / 対象外）
+- **参照**: 使用テーブル [`users`, `applies` 等]（common の `TABLE_DEFINITION.md` を指す）
 
-### ER図
+### 1.1 対応ユースケース
 
-```mermaid
-erDiagram
-    users ||--o{ projects : has
-    users {
-        uuid id PK
-        string email
-        timestamp created_at
-    }
-```
+REQUIREMENTS の各ユースケースを列挙し、本書のどの設計で実現するかを対応づける（設計漏れ防止）。
 
-### TypeScript型定義
-
-```typescript
-// Entity型
-export interface UserEntity {
-  id: string;
-  email: string;
-  created_at: string;
-}
-
-// UI型
-export interface User {
-  id: string;
-  email: string;
-  createdAt: Date;
-}
-```
+| ユースケース（REQUIREMENTS §2.1） | Priority | 実現する設計 |
+| --- | --- | --- |
+| [ユースケース名] | P0 | §4.1 ユースケース別ロジック / §3 画面項目定義 |
+| [ユースケース名] | P1 | §4.1 ユースケース別ロジック |
 
-### バリデーションルール
+### 1.2 使用 API
 
-- `email`: 必須、メール形式、最大255文字
-- `created_at`: ISO8601形式、過去の日時
+本機能が使用する API を列挙し、`API_SPEC.md` の定義へリンクする（API を持たない機能では本節を削除）。
 
----
+| API | 用途 | 対応ユースケース | 定義 |
+| --- | --- | --- | --- |
+| `POST /api/...` | [用途] | [ユースケース名] | [API_SPEC](../../common/API_SPEC.md) |
 
-## 4. API設計
+## 2. 主要な設計判断
 
-### エンドポイント
+> この機能**特有**の判断のみ。共通方針は ARCHITECTURE に従う。判断が無ければ本章を削除する。
 
-#### POST /api/users
+### 判断 1: [テーマ]
 
-**リクエスト**:
-```typescript
-interface CreateUserRequest {
-  email: string;
-}
-```
+- **選択**: ...
+- **理由**: ...
 
-**レスポンス**:
-```typescript
-interface CreateUserResponse {
-  user: User;
-}
-```
+## 3. 画面項目定義
 
-**ビジネスロジック**:
-1. メールアドレスの重複チェック
-2. ユーザー作成
-3. ウェルカムメール送信
+> 画面を持つ feature のみ。非画面（API 専用 / バッチ / 共通部品）では本章を削除する。
+> DB カラムは [`TABLE_DEFINITION.md`](../../common/TABLE_DEFINITION.md) のカラムを指す（再定義しない）。
 
----
+**操作モード**（入力フォームのみ）: Create / Edit / View（View は全項目非活性）
 
-## 5. エラーハンドリング戦略
+| 項目名 | 必須（条件） | 活性（条件） | デフォルト値 | 入力コンポーネント | 制約 | SELECT 定義 | DB テーブル.カラム | 備考 |
+| --- | --- | --- | --- | --- | --- | --- | --- | --- |
+| [項目名] | Create: 必須 / Edit: 必須 | Create: 活性 / Edit: 非活性 | null | Text | maxLen=100 | – | users.name | |
+| [項目名] | 任意 | 活性 | null | Select | – | S.1 [選択肢] | users.status | |
 
-### エラーコード定義
+**操作ボタン**
 
-| エラーコード | HTTPステータス | メッセージ | 原因 |
-|------------|--------------|----------|------|
-| `USER_NOT_FOUND` | 404 | ユーザーが見つかりません | 存在しないユーザーID |
-| `EMAIL_ALREADY_EXISTS` | 409 | このメールアドレスは既に使用されています | メール重複 |
-| `VALIDATION_ERROR` | 400 | 入力内容を確認してください | バリデーション失敗 |
+| ボタン | 表示条件 | 活性条件 | アクション |
+| --- | --- | --- | --- |
+| [登録] | Create / Edit | View: 非活性 | 全バリデーション後に保存 |
 
-### 実装方針
+**バリデーション適用ルール**（下書き保存等のモードがある場合）
 
-- すべてのエラーは`AppError`クラスを継承
-- エラーコードでエラー種別を識別
-- ユーザー向けメッセージとログ用メッセージを分離
+| 種別 | 本登録 | 下書き保存 |
+| --- | --- | --- |
+| 必須チェック | ✅ | ❌ |
+| 型 / 桁 / 形式 / 範囲チェック | ✅ | ✅ |
 
----
+（SELECT の選択肢は共通定義を参照 ID `S.x` で指す。DB カラムは `TABLE_DEFINITION.md` の定義を正とする）
 
-## 6. セキュリティ要件
+**画面状態**（画面全体の表示状態）
 
-- **認証・認可**: 実装方法と適用範囲
-- **XSS対策**: 対策内容
-- **CSRF対策**: 対策内容
-- **SQLインジェクション対策**: 対策内容
-- **個人情報の暗号化**: 暗号化方式
+| 状態 | 表示 |
+| --- | --- |
+| 通常 | [項目・データを表示] |
+| 空（0 件） | [空表示の文言・代替表示] |
+| ローディング | [取得中の表示] |
+| エラー | [失敗時の表示。挙動は §5 を参照] |
 
----
+## 4. ロジック設計
 
-## 7. パフォーマンス要件
+> 本機能のコア。集計式・変換・ドメインルール・トランザクション境界・副作用・複数テーブル横断の流れを
+> **手順 / 擬似コード / 計算式**で記述する（実コードは書かない）。API を持たない機能（DB 直接参照等）でもここに書く。
 
-- **ページ読み込み時間**: 2秒以内
-- **API応答時間**: 500ms以内
-- **同時接続数**: 1000ユーザー
+### 4.1 ユースケース別ロジック
 
----
+REQUIREMENTS §2.1 の各ユースケースの実現ロジックを**ユースケース単位**で記述する（§1.1 の対応表と紐づく。各ユースケースが必ずロジックとして設計されていること）。
 
-## 8. テスト戦略
+#### [ユースケース名]
 
-### ジャーニー別テスト戦略
+1. [入力 / トリガ]
+2. [取得]: [`table`] を [条件（例: `deleted_at IS NULL`）] で参照
+3. [加工 / 集計]: [週/月/年バケット集計・近似指標の算出式など]
+4. [出力 / 永続化 / 副作用]
 
-| ジャーニー | E2E | Integration | Unit | 根拠 |
-|---------|-----|-------------|------|-----------|
-| P0: メインフロー | ✅ | ✅ | ✅ | Critical path、ビジネスに直結、複数システム統合 |
-| P1: 重要なエラーケース | ⚠️ 検討 | ✅ | ✅ | 頻度高い、Integration必須、E2Eは複雑さ・コストで判断 |
-| P2: エッジケース | ❌ | ⚠️ | ✅ | 低頻度、Unit十分 |
-
-### テストファイル構成
-
-- **E2E**: `e2e/tests/[app]/[feature].spec.ts`
-- **Integration**: `[app]/components/[name].test.tsx`
-- **Unit**: `[app]/lib/*.test.ts`, `[app]/domain/models/*.test.ts`
 ```
-
-## 重要なポイント
-
-- REQUIREMENTS.mdのジャーニーをテストレベル（E2E/Integration/Unit）にマッピング
-- テストレベル決定の根拠（Rationale）を含める
-- 設計判断は「選択」と「理由」を明記
-- アーキテクチャ、API設計、エラーハンドリング戦略
-
-### 実装例・コード例について
-
-**TECH_DESIGN.mdには実装例・コード例を含めない**。ただし、以下の場合はコードブロックの使用が許容される:
-
-- **型定義・インターフェース**: Entity型、UI型、Request/Response型など設計情報として必要なもの
-- **データモデル**: ER図、バリデーションルール
-- **API設計**: エンドポイント、リクエスト/レスポンス型
-
-以下は記述しないこと:
-- 関数・メソッドの具体的な実装
-- コンポーネントの実装
-- Server Actions の実装
-- 処理フローのコード
-
-## TECH_DESIGN.md作成時のルール
-
-### 1. 「実装済み」「新規追加」の分類は不要
-
-**理由**: REQUIREMENTS.mdが常にSSoT（Single Source of Truth）であるため、TECH_DESIGN.mdでは実装済みかどうかの区別は不要。すべての要件を統一的に設計する。
-
-❌ **悪い例**:
-```markdown
-### 実装済み（既存）
-- ✅ 認証・認可: NextAuth + Supabase Authで二重認証
-
-### 新規追加（パスワード認証）
-- ✅ Supabase Authによるパスワード認証
+（必要に応じてシーケンス図 or 擬似コード）
+集計値 M = Σ(対象) / 母集団   ※[可] or [近似]
 ```
 
-✅ **良い例**:
-```markdown
-## 6. セキュリティ要件
+- **ドメインルール / 計算式**: [境界条件・丸め・単位・null の扱いを明示]
+- **トランザクション / 副作用**: [トランザクション境界・冪等性・外部送信（メール等）]
 
-- **認証・認可**: NextAuth + Supabase Authで二重認証
-- **Supabase Authによるパスワード認証**: Credentials Providerで`signInWithPassword`を使用
-```
+### 4.2 その他処理フロー  〔機能固有ロジックがあれば記載・なければ省略〕
 
-### 2. 削除すべきセクション
+ユースケースに直接紐づかない機能固有のロジック（バッチ / スケジュール処理・共通集計・内部整合処理 等）。各フローに識別名を付け、TEST_PLAN の処理フロー別テストと対応づける。
 
-TECH_DESIGN.mdでは以下のセクションは**削除する**こと:
+#### [処理フロー名]
 
-- ❌ **Integration Points**: 外部システム・内部システムの一覧
-- ❌ **実装順序**: フェーズ別の実装計画
-- ❌ **ドキュメント参照文言**: 「このドキュメントは〜を参考に作成されました」
+1. [トリガ / 手順]
+2. ...
 
-### 3. チェックボックス形式の削除
+## 5. エラーハンドリング戦略
 
-TECH_DESIGN.mdでは、実装状態を示すチェックボックス（`- [ ]`や`- ✅`）は使用しない。
+> API / 処理の失敗を**本機能がどう捌くか**。エラーコードのカタログは [`API_SPEC.md`](../../common/API_SPEC.md) を参照。
 
-❌ **悪い例**:
-```markdown
-## 6. セキュリティ要件
+| 失敗ケース | 検知 | 本機能の挙動 |
+| --- | --- | --- |
+| 認証切れ（401） | API レスポンス | ログイン画面へリダイレクト |
+| 検証エラー（400） | API レスポンス | 該当項目にインラインエラー表示 |
+| 取得失敗 / タイムアウト | API レスポンス | エラーメッセージ表示・部分クラッシュ防止・リトライ導線 |
 
-- [ ] 認証・認可の実装
-- [ ] XSS対策
-- ✅ CSRF対策
-```
+## 6. 非機能要件
 
-✅ **良い例**:
-```markdown
-## 6. セキュリティ要件
+> REQUIREMENTS（feature / common）に非機能要件の記載がある場合のみ、その**実現方法**を書く。無ければ本章を削除する。
 
-- **認証・認可**: NextAuth + Supabase Authで二重認証
-- **XSS対策**: React自動エスケープ + DOMPurify
-- **CSRF対策**: NextAuthがCSRFトークンを自動管理
+- **性能**: [目標値とその実現手段（インデックス / キャッシュ等）]
+- **セキュリティ**: [認証・認可・データ保護の実現手段]
+- **アクセシビリティ / 可用性**: [該当時]
+````
 
-### スコープ外
+## 記述しない内容（責務分界）
 
-- 二要素認証（2FA）
-- アカウントロック
-```
+- データ構造（テーブル・カラム定義） → common の `TABLE_DEFINITION.md`
+- API 入出力契約・エラーコードカタログ → common の `API_SPEC.md`
+- 全体構成・技術スタック → common の `ARCHITECTURE.md`
+- テスト戦略 → 同階層の `TEST_PLAN.md`
+- ユースケース（振る舞い＋受入基準） → `REQUIREMENTS.md`
+- 関数 / メソッドの具体実装コード（擬似コード・型 I/F は可）
+- 実装状態のチェックボックス（`- [ ]` / `✅`）・「実装済み / 新規追加」の区別・履歴（SSoT 原則）

package/assets/.claude/skills/documenting-specifications/templates/test-plan.md

@@ -0,0 +1,58 @@
+# TEST_PLAN.md テンプレート（feature）
+
+**目的**: 機能（画面単位）のテスト戦略。**REQUIREMENTS のユースケース**と **TECH_DESIGN のロジック設計**の両方を、テストレベル（E2E / Integration / Unit）に漏れなくマッピングする。
+
+**配置**: `docs/<app>/<path>/TEST_PLAN.md`（`.stdd.config.yml` の `docs.layout.test_plan` に従う）
+
+## 章立ての骨格
+
+| 章 | 内容 | 適用 |
+| --- | --- | --- |
+| 1. ユースケース別テスト戦略 | REQUIREMENTS §2.1 の全ユースケース × テストレベル × 根拠 | 常に |
+| 2. その他処理フロー別テスト戦略 | TECH_DESIGN §4.2 その他処理フロー × テストレベル × 根拠 | TECH_DESIGN に §4.2 がある場合 |
+
+- **網羅性の二本立て**: REQUIREMENTS のユースケース（§1）と TECH_DESIGN ロジック設計のその他処理フロー（§2）の**両方**を漏れなくカバーする。
+- 各レベルを選ぶ / 選ばない**根拠（Rationale）**を必ず書く。
+
+## テンプレート構造
+
+````markdown
+# [機能名] テスト計画
+
+> ビジネス要件は [`REQUIREMENTS.md`](./REQUIREMENTS.md)、技術設計は [`TECH_DESIGN.md`](./TECH_DESIGN.md) を参照。
+
+## 1. ユースケース別テスト戦略
+
+REQUIREMENTS §2.1 の**全ユースケースを 1 行ずつ**列挙する（ユースケース名は REQUIREMENTS と同名・Priority も引く）。
+**振る舞い（手順）→ E2E の骨格**、**受入基準（EARS）→ Unit / Integration** で担保するのが基本対応。
+
+| ユースケース（REQUIREMENTS §2.1） | Priority | E2E | Integration | Unit | 根拠 |
+| --- | --- | --- | --- | --- | --- |
+| [ユースケース名] | P0 | ✅ | ✅ | ✅ | Critical path・ビジネス直結・複数システム統合 |
+| [ユースケース名] | P1 | ⚠️ 検討 | ✅ | ✅ | 頻度高い・Integration 必須・E2E はコストで判断 |
+| [ユースケース名] | P2 | ❌ | ⚠️ | ✅ | 低頻度・Unit で十分 |
+
+> 受入基準（EARS）の主要条件（例外・境界・データ制約）は、対応する Unit / Integration の根拠列に検証観点として落とす。
+
+## 2. その他処理フロー別テスト戦略
+
+> TECH_DESIGN §4.2「その他処理フロー」がある場合のみ。各処理フローを 1 行ずつ列挙する（無ければ本章を削除）。
+
+| 処理フロー（TECH_DESIGN §4.2） | E2E | Integration | Unit | 根拠 |
+| --- | --- | --- | --- | --- |
+| [処理フロー名] | ❌ | ✅ | ✅ | バッチ / 内部ロジック・境界値は Unit で網羅 |
+````
+
+## 記述基準
+
+- **ユースケース名は REQUIREMENTS §2.1 と一致させ、全ユースケースを漏れなく 1 行ずつ記載する**（REQUIREMENTS ↔ TEST_PLAN を 1:1 で追跡可能にする）。Priority も REQUIREMENTS から引く。
+- **TECH_DESIGN §4.2 その他処理フローがある場合、§2 に全フローを 1 行ずつ記載する**（TECH_DESIGN ロジック設計 ↔ TEST_PLAN も 1:1 で追跡可能にする）。
+- **振る舞い（手順）→ E2E、受入基準（EARS）→ Unit / Integration** の役割で対応づける。
+- テストレベルの選択は「✅ 実施 / ⚠️ 検討 / ❌ 不要」で示し、根拠列を空にしない。
+- ロジック設計の検証観点（集計式・境界値）は対応する Unit / Integration の根拠に紐づける。
+
+## 記述しない内容（責務分界）
+
+- ユースケース本体（振る舞い＋受入基準） → `REQUIREMENTS.md`
+- ロジック設計・画面項目 → `TECH_DESIGN.md`
+- テストの実装コード → テストファイル本体

package/assets/.claude/skills/generating-wireframes/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: generating-wireframes
 description: |-
-  REQUIREMENTS.md のユーザージャーニーから、低忠実度（low-fidelity）の HTML ワイヤーフレームを生成する。技術スタック非依存の素の HTML（CSS は各 HTML に `<style>` で埋め込み・自己完結）で、画面レイアウト・情報設計・主要文言（タイトル / ボタン / 項目ラベル）を合意形成用に可視化する。
+  REQUIREMENTS.md のユースケース（振る舞い＋受入基準）から、低忠実度（low-fidelity）の HTML ワイヤーフレームを生成する。技術スタック非依存の素の HTML（CSS は各 HTML に `<style>` で埋め込み・自己完結）で、画面レイアウト・情報設計・主要文言（タイトル / ボタン / 項目ラベル）を合意形成用に可視化する。
 when_to_use: |-
   「ワイヤーフレーム」「WF」「wireframe」「画面設計」「画面イメージ」「モックの前段」「UI/UX デザインのHTML化」「REQUIREMENTS の画面を作る」に関する作業のとき。
 allowed-tools: Read, Write, Edit, Glob, Grep
@@ -9,7 +9,7 @@ allowed-tools: Read, Write, Edit, Glob, Grep
 
 # ワイヤーフレーム生成
 
-REQUIREMENTS.md の **ユーザージャーニー**と**画面要素**をもとに、低忠実度の HTML ワイヤーフレーム（WF）を生成する。WF は REQUIREMENTS.md の「3. UI/UX デザイン」セクションの実体となり、ステークホルダーが画面構成・遷移・主要文言を合意するために使う。
+REQUIREMENTS.md の **ユースケース**（振る舞い＋受入基準）と**画面要素**をもとに、低忠実度の HTML ワイヤーフレーム（WF）を生成する。WF は REQUIREMENTS.md の「2.4 UI/UX・画面」セクションの実体となり、ステークホルダーが画面構成・遷移・主要文言を合意するために使う。
 
 ## 何を作るか / 作らないか
 
@@ -39,13 +39,13 @@ docs/<app>/<feature_path>/wireframes/
 
 ### 1. 入力を読む
 
-- 対象の `REQUIREMENTS.md`（ユーザージャーニー・表示要素・空 / エラー状態）
-- `SCREEN_ITEMS_DEFINITION.md`（存在する場合 — フォーム項目名・選択肢・必須/任意の出所はこれ）
+- 対象の `REQUIREMENTS.md`（ユースケース：振る舞い＋受入基準・表示要素）
+- `TECH_DESIGN.md` の画面項目定義セクション（画面 feature にあれば — フォーム項目名・選択肢・必須/任意・画面状態〔通常 / 空 / ローディング / エラー〕の出所はこれ）
 - 既存の類似画面の WF（`docs/**/wireframes/` を Glob して文言・構造を踏襲）
 
 ### 2. 画面を洗い出す
 
-ユーザージャーニーの各ステップが「どの画面で起きるか」を割り出し、画面のリストを作る。1 ジャーニー = 複数画面のことも、複数ジャーニーが 1 画面を共有することもある。各画面について必要な**状態**（通常 / 空 / エラー / ローディング）を決める。詳細は [guides/from-requirements.md](guides/from-requirements.md)。
+ユースケースの振る舞い（手順）の各ステップが「どの画面で起きるか」を割り出し、画面のリストを作る。1 ユースケース = 複数画面のことも、複数ユースケースが 1 画面を共有することもある。各画面について必要な**状態**（通常 / 空 / エラー / ローディング）を決める。詳細は [guides/from-requirements.md](guides/from-requirements.md)。
 
 ### 3. 雛形をコピーして組む
 
@@ -54,7 +54,7 @@ docs/<app>/<feature_path>/wireframes/
 3. 各画面の `<title>` と `.wf-screen-label` に「画面名 / 状態名」を実値で入れる。
 4. `<style>` ブロックは各画面で同一内容を保つ（デザインシステムを変えたい場合は全画面の `<style>` を揃えて更新する）。CSS 単体ファイルは作らない。
 
-### 4. REQUIREMENTS.md の「3. UI/UX デザイン」を更新
+### 4. REQUIREMENTS.md の「2.4 UI/UX・画面」を更新
 
 ASCII アートは置かない。代わりに以下を書く（テンプレートは `documenting-specifications` の REQUIREMENTS テンプレートに準拠）:
 
@@ -64,7 +64,7 @@ ASCII アートは置かない。代わりに以下を書く（テンプレー
 
 ### 5. セルフチェック
 
-- [ ] すべての P0 / P1 ジャーニーに対応する画面が WF 化されている
+- [ ] すべての P0 / P1 ユースケースに対応する画面が WF 化されている
 - [ ] 各画面に**実文言**のタイトル・ボタン・ラベルが入っている（ダミー `[...]` が残っていない）
 - [ ] 空状態・主要エラー状態の WF がある
 - [ ] モバイル幅でも破綻しない（`wf-page--mobile` でプレビュー確認、または論理的に 1 列化される構造）
@@ -98,8 +98,8 @@ ASCII アートは置かない。代わりに以下を書く（テンプレー
 ## STDD フローでの位置づけ
 
 ```
-REQUIREMENTS.md（ジャーニー）
-  └─ ワイヤーフレーム生成（本スキル）── 「3. UI/UX デザイン」の実体に
+REQUIREMENTS.md（ユースケース）
+  └─ ワイヤーフレーム生成（本スキル）── 「2.4 UI/UX・画面」の実体に
        └─ TECH_DESIGN.md → テスト → 実装
 ```
 
@@ -116,6 +116,6 @@ REQUIREMENTS.md（ジャーニー）
 
 - [templates/screen.html](templates/screen.html) — 画面ひな型（`<head>` に汎用デザインシステムの `<style>` を埋め込み済み＝デザインシステム本体）
 - [templates/index.html](templates/index.html) — 画面一覧ひな型
-- [guides/from-requirements.md](guides/from-requirements.md) — ジャーニー → 画面の起こし方
+- [guides/from-requirements.md](guides/from-requirements.md) — ユースケース → 画面の起こし方
 - [examples/](examples/) — toC / toB のサンプル WF
 - 関連: [documenting-specifications](../documenting-specifications/SKILL.md)（REQUIREMENTS テンプレート）

package/assets/.claude/skills/generating-wireframes/guides/from-requirements.md

@@ -1,26 +1,26 @@
-# ジャーニー → 画面の起こし方
+# ユースケース → 画面の起こし方
 
-REQUIREMENTS.md のユーザージャーニーから WF にすべき画面を導くための手順。
+REQUIREMENTS.md のユースケース（振る舞い＋受入基準）から WF にすべき画面を導くための手順。
 
-## 1. ジャーニーのステップを「画面」に割り当てる
+## 1. ユースケースの振る舞い（手順）を「画面」に割り当てる
 
-各ジャーニーの手順を読み、**ユーザーが何かを見る / 操作する単位**で画面を切る。
+各ユースケースの振る舞い（手順）を読み、**ユーザーが何かを見る / 操作する単位**で画面を切る。
 
-例（一覧 → 詳細 → 申込のジャーニー）:
+例（一覧 → 詳細 → 申込のユースケース）:
 
-| ジャーニー手順 | 画面 |
+| 振る舞いの手順 | 画面 |
 | -------------- | ---- |
 | 一覧を検索・絞り込みする | 一覧画面（検索条件 + 結果テーブル/カード） |
 | 1 件を選んで詳細を見る | 詳細画面 |
 | 申込フォームを入力して送信する | 申込フォーム（モーダル or 専用画面） |
 | 送信完了を確認する | 完了画面 / トースト |
 
-- 1 ジャーニーが複数画面にまたがる、複数ジャーニーが 1 画面を共有する、どちらもある。
-- 重複を避けるため、**先に全ジャーニーを通して画面の集合を作ってから** WF 化する。
+- 1 ユースケースが複数画面にまたがる、複数ユースケースが 1 画面を共有する、どちらもある。
+- 重複を避けるため、**先に全ユースケースを通して画面の集合を作ってから** WF 化する。
 
 ## 2. 各画面の「状態」を決める
 
-P0 / P1 で「期待結果」や「エラーケース」に出てくる状態を WF にする。
+P0 / P1 のユースケースで、受入基準（EARS）の「エラー時（IF）」や「空・境界（WHERE）」に出てくる状態を WF にする。
 
 | 状態 | 作るべきか | クラス例 |
 | ---- | ---------- | -------- |
@@ -41,13 +41,13 @@ P0 / P1 で「期待結果」や「エラーケース」に出てくる状態を
 | ステータス管理（カンバン） | `wf-kanban--3` + `wf-kanban__col` + `wf-card` |
 | 確認 / 申込ダイアログ | `wf-modal`（`wf-modal__head/body/foot`） |
 
-## 4. 文言は SCREEN_ITEMS_DEFINITION.md / REQUIREMENTS.md から取る
+## 4. 文言は TECH_DESIGN.md の画面項目定義 / REQUIREMENTS.md から取る
 
-- フォーム項目名・必須/任意・選択肢は `SCREEN_ITEMS_DEFINITION.md` があればそれが出所（なければ REQUIREMENTS.md の表示要素から）。
-- ボタン文言・タブ名・空状態メッセージは REQUIREMENTS.md のジャーニー / 期待結果から拾う。
+- フォーム項目名・必須/任意・選択肢は `TECH_DESIGN.md` の画面項目定義セクション（画面 feature にあれば）が出所（なければ REQUIREMENTS.md の表示要素から）。
+- ボタン文言・タブ名・空状態メッセージは REQUIREMENTS.md のユースケース（振る舞い / 受入基準）から拾う。
 - **想像で増やさない**。Spec にない項目・ボタンを WF に足すと、WF が Spec を上書きしてしまい SSOT が壊れる。足したくなったら先に REQUIREMENTS.md を更新する。
 
 ## 5. index と REQUIREMENTS のリンクを最後に整える
 
 - `index.html` に全画面・全状態を列挙。
-- REQUIREMENTS.md「3. UI/UX デザイン」から `./wireframes/index.html` を指し、各画面の要点（タイトル・主要ボタン・表示要素）をテキストでも残す（HTML を開けない読者・差分レビュー用）。
+- REQUIREMENTS.md「2.4 UI/UX・画面」から `./wireframes/index.html` を指し、各画面の要点（タイトル・主要ボタン・表示要素）をテキストでも残す（HTML を開けない読者・差分レビュー用）。

package/assets/.claude/skills/generating-wireframes/templates/index.html

@@ -4,7 +4,7 @@
   使い方:
     - docs/<app>/<feature_path>/wireframes/index.html としてコピーする。
     - 各画面 HTML へのリンクと、1 行説明を並べる。
-    - REQUIREMENTS.md の「3. UI/UX デザイン」からは、まずこの index.html を指す。
+    - REQUIREMENTS.md の「2.4 UI/UX・画面」からは、まずこの index.html を指す。
 -->
 <!DOCTYPE html>
 <html lang="ja">

package/assets/.claude/skills/introducing-stdd/SKILL.md

@@ -117,8 +117,11 @@ docs:
   layout:
     common_requirements: docs/common/REQUIREMENTS.md    # common ティアを使う場合のみ
     common_architecture: docs/common/ARCHITECTURE.md
+    common_table_definition: docs/common/TABLE_DEFINITION.md
+    common_api_spec: docs/common/API_SPEC.md             # API がある場合
     requirements: docs/{{app.id}}/{{feature_path}}/REQUIREMENTS.md
     tech_design: docs/{{app.id}}/{{feature_path}}/TECH_DESIGN.md
+    test_plan: docs/{{app.id}}/{{feature_path}}/TEST_PLAN.md
     plan: docs/{{app.id}}/{{feature_path}}/plans/{{date}}.md
 ```