Design Feature

---
name: design-feature
description: 抽象的な要件・事業側の要求から要求を深掘りし、コードベース SSoT で既存実装整合性を確認した上で「実装マスタ（01_requirements_skeleton.md）」と「システム要件書（02_system_requirements.md）」を作成する。使用タイミング (1)「○○って機能を作りたい」「この要求を満たす機能を設計して」等の抽象要件提示時、(2) 既存機能の拡張・Phase 分割等の要件定義開始時、(3) `/design-feature ...` 実行時。境界: 要件確定後の実装計画書・PR分割の立案は plan-feature-prs、実装の分割・進捗管理は large-task、既存文書のレビューは doc-review。本スキルは新規要件の深掘りと文書化が目的。
---

# Design Feature

抽象的な要求から、実装可能な粒度の「実装マスタ（01）」と、非開発者の関係者向けの「システム要件書（02）」をペアで作るワークフロー。`large-task` 実装フェーズの上流にあたる設計工程を担う。

> 用語注記: 本スキルの「AskUserQuestion」はユーザーへの選択肢提示質問を指す（Claude Code: AskUserQuestion ツール。無い環境では番号付き選択肢のテキスト質問で代替）。「Explore agent」は読み取り専用の調査用サブエージェントを指す。

## 出力物

| ファイル | 内容 | 読み手 |
|---------|------|-------|
| `01_requirements_skeleton.md` | 実装マスタ。What + How。DB スキーマ / API / Usecase / ガード / 影響範囲 / 設計理由 | 実装担当 |
| `02_system_requirements.md` | システム要件書。What のみ。Why は注記程度 | 企画・事業側 / 連携先 / サポート担当 |

両者は同一プロジェクトの **2 つの顔**。01 を SSoT として 02 を抽出する関係。

## 既存設定との関係

- **Phase 0-5（@context/workflow-rules.md）**: 本スキルは Phase 0-2（準備・調査・計画）を担う。Phase 3 以降の実装は `/large-task` 等に引き継ぐ
- **メモリディレクトリ（@context/memory-file-formats.md）**: 既定保存先は `${MEMORY_DIR}/memory/YYMMDD_<context_name>/`
- **agent review（@context/agent-cli-guide.md）**: 01 確定前の必須プロセス
- **ライティング（`/ukwhatn-writing`）**: 文体・語彙ルールを全章で遵守
- **`/large-task`（既存スキル）**: 本スキルが上流（設計）、`large-task` が下流（実装分割）。明確に分担

## ワークフロー（Phase 0-5）

```
Phase 0: 準備           → メモリディレクトリ・タスク管理
Phase 1: 要求深掘り     → AskUserQuestion で目的・スコープ・制約を確定
Phase 2: 既存実装調査   → コードベース SSoT で関連実装を把握
Phase 3: 01 ドラフト     → 実装マスタを章別に書く
Phase 4: agent review   → 外部CLI で Action Required 0 まで反映
Phase 5: 02 抽出         → 01 から What だけ抽出して書き、完了報告
```

各 Phase の具体手順: @references/workflow-detail.md

## 厳守ルール（CRITICAL）

### 1. コードベース SSoT
- 既存実装に関する SSoT は**コードベース**。メモリディレクトリ内資料は outdated 可能性あり
- ドキュメントに事実を書く前に必ず実コードで裏取り
- Explore agent の判断もそのまま信用せず、重要箇所は Read で再確認する
- 公式仕様は context7 / WebSearch で確認

### 2. 禁止フレーズ
以下を 01 / 02 のいずれにも書かない:

要調査 / TBD / TODO / 要確認 / 要検討 / 追って確認 / 別途決定 / 要相談 / 場合によっては / 必要に応じて

→ 書きたくなったら **Phase 2 で情報を揃える** か **AskUserQuestion で確定** する。チェックリスト: @references/quality-checklist.md

### 3. 設計判断は AskUserQuestion
- 複数案で迷う、スケジュール・金額・対外コミュニケーションが絡む、既存パターンから外れる、スコープ縮小判断 — いずれも勝手に決めない
- 採用案 + 不採用案 + 理由をセットで `30_decisions.md` または `99_history.md` に記録

### 4. ライティング（`/ukwhatn-writing`）
- 常体・簡潔・端的・宣言形
- AI 翻訳調禁止（「〜することが可能」→「〜できる」、「実施する/対応する」の乱用回避）
- 専門用語は原語 + `` `code` `` 表記
- 推測はぼかし、断定は事実のみ
- 自明な前置きを削る

### 5. 既存パターン踏襲
- プロジェクトの既存規約・命名・レイヤー構成から自己判断で逸脱しない
- 逸脱が必要なら必ず AskUserQuestion

### 6. 識別子・用語は正式名称
- システム上の識別子（Cloud Task キュー名 / Scheduler ジョブ名 / enum 値 / procedure 名）は実装から抽出した正式名称で書く。独自の通称・意訳を作らない
- 外部システムの操作は先方の正式 API 名で表現（例: 「カード失効」ではなく「解約（`AM01AE14-解約登録API`）」）
- データ項目は既存スキーマのフィールドと対応させる。スキーマに無い概念語（「表示名」等）を導入しない

### 7. 一覧は SSoT 全件 grep で網羅
- Cloud Task / Scheduler / Webhook / API 等の一覧表は、定義箇所（routers / domain 等の SSoT ファイル）を全件 grep してから作る
- 部分列挙なら「一部抜粋」と明記。grep 検証コマンドと件数を 05_log.md に記録

### 8. 可能な限り既存実装を踏襲できるよう網羅的に調査
- 新アクター（例: 降格者）の挙動は、類似既存アクター（例: 退会者）の現状動作を実コードで網羅的に調査し、追従させるのが原則。対応表を 01 に書く
- 既存実装のガード漏れ・不統一に見えるものを「バグ」「統一修正対象」と独断評価しない。意図的設計の可能性を AskUserQuestion で確認
- 既存挙動の変更・広範囲リファクタをスコープに含めない。必要性を感じたら「後続フェーズ」として分離提示

### 9. 状態変更は内部表現まで特定
- 「無効化」「失効」等の状態変更は、どのフィールド・enum 値で記録するかまで 01 で特定（例: `kycStatus = "reapplication"`）
- 既存関数を流用できるかをまず確認し、流用できる場合は 01 に関数名を明記（例: `invalidateKycStatus` / `reissueMkp` 流用）。02 では「既存処理を流用」程度に言及

### 10. 要件の語彙で設計を組み立てない

- 互換・移行・外部連携・規制対応など外部制約を満たす機能でも、成果物は自システムの第一級機能として設計・命名する
- 制約は仕様（fixtures・規範ルール・契約文書）として自立させ、制約元（旧システム・相手システム・規格書）の語彙・構造を設計書の骨格や実装の識別子にしない。制約元への言及は仕様書・ADR の背景節のみに置く
- 01 完成前に「章立て・用語が制約元との対応を骨格にしていないか」を確認する（対応表は根拠資料として分離し、01 本文は自システムの語彙で書く）

## Phase 別の要点

### Phase 0: 準備

1. `MEMORY_DIR` 確認（未定義なら `.local/`）
2. 既存メモリディレクトリ検索 → 同コンテキストなら再利用、新規なら `${MEMORY_DIR}/memory/YYMMDD_<context_name>/` 作成
3. `05_log.md` を初期化 / 追記、ユーザー指示を逐語記録
4. 関連する過去タスク・issue を `findmem` 相当で探索（@context/workflow-rules.md §1.0）
5. タスク管理機構（Claude Code: TaskCreate、Codex: plan）で本ワークフローのタスクを構造化
6. **絶対パス固定**: 元 repo のメモリディレクトリ絶対パスを 05_log.md 冒頭に記録（worktree 運用時の事故防止）

### Phase 1: 要求深掘り

AskUserQuestion で以下を **必ず確定** してから次に進む:

1. **目的・解決したい問題**: なぜ作るのか
2. **対象ユーザー / アクター**: 誰が使うか、誰が影響を受けるか（運用者 / 連携先 / エンドユーザー）
3. **スコープの境界**: やる / やらない を明示。「全件」「全連携先」等は文字通り全件
4. **既存機能との関係**: 新規 / 拡張 / 置換 / 共存
5. **制約**: スケジュール、依存サービス、法的制約、運用制約
6. **成果物の保存先**: デフォルトは `${MEMORY_DIR}/memory/YYMMDD_<context_name>/`、指定があれば従う
7. **Phase 1 既知バグの取り込み有無**: 機能追加と同時に既知バグを修正するか

依頼文から一意に読み取れる項目は、推定した内容を明示した上で進めてよい。実際に解釈が分岐しうる項目（スコープ境界・対外影響・スケジュール・金額）のみ AskUserQuestion で確定する。

質問の粒度・テンプレート: @references/workflow-detail.md §「Phase 1 質問テンプレート」

### Phase 2: 既存実装調査（SSoT 確認）

調査観点:
- 対象機能に関連する既存コードの場所・パターン
- データモデル（DB スキーマ、Domain 型）
- 既存 API / Usecase / Service / Repository / Adapter
- 既存ガード・エラーパターン
- 命名規約・テンプレート・規約同意・通知メールの既存実装
- Cloud Task / Scheduler / Webhook の関連エンドポイント
- 影響範囲（同類画面・同類 procedure）

調査手段:
- **Explore agent を並列 3-5 で起動**してファイル/関数のリストアップ（**経路は Agent tool**: `Explore` は書き込み不可で調査結果を返すだけなので、委譲の既定である herdr pane に当たらない。@context/herdr-delegation.md「経路の選択」）
- **重要箇所は Read で直接確認する**（agent の判定をそのまま信じない）
- context7 / WebSearch で公式仕様確認（必須）
- 発見は `05_log.md` に逐次記録

並列調査パターン: @references/workflow-detail.md §「Phase 2 並列調査パターン」

### Phase 3: 01 ドラフト作成

実装可能な粒度で What + How を書く。章構成はプロジェクト次第で調整可。

詳細テンプレート: @references/doc-templates.md §「01 実装マスタ」

#### 並列化（ユーザー指示時のみ）

ユーザーが `ultracode` の語を使った、または並列化を明示的に指示した場合のみ Workflow で章別並列ドラフト → 統合する。自己判断（「大規模だから」等）では起動しない。並列パターン: @references/workflow-detail.md §「並列化」

### Phase 4: agent review ループ

@context/agent-cli-guide.md に従う:

1. 初回: codex CLI（fallback: cursor agent → fable subagent）で 01 をレビュー
2. Severity 別判断:
   - Action Required → 必ず修正
   - Recommended → 必要性で判断、スキップ時は理由を 05_log.md に記録
   - Minor → スタイル差は許容
3. `--resume <session_id>` で 2 回目以降継続
4. 打ち切り条件:
   - Action Required = 0
   - 同一指摘 2R 連続
   - 安全上限 5R

実コードでの裏取り: agent の指摘も鵜呑みにせず、修正前に Read で事実確認。`Phase 2 で追加する内容を「現状無いから差異」と誤判定する`パターンに注意。

### Phase 5: 02 抽出 + 完了報告

#### 02 抽出ルール

01 から **What のみ** を抽出して `02_system_requirements.md` を書く。

| 書く | 書かない |
|------|---------|
| 機能の存在・挙動・入出力 | クラス名・関数名・ファイルパス・行番号 |
| 状態遷移・分岐条件 | Usecase / Service / Repository / Adapter の構造 |
| API レスポンス・scope / claim 名 | DB のテーブル名・カラム名（最小限可、ただし極力避ける） |
| 画面遷移の概要 | Procedure / queue key / DI 構造 |
| エラーコード（仕様レベル） | エラーメッセージキー・ステータスマッピング詳細 |
| Why は注記程度（1-2 行、「※」「→」） | Why の詳細な設計理由 |

形式: 既存フェーズのシステム要件書と同等（章番号 + 箇条書き多用 + サブセクション X.Y / X.Y.Z + 表は最小限）。テンプレ: @references/doc-templates.md §「02 システム要件書」

#### 完了報告

1. 作成ファイルのフルパス
2. 主要設計判断のサマリ
3. agent review ループの結果（Round 数・Action Required 件数）
4. 残課題（あれば。ただし「要調査」は禁止 — 残課題は具体的に書く）

## 既存スキルとの違い

| スキル | 役割 | 本スキルとの関係 |
|--------|------|---|
| `/large-task` | 大規模タスクの実装分割（Phase 3-5） | 本スキルが上流（設計）、`/large-task` が下流（実装） |
| `/codebase-review` | 既存コードの 6 観点並列レビュー | Phase 2 で部分的に活用可。本スキルは新機能設計が主目的 |
| `/doc-review` | 既存ドキュメントのレビュー | 本スキルは新規作成。レビューは agent review CLI で代替 |
| `/ukwhatn-writing` | 文体スキル | 本スキルはこれを内部で遵守 |
| `/project-init` | プロジェクト初期化 | プロジェクト立ち上げ時。本スキルは機能単位 |

## 詳細参照

- @references/workflow-detail.md — Phase 別の具体手順、質問テンプレ、並列化パターン
- @references/doc-templates.md — 01 / 02 のテンプレート構造とサンプル
- @references/quality-checklist.md — 禁止フレーズ・整合性チェック・完了基準

## チェックリスト（完了前に確認）

完了基準は @references/quality-checklist.md §「完了基準」に集約（禁止フレーズ・grep 網羅確認・agent review 等の全項目）。