📦 その他コミュニティ

devdocs-requirements

ユーザーからの機能要望や製品要件を詳細な開発ドキュメントに落とし込み、要件定義やPRD作成を支援することで、開発チームがスムーズに開発を進められるようにするSkill。

📜 元の英語説明(参考)

Expand user requirements into detailed DevDocs documents. Use when users provide feature requirements, want to clarify requirements, or need to create product requirement documents. Triggers on keywords like "requirements", "PRD", "feature request", "user story".

🇯🇵 日本人クリエイター向け解説

一言でいうと

※ jpskill.com 編集部が日本のビジネス現場向けに補足した解説です。Skill本体の挙動とは独立した参考情報です。

⚡ おすすめ: コマンド1行でインストール(60秒)

下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。ダウンロード → 解凍 → 配置まで全自動。

🍎 Mac / 🐧 Linux

mkdir -p ~/.claude/skills && cd ~/.claude/skills && curl -L -o devdocs-requirements.zip https://jpskill.com/download/8774.zip && unzip -o devdocs-requirements.zip && rm devdocs-requirements.zip

🪟 Windows (PowerShell)

$d = "$env:USERPROFILE\.claude\skills"; ni -Force -ItemType Directory $d | Out-Null; iwr https://jpskill.com/download/8774.zip -OutFile "$d\devdocs-requirements.zip"; Expand-Archive "$d\devdocs-requirements.zip" -DestinationPath $d -Force; ri "$d\devdocs-requirements.zip"

完了後、Claude Code を再起動 → 普通に「動画プロンプト作って」のように話しかけるだけで自動発動します。

💾 手動でダウンロードしたい(コマンドが難しい人向け)

1. 下の青いボタンを押して devdocs-requirements.zip をダウンロード
2. ZIPファイルをダブルクリックで解凍 → devdocs-requirements フォルダができる
3. そのフォルダを C:\Users\あなたの名前\.claude\skills\(Win)または ~/.claude/skills/(Mac)へ移動
4. Claude Code を再起動

⬇ .zip でダウンロード(推奨) ⬇ .skill 形式(上級者用) 元のソース ↗

⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。

🎯 このSkillでできること

下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。

📦 インストール方法 (3ステップ)

1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
3. 展開してできたフォルダを、ホームフォルダの .claude/skills/ に置く
- · macOS / Linux: ~/.claude/skills/
- · Windows: %USERPROFILE%\.claude\skills\

Claude Code を再起動すれば完了。「このSkillを使って…」と話しかけなくても、関連する依頼で自動的に呼び出されます。

詳しい使い方ガイドを見る →

最終更新: 2026-05-18
取得日時: 2026-05-18
同梱ファイル: 1

📖 Skill本文(日本語訳)

※ 原文(英語/中国語)を Gemini で日本語化したものです。Claude 自身は原文を読みます。誤訳がある場合は原文をご確認ください。

需求拡写

ユーザーの簡潔な要求を構造化された要求ドキュメントに拡張し、機能点、ユーザーストーリー、受け入れ基準の関連体系を構築します。

言語規則

中国語と英語での質問をサポート
中国語での統一された回答
中国語を使用してドキュメントを生成

起動条件

ユーザーが機能要求またはアイデアを提供する
ユーザーが PRD の作成/記述を要求する
ユーザーが要求を明確化または記録したい
/devdocs-feature からの増分要求委託

実行モード

/devdocs-requirements              → 自動検出モード
/devdocs-requirements --incremental → 強制増分モード

モード	起動条件	説明
初期モード	`01-requirements.md` がない	要求ドキュメントをゼロから作成
増分モード	`01-requirements.md` が存在する	番号をスキャン + 要求を追加

ワークフロー

初期モード

1. 要求を理解する
   │
   ▼
2. コードベースを探索する（該当する場合）
   │
   ▼
3. 機能点 (F-XXX) を識別する
   │
   ▼
4. ユーザー ストーリー (US-XXX) を記述する
   │
   ▼
5. 受け入れ基準 (AC-XXX) を定義する
   │
   ▼
6. 追跡マトリックスを生成する
   │
   ▼
7. ユーザー確認

増分モード

1. 既存の番号をスキャンする
   │
   ├── 01-requirements.md を読み取る
   └── F/US/AC の最大番号を取得する
   │
   ▼
2. 新規要求を理解する
   │
   ▼
3. 機能点/ユーザー ストーリー/受け入れ基準を追加する
   │
   ├── 既存の番号を継続する
   └── 増分バージョンと日付を注釈する
   │
   ▼
4. 追跡マトリックスを更新する
   │
   ▼
5. ユーザー確認
   │
   ▼
6. 新規番号リストを返す（呼び出し元で使用するため）

番号規則

タイプ	プレフィックス	フォーマット	例
機能点	F	F-XXX	F-001, F-002
ユーザーストーリー	US	US-XXX	US-001, US-002
受け入れ基準	AC	AC-XXX	AC-001, AC-002

番号規則：

グローバルな順序番号、ネストなし
追跡マトリックスを通じて関連関係を表現
一度割り当てられた番号は再利用不可

出力ファイル

メインファイル：docs/devdocs/01-requirements.md

ドキュメントが 300 行を超える場合は、以下に分割できます。

01-requirements.md - 概要と機能点
01-requirements-stories.md - ユーザーストーリーの詳細
01-requirements-nfr.md - 非機能要件

詳細なテンプレートについては、templates/requirements-template.md を参照してください。

ドキュメント構造

# 要求ドキュメント：<機能名称>

## 1. 背景と目標
## 2. 機能点リスト
## 3. ユーザー ストーリー
## 4. 受け入れ基準
## 5. 追跡マトリックス
## 6. 非機能要件
## 7. 範囲境界
## 8. リスクと仮定

コアコンセプト

機能点 (Feature)

機能点は、ユーザーが認識できる独立した機能ユニットです。

識別方法：

独立して提供および検証できる
ユーザーにとって明確な価値がある
粒度が適切（大きすぎず小さすぎず）

例：

| 编号 | 功能点 | 描述 | 优先级 |
|------|--------|------|--------|
| F-001 | ユーザー登録 | 新規ユーザーがメールアドレスでアカウントを登録する | P0 |
| F-002 | ユーザーログイン | 登録済みユーザーがシステムにログインする | P0 |
| F-003 | パスワード再設定 | ユーザーがメールアドレスでパスワードをリセットする | P1 |

ユーザーストーリー (User Story)

ユーザーストーリーは、ユーザーが機能点を使用して目標を達成する方法を記述します。

フォーマット：<役割> として、<機能> を希望します。それは <価値> を得るためです。

例：

| 编号 | 功能点 | 角色 | 期望 | 目的 |
|------|--------|------|------|------|
| US-001 | F-001 | 新規ユーザー | メールアドレスを使用して登録する | システムへのアクセス権を取得する |
| US-002 | F-001 | 新規ユーザー | 安全なパスワードを設定する | アカウントのセキュリティを保護する |
| US-003 | F-002 | 登録済みユーザー | メールアドレスとパスワードを使用してログインする | システムに入る |

受け入れ基準 (Acceptance Criteria)

受け入れ基準は、ユーザーストーリーの完了条件を定義し、テストケース設計の基礎となります。

原則：

定量化可能、検証可能
実装ではなく、予想される動作を記述する
各ユーザーストーリーに少なくとも 2〜3 個の受け入れ基準

例：

### US-001: メールアドレスを使用して登録する

| 编号 | 标准描述 | 验证方式 |
|------|----------|----------|
| AC-001 | 有効なメールアドレス形式で登録を送信できる | test@example.com を入力し、送信に成功する |
| AC-002 | 既存のメールアドレスはエラーメッセージを表示する | 登録済みのメールアドレスを入力し、「メールアドレスはすでに存在します」と表示する |
| AC-003 | 登録が成功すると、確認メールが送信される | 確認リンクを含むメールを受信する |

追跡マトリックス

追跡マトリックスは、機能点、ユーザーストーリー、受け入れ基準の関連関係を示します。

例：

| 功能点 | 用户故事 | 验收标准 |
|--------|----------|----------|
| F-001 | US-001 | AC-001, AC-002, AC-003 |
| F-001 | US-002 | AC-004, AC-005 |
| F-002 | US-003 | AC-006, AC-007, AC-008 |

増分モード詳細

番号スキャン

既存のドキュメントから最大番号を抽出します。

## 当前状态

| 类型 | 当前最大编号 | 下一编号 |
|------|-------------|----------|
| 機能点 (F) | F-003 | F-004 |
| ユーザー ストーリー (US) | US-008 | US-009 |
| 受け入れ基準 (AC) | AC-015 | AC-016 |

追加フォーマット

---

## 機能イテレーション v2: <機能名称> (2024-01-15)

> 今回は F-004 を追加し、2 つのユーザー ストーリー、5 つの受け入れ基準が含まれます。

### F-004: <機能名称>

**説明**：<機能説明>

**ユーザー ストーリー**：

| 编号 | 角色 | 期望 | 目的 |
|------|------|------|------|
| US-009 | <役割> として | <機能> を希望します | <価値> を得るためです |

**受け入れ基準**：

- [ ] AC-016: <標準1>
- [ ] AC-017: <標準2>

戻り値

増分モードが完了したら、呼び出し元が使用できるように、新しい番号のリストを返します。

新增编号：
- F-004
- US-009, US-010
- AC-016 ~ AC-020

制約

機能点の制約

[ ] 各機能点には一意の番号 (F-XXX) が必要です
[ ] 機能点には優先度 (P0/P1/P2) を注釈する必要があります
[ ] 機能点の記述は簡潔かつ明確である必要があります

ユーザーストーリーの制約

[ ] 各ユーザーストーリーは機能点に関連付けられている必要があります
[ ] 「...として、...を希望します、...のために」の形式に従う必要があります
[ ] 各機能点には少なくとも 1 つのユーザーストーリーが必要です

受け入れ基準の制約

[ ] 各受け入れ基準には一意の番号 (AC-XXX) が必要です
[ ] 各ユーザーストーリーには少なくとも 2 つの受け入れ基準が必要です
[ ] 受け入れ基準は定量化可能で検証可能である必要があります
[ ] 検証方法を記述する必要があります

追跡の制約

[ ] 追跡マトリックスを提供する必要があります
[ ] すべての機能点に対応するユーザーストーリーが必要です
[ ] すべてのユーザーストーリーに対応する受け入れ基準が必要です

増分モードの制約

[ ] 最初に既存の番号をスキャンし、番号を継続する必要があります
[ ] 追加されたコンテンツには、増分バージョンと日付を注釈する必要があります
[ ] 既存のコンテンツを削除または上書きしてはなりません
[ ] 完了後、新しい番号のリストを返す必要があります

確認の制約

[ ] 機能点が完全であるかどうかをユーザーに確認する必要があります
[ ] ユーザーが言及しておらず、確認されていない機能を追加してはなりません

Skill 連携

场景	协作 Skill	说明
新規機能要求	`/devdocs-feature`	呼び出される：新機能が要求の追加をトリガーする
洞察の変換	`/devdocs-insights`	呼び出される：改善提案が要求に変換される
バグによる要求の露呈	`/devdocs-bugfix`	呼び出される：バグ修正により要求の欠落が発見される
プロジェクトの改造	`/devdocs-retrofit`	呼び出される：リバースエンジニアリングにより要求が生成される
設計段階	`/devdocs-system-design`	後続：要求の確認後、設計に入る

次のステップ

完了後、/devdocs-system-design を実行してシステム設計を行うことをお勧めします。

📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開

需求扩写

将用户简短需求扩展为结构化的需求文档，建立功能点、用户故事、验收标准的关联体系。

语言规则

支持中英文提问
统一中文回复
使用中文生成文档

触发条件

用户提供功能需求或想法
用户要求创建/编写 PRD
用户想要澄清或记录需求
来自 /devdocs-feature 的增量需求委托

运行模式

/devdocs-requirements              → 自动检测模式
/devdocs-requirements --incremental → 强制增量模式

模式	触发条件	说明
初始模式	无 `01-requirements.md`	从零创建需求文档
增量模式	已有 `01-requirements.md`	扫描编号 + 追加需求

工作流程

初始模式

1. 理解需求
   │
   ▼
2. 探索代码库（如适用）
   │
   ▼
3. 识别功能点 (F-XXX)
   │
   ▼
4. 编写用户故事 (US-XXX)
   │
   ▼
5. 定义验收标准 (AC-XXX)
   │
   ▼
6. 生成追溯矩阵
   │
   ▼
7. 用户确认

增量模式

1. 扫描现有编号
   │
   ├── 读取 01-requirements.md
   └── 获取 F/US/AC 最大编号
   │
   ▼
2. 理解新增需求
   │
   ▼
3. 追加功能点/用户故事/验收标准
   │
   ├── 延续现有编号
   └── 标注增量版本和日期
   │
   ▼
4. 更新追溯矩阵
   │
   ▼
5. 用户确认
   │
   ▼
6. 返回新增编号列表（供调用方使用）

编号规范

类型	前缀	格式	示例
功能点	F	F-XXX	F-001, F-002
用户故事	US	US-XXX	US-001, US-002
验收标准	AC	AC-XXX	AC-001, AC-002

编号规则：

全局顺序编号，不嵌套
通过追溯矩阵表达关联关系
编号一旦分配不可复用

输出文件

主文件：docs/devdocs/01-requirements.md

如文档超过 300 行，可拆分为：

01-requirements.md - 概览和功能点
01-requirements-stories.md - 用户故事详情
01-requirements-nfr.md - 非功能性需求

详细模板参见 templates/requirements-template.md

文档结构

# 需求文档：<功能名称>

## 1. 背景与目标
## 2. 功能点清单
## 3. 用户故事
## 4. 验收标准
## 5. 追溯矩阵
## 6. 非功能性需求
## 7. 范围边界
## 8. 风险与假设

核心概念

功能点 (Feature)

功能点是用户可感知的独立功能单元。

识别方法：

可以独立交付和验证
对用户有明确价值
粒度适中（不过大也不过小）

示例：

| 编号 | 功能点 | 描述 | 优先级 |
|------|--------|------|--------|
| F-001 | 用户注册 | 新用户通过邮箱注册账号 | P0 |
| F-002 | 用户登录 | 已注册用户登录系统 | P0 |
| F-003 | 密码找回 | 用户通过邮箱重置密码 | P1 |

用户故事 (User Story)

用户故事描述用户如何使用功能点完成目标。

格式：作为 <角色>，我希望 <功能>，以便 <价值>

示例：

| 编号 | 功能点 | 角色 | 期望 | 目的 |
|------|--------|------|------|------|
| US-001 | F-001 | 新用户 | 使用邮箱注册 | 获得系统访问权限 |
| US-002 | F-001 | 新用户 | 设置安全密码 | 保护账号安全 |
| US-003 | F-002 | 已注册用户 | 使用邮箱密码登录 | 进入系统 |

验收标准 (Acceptance Criteria)

验收标准定义用户故事的完成条件，是测试用例设计的依据。

原则：

可量化、可验证
描述预期行为，不描述实现
每个用户故事至少 2-3 条验收标准

示例：

### US-001: 使用邮箱注册

| 编号 | 标准描述 | 验证方式 |
|------|----------|----------|
| AC-001 | 有效邮箱格式可以提交注册 | 输入 test@example.com，提交成功 |
| AC-002 | 已存在邮箱显示错误提示 | 输入已注册邮箱，显示"邮箱已存在" |
| AC-003 | 注册成功后发送验证邮件 | 收到包含验证链接的邮件 |

追溯矩阵

追溯矩阵展示功能点、用户故事、验收标准的关联关系。

示例：

| 功能点 | 用户故事 | 验收标准 |
|--------|----------|----------|
| F-001 | US-001 | AC-001, AC-002, AC-003 |
| F-001 | US-002 | AC-004, AC-005 |
| F-002 | US-003 | AC-006, AC-007, AC-008 |

增量模式详解

编号扫描

从现有文档提取最大编号：

## 当前状态

| 类型 | 当前最大编号 | 下一编号 |
|------|-------------|----------|
| 功能点 (F) | F-003 | F-004 |
| 用户故事 (US) | US-008 | US-009 |
| 验收标准 (AC) | AC-015 | AC-016 |

追加格式

---

## 功能迭代 v2: <功能名称> (2024-01-15)

> 本次新增 F-004，包含 2 个用户故事、5 个验收标准。

### F-004: <功能名称>

**描述**：<功能描述>

**用户故事**：

| 编号 | 角色 | 期望 | 目的 |
|------|------|------|------|
| US-009 | 作为<角色> | 我希望<功能> | 以便于<价值> |

**验收标准**：

- [ ] AC-016: <标准1>
- [ ] AC-017: <标准2>

返回值

增量模式完成后，返回新增编号列表供调用方使用：

新增编号：
- F-004
- US-009, US-010
- AC-016 ~ AC-020

约束

功能点约束

[ ] 每个功能点必须有唯一编号 (F-XXX)
[ ] 功能点必须标注优先级 (P0/P1/P2)
[ ] 功能点描述应简洁明确

用户故事约束

[ ] 每个用户故事必须关联到功能点
[ ] 必须遵循"作为...我希望...以便..."格式
[ ] 每个功能点至少有 1 个用户故事

验收标准约束

[ ] 每个验收标准必须有唯一编号 (AC-XXX)
[ ] 每个用户故事至少有 2 条验收标准
[ ] 验收标准必须可量化、可验证
[ ] 必须描述验证方式

追溯约束

[ ] 必须提供追溯矩阵
[ ] 所有功能点必须有对应的用户故事
[ ] 所有用户故事必须有对应的验收标准

增量模式约束

[ ] 必须先扫描现有编号，延续编号
[ ] 追加内容必须标注增量版本和日期
[ ] 不得删除或覆盖现有内容
[ ] 完成后必须返回新增编号列表

确认约束

[ ] 必须与用户确认功能点是否完整
[ ] 不得添加用户未提及且未确认的功能

Skill 协作

场景	协作 Skill	说明
新功能需求	`/devdocs-feature`	被调用：新功能触发需求追加
洞察转化	`/devdocs-insights`	被调用：改进建议转化为需求
Bug 暴露需求	`/devdocs-bugfix`	被调用：Bug 修复发现需求缺失
项目改造	`/devdocs-retrofit`	被调用：逆向推导生成需求
设计阶段	`/devdocs-system-design`	后续：需求确认后进入设计

下一步

完成后建议运行 /devdocs-system-design 进行系统设计。