Stats
Actions
Tags
From requirements
Generic project requirements definition through structured iterative dialogue. Clarifies even vague ideas through multiple rounds of deep questioning, then outputs a structured requirements document for AI-driven development.
How this skill is triggered — by the user, by Claude, or both
Slash command
/requirements:requirementsThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
プロジェクトの要件を構造化された反復対話を通じて定義する。
プロジェクトの要件を構造化された反復対話を通じて定義する。 ユーザーの曖昧なアイデアを複数ラウンドの対話で明確にし、AIが開発可能な精度の要件定義書を出力する。
ユーザーの回答が曖昧な場合、以下のテクニックを使い分けて深掘りする：
目的：プロジェクトの存在意義と背景を理解する
質問すべきこと：
深掘りポイント：
目的：プロジェクトの範囲を明確にし、開発対象の境界線を引く
質問すべきこと：
深掘りポイント：
目的：システムが提供すべき具体的な機能を定義する
質問すべきこと：
各機能について以下を明確にする：
深掘りポイント：
目的：システムの品質特性を定義する
プロジェクトに関連するものについて確認する：
深掘りポイント：
目的：全フェーズの結果を横断的にレビューし、矛盾と漏れを解消する
実施すること：
目的：要件定義書の最終確認と出力
実施すること：
{project-name}/docs/requirements/index.md を作成する（プロジェクトディレクトリ・docsフォルダ・requirementsフォルダも同時に作成する）docs/requirements/index.md を作成する（docsフォルダ・requirementsフォルダが存在しない場合は作成する）index.mdに対する追加機能など）: docs/requirements/{feature-name}.md として出力するstatus を available に更新するreviewed を記録するrelated に ./ から始まる相対パスを記載する（例: ./auth.md）最終承認後、Phase 6 の出力ルールに従いMarkdownファイルを生成する。
{project-name}/ ← 新規プロジェクトの場合のみ作成
docs/
requirements/
index.md ← 基本要件（このスキルが生成する）
auth.md ← 追加要件の例（feature名で命名）
payment.md ← 追加要件の例
出力する要件定義書には必ず以下のfrontmatterを付与する：
---
status: draft # draft | available | in-progress | closed
reviewed: # レビュー済みの場合: "YYYY-MM-DD by @reviewer"
related: # 関連する要件定義書への相対パスリスト
- ./auth.md
---
| フィールド | 必須 | 説明 |
|---|---|---|
status | Yes | 要件定義書のライフサイクル状態。初回出力時は draft とする |
reviewed | No | レビュー完了時に YYYY-MM-DD by @レビュアー名 の形式で記録する。未レビューの場合は空欄 |
related | No | 関連する要件定義書への相対パス（./から始まる）をリストで記載する |
draft → available → in-progress → closed
draft を設定するavailable に更新するin-progress / closed への遷移はユーザーが手動で、または別のスキル・ワークフローから更新する---
status: available
reviewed:
related: []
---
# {プロジェクト名} 要件定義書
## 1. プロジェクト概要
### 背景と課題
{現状の課題、プロジェクトの背景}
### 目的
{プロジェクトの目的。なぜこのプロジェクトが必要なのか}
### 成功基準
{プロジェクトが成功したと判断できる具体的な基準}
### 想定ユーザー
{このシステムを利用するユーザー像}
## 2. スコープ
### 実現すること
- {スコープ内の項目}
### 実現しないこと
- {スコープ外の項目}
### 将来的な拡張候補
- {今回は含めないが将来実装する可能性のある項目}
## 3. 機能要件
| カテゴリー | 必須/希望 | 優先度 | 機能概要 | 要求内容 |
| --- | --- | --- | --- | --- |
| {category} | {必須/希望} | {高/中/低} | {summary} | {detail} |
### 各機能の詳細
#### {機能名}
- **ユーザーストーリー**: {〜として、〜したい。なぜなら〜}
- **入力**: {input}
- **出力**: {output}
- **主要フロー**: {happy path}
- **エッジケース**: {edge cases}
## 4. 非機能要件
| カテゴリー | 要件 | 具体的な基準 |
| --- | --- | --- |
| {category} | {requirement} | {measurable criteria} |
## 5. 前提条件と制約
- {前提条件や技術的制約}
## 6. 用語集
| 用語 | 定義 |
| --- | --- |
| {term} | {definition} |
要件定義完了後の次のステップをユーザーに案内する：
Option A: レビューしてから実装計画へ
docs/requirements/index.md をレビューしてもらうreviewed フィールドに YYYY-MM-DD by @レビュアー名 を記録するwriting-plans スキルで実装計画を策定するOption B: そのまま実装計画へ
writing-plans スキルで要件に基づいた実装計画を策定するdocs/requirements/index.md) を渡して計画策定を開始するFetches up-to-date documentation from Context7 for libraries and frameworks like React, Next.js, Prisma. Use for setup questions, API references, and code examples.
Applies a firm's KYC/AML rules grid to parsed onboarding records: assigns risk rating, checks required documents, outputs rule outcomes with citations, and routes for escalation.
Generates daily or weekly digests of activity from connected sources (chat, email, docs, tasks, CRM), highlighting action items, decisions, mentions, and project updates.
npx claudepluginhub 555takakusaki/requirements-plugin --plugin requirements