القائمة
コンテキストから要件定義書作成→レビュー→承認までの完全ワークフロー
يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.
اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
يتجاوز الأمر المباشر Prompt المخصّص للمراجعة. افحص المصدر قبل تشغيله.
npx skills add https://github.com/takemo101/compose-workflow --skill req-workflowيبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.
تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى SkillsMP.
استنادا إلى تصنيف SOC المهني
عرض SKILL.md
| name | req-workflow |
| description | コンテキストから要件定義書作成→レビュー→承認までの完全ワークフロー |
コンテキスト情報を入力として、要件定義書を作成し、レビュー・承認までを一貫して行うワークフロー。
$ARGUMENTS
以下の形式で入力を受け付けます：
プロジェクト: [プロジェクト名・概要]
ビジネス: [ビジネス目標・KPI]
ユーザー: [ターゲットユーザー・課題]
技術: [技術制約・既存システム]
メモ: [参照するメモのパス（任意）]
入力例:
プロジェクト: タスク管理システムの新規開発
ビジネス: チーム生産性向上、進捗可視化
ユーザー: 開発チーム、プロジェクトマネージャー
技術: Next.js、既存の認証基盤と連携必須
メモ: docs/memos/task-management-idea.md
簡易入力（プロジェクト概要のみ）:
ユーザー管理機能を持つWebアプリケーションを作りたい
| Phase | 名称 | 内容 |
|---|---|---|
| 0 | コンテキスト収集 | 入力解析、メモ読み込み、既存ドキュメント確認 |
| 0.3 | ヒアリング提案 | 情報不足時の確認事項リスト生成【条件付き】 |
| 0.5 | 既存要件整合性確認 | 既存要件定義書との整合性チェック（追加仕様時） |
| 1 | 要件定義書作成 | ``req-writer skill による作成 |
| 2 | レビューループ | ``req-reviewer skill によるレビュー（8点以上、最大5回） |
| 2.5 | ユーザー承認 | approval-gate skill |
| 3 | 成果物サマリー | 完了報告、次ステップ提示 |
Phase規約:
workflow-phase-conventionskill を参照
| 条件 | アクション |
|---|---|
| メモ不在 | 入力情報のみで続行 |
| 入力不足 | Phase 0.3 ヒアリング提案を実行 |
| 5回ループ後も8点未満 | 現状の問題点をまとめて報告、手動修正を推奨 |
入力から参照先を解析し、必要な情報を収集
実行内容:
docs/memos/ ディレクトリを自動チェックdocs/requirements/ の既存要件定義書を確認収集する情報:
| カテゴリ | 収集内容 |
|---|---|
| ビジネス | 目的、ゴール、KPI、予算、スケジュール |
| ユーザー | ペルソナ、課題、ニーズ、利用シーン |
| 技術 | 技術スタック、制約、既存システム |
| 競合 | 競合サービス、差別化ポイント |
| 法規制 | コンプライアンス要件 |
【重要】技術スタック完全性チェック:
以下の技術スタックが定義されているか確認し、未定義の場合は未解決課題として記録する：
| レイヤー | 必須/推奨 | 未定義時のアクション |
|---|---|---|
| フロントエンド | 必須 | 未解決課題に追加（例: I-XXX フロントエンド技術選定） |
| バックエンド | 必須 | 未解決課題に追加 |
| データベース | 必須 | 未解決課題に追加 |
| 認証方式 | 必須 | 未解決課題に追加 |
| インフラ/クラウド | 推奨 | 備考として記載 |
| CI/CD | 推奨 | 備考として記載 |
注意: 技術スタックが未定義の場合、仮定で埋めずに「要選定（I-XXX）」と明記すること。
完了条件:
トリガー: コンテキスト収集後、以下のいずれかに該当する場合
- 必須情報（ビジネス目標/ユーザー/技術制約）が欠落
- 曖昧な表現が多い（「など」「適宜」「必要に応じて」）
- 矛盾する要件が存在
- スコープが広すぎる/不明確
目的: 要件定義の品質を左右する重要情報を事前に収集し、後工程での手戻りを防止する。
実行内容:
情報ギャップ分析:
| カテゴリ | 評価 | チェック項目 |
|---|---|---|
| ビジネス | ✅/⚠️/❌ | 目的明確か、KPI具体的か、予算/スケジュールあるか |
| ユーザー | ✅/⚠️/❌ | ペルソナ特定可能か、課題明確か、利用シーン想定できるか |
| 技術 | ✅/⚠️/❌ | 技術スタック指定あるか、既存システム連携明確か |
| スコープ | ✅/⚠️/❌ | 境界明確か、優先順位あるか、フェーズ分けあるか |
ヒアリング質問リスト生成:
## 確認事項リスト
### 🔴 必須確認（これがないと要件定義の品質が担保できません）
1. [質問内容]
- 背景: なぜこの情報が必要か
- 例: 回答の具体例
### 🟡 推奨確認（あると設計精度が大幅に向上します）
2. [質問内容]
### 🟢 任意確認（Phase 1で仮定を置くことも可能）
3. [質問内容]
質問テンプレート（カテゴリ別）:
| カテゴリ | 必須質問例 |
|---|---|
| ビジネス | 「このプロジェクトの成功指標は何ですか？（例: MAU 1万達成 / 工数50%削減 / 売上10%増）」 |
| ユーザー | 「メインターゲットユーザーは誰ですか？（例: 社内開発チーム / 一般消費者 / 企業の管理者）」 |
| 技術 | 「既存システムとの連携は必要ですか？あれば連携方式の制約を教えてください」 |
| スコープ | 「MVP（最小限の機能）として必須な機能は何ですか？」 |
| 制約 | 「予算・リソース・納期に制約はありますか？」 |
ユーザー選択:
⚠️ 要件定義に必要な情報が不足しています。
**検出された情報ギャップ:**
| カテゴリ | 状態 | 不足情報 |
|---------|------|---------|
| ビジネス | ⚠️ 部分的 | KPI具体値 |
| ユーザー | ❌ 不足 | ペルソナ詳細 |
**対応を選択してください**:
1. ヒアリング実施 → 上記質問への回答を入力
2. 仮定で続行 → 不明点は「未解決課題（I-XXX）」として記録し続行
3. 中断 → 情報収集後に再開
> 番号を選択してください（1-3）:
ユーザー回答と対応:
| 回答 | アクション |
|---|---|
1 | ユーザーの回答を待ち、回答内容をコンテキストに追加して Phase 0.5 へ |
2 | 不足情報を「未解決課題」として記録し、仮定を明記して Phase 0.5 へ |
3 | ワークフロー中断。再開時は収集した情報を入力として再実行 |
スキップ条件:
完了条件:
トリガー:
docs/requirements/に既存の要件定義書が存在する場合
目的: 追加仕様が既存要件と矛盾しないことを確認し、影響範囲を特定する。
実行内容:
既存要件定義書の特定:
docs/requirements/REQ-*.md を検索整合性チェック項目:
| チェック項目 | 確認内容 | 矛盾時のアクション |
|---|---|---|
| 機能ID重複 | 新規F-XXXが既存と重複しないか | 連番を調整 |
| 用語定義 | 同一用語が異なる意味で使われていないか | 用語集を統一 |
| 技術制約 | 既存の技術制約と矛盾しないか | 制約の優先順位を明記 |
| 非機能要件 | パフォーマンス/セキュリティ要件が矛盾しないか | 厳しい方を採用 |
| スコープ境界 | 既存のスコープ外項目と重複しないか | スコープ変更を明記 |
影響分析レポート作成:
## 既存要件との整合性チェック結果
### 関連する既存要件定義書
| ドキュメント | 関連度 | 影響 |
|-------------|--------|------|
| REQ-XXX-001_既存機能.md | 高 | 機能追加 |
### 整合性チェック結果
| 項目 | ステータス | 備考 |
|------|----------|------|
| 機能ID | ✅ OK | F-024から連番開始 |
| 用語定義 | ✅ OK | 既存用語集と整合 |
| 技術制約 | ⚠️ 要確認 | 依存バージョンの確認が必要 |
### 既存要件への影響
- REQ-XXX-001 の機能一覧に追記が必要
- または新規要件定義書 REQ-XXX-002 として独立作成
ユーザー確認（影響がある場合）:
⚠️ 既存要件への影響が検出されました。
**対応方針を選択してください**:
1. 追記 → 既存要件定義書に追記
2. 新規 → 新規要件定義書として作成
3. 中断 → 確認後に再開
> 番号を選択してください（1-3）:
スキップ条件:
docs/requirements/ に既存要件定義書が存在しない（新規プロジェクト）完了条件:
req-writer skill を使用して要件定義書を作成
実行内容:
docs/requirements/REQ-[カテゴリ]-[連番]_[プロジェクト名].md に保存コンテキストの活用:
完了条件:
req-reviewer skill と req-writer skill を使用してレビューと修正を繰り返す
実行内容:
loop (最大5回):
1. req-reviewerでレビュー実行
2. スコアが8点以上なら終了
3. req-writerで問題点を修正
4. ループ継続
完了条件:
Note: 要件定義は最大5回リトライ（設計/実装の3回より多い）
理由: 要件定義は後工程の土台となるため、ここでの品質確保が最重要。 ステークホルダーとの認識齟齬を解消するために、より多くの修正機会を確保。 また、要件の曖昧さは設計・実装フェーズで増幅されるため、 初期段階での徹底的な精査が全体コストを削減する。
共通仕様・出力形式:
approval-gateskill を参照
| 項目 | 値 |
|---|---|
| ドキュメント種別 | 要件定義書 |
| 合格基準 | 8点以上 |
| 次のアクション | 成果物サマリー出力 → 基本設計へ |
重要: ユーザーからの明示的な応答があるまで次のフェーズに進んではならない。
レビュー合格後、成果物をまとめて報告
実行内容:
共通仕様・出力形式:
approval-gateskill の「ワークフロー完了後の次ステップ選択」を参照
| 項目 | 値 |
|---|---|
| ワークフロー名 | 要件定義 |
| 次ワークフロー | /basic-design-workflow |
## ワークフロー完了報告
### 実行サマリー
| フェーズ | ステータス | 詳細 |
|---------|-----------|------|
| コンテキスト収集 | 完了 | X件の情報源を参照 |
| 要件定義書作成 | 完了 | [ファイルパス] |
| レビューループ | 完了 | X回実行, 最終スコア: X/10 |
### 収集したコンテキスト
| 種類 | ソース | 主な内容 |
|------|--------|---------|
| ビジネス | 入力情報 | [概要] |
| ユーザー | 入力情報 | [概要] |
| メモ | docs/memos/xxx.md | [概要] |
### 成果物
#### 要件定義書
- パス: docs/requirements/REQ-XXX-001_xxx.md
- 最終スコア: X/10点
#### 機能一覧
| ID | 機能名 | 優先度 | フェーズ |
|----|--------|--------|---------|
| F-001 | [機能名] | 必須 | Phase 1 |
| F-002 | [機能名] | 重要 | Phase 1 |
### レビュースコア推移
| 回 | スコア | 主な改善点 |
|----|--------|-----------|
| 1 | X/10 | ... |
| 2 | X/10 | ... |
### 未解決課題
| ID | 課題 | 対応方針 |
|----|------|---------|
| I-001 | [課題] | [方針] |
---
## エラーハンドリング
- **フェーズ0失敗**: メモが見つからない場合は入力情報のみで続行
- **フェーズ1失敗**: 入力情報の不足を報告し、追加情報を要求
- **フェーズ2で5回ループ後も8点未満**: 現状の問題点をまとめて報告、手動修正を推奨
## 全体フロー図
[入力] コンテキスト情報
↓
[Phase 0] コンテキスト収集
├── メモ読み込み
├── 既存ドキュメント確認
└── プロジェクト構成把握
↓
[Phase 0.3] ヒアリング提案 ★入力不足時
├── 情報ギャップ分析
├── 確認事項リスト生成
└── ⏸️ ヒアリング/仮定で続行/中断 を選択
↓ (情報十分 or ヒアリング完了)
[Phase 0.5] 既存要件との整合性確認 ★追加仕様時
├── 関連要件定義書の特定
├── 整合性チェック（機能ID/用語/技術制約）
├── 影響分析レポート作成
└── ⏸️ 追記/新規/中断 を選択
↓
[Phase 1] 要件定義書作成
└── req-writer skill
↓
[Phase 2] レビュー・修正ループ
├── req-reviewer skill → スコア判定
└── req-writer skill → 修正
↓ (8点以上)
[Phase 2.5] ユーザー承認ゲート
└── ⏸️ 続行/修正/中断 を待機
↓ (続行)
[Phase 3] 成果物サマリー
↓
[Phase 3.5] 次ステップ選択 ★NEW
└── ⏸️ 1.基本設計へ / 2.修正 / 3.終了 を選択
↓ (1を選択)
[自動実行] /basic-design-workflow "{成果物パス}"
---
## 参考スキル
| スキル | 用途 |
|--------|------|
| `approval-gate` skill | ユーザー承認ゲート |
| `workflow-phase-convention` skill | Phase命名規約 |