Best use case
create-requirements is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
ヒアリングしながら作りたい機能の要件定義を確定する
Teams using create-requirements should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/create-requirements/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How create-requirements Compares
| Feature / Agent | create-requirements | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
ヒアリングしながら作りたい機能の要件定義を確定する
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
## あなたの役割
わたしにヒアリングしながら作りたい機能の要件定義を確定してください。事実確認と利用者価値に集中して要件定義していきます。
## 制約（最重要）
- この段階では技術的設計・実装詳細・アーキテクチャ・データ構造・API仕様・ライブラリ選定を**一切**検討しない。要件を整理するためにこちらから実装について聞いた時だけチャットで教えるだけで、最終的な要件定義書には含めない
- 実現方法の示唆（例: 「〜で実装できる」「〜を使う」）は禁止
- 出力は**要件のみ**。検討すべき事項は「Open Questions」に入れる
## 要件定義したい内容
$1
に基づいて要件定義を行ってください。
## 手順
1) 作りたい機能の概要を理解し、その文脈を把握するために現在のコードベースを調査する
2) 不足情報を最大3問だけ質問する（Yes/No or 選択式を優先）
- もしYes/No or 選択式の場合、AskUserQuestionツールを活用
3) こちらが「十分」と言うか、あなたが十分だと判断するまで、質問を繰り返す
4) 要件定義書を返答、もしくはプランファイルとしてMarkdown形式で作る。以下を必ず含める
- Context / Goal
- In scope / Out of scope
- User stories（3〜7個）
- Acceptance Criteria（Gherkinで主要3本＋例外2本）
- NFR（性能/コスト/セキュリティ/監査/運用）
- Open Questions（未確定事項）Related Skills
my-create-draft-pull-request
GitHubのDraft PullRequestを作成する
create-implement-plan
要件定義書から実装計画（フェーズ分解・commit分解）を作成する
subagent-commit
git-commit-message-generatorエージェントを利用して、commitメッセージを生成する
self-review
手元のコードをreviewerエージェントでセルフレビューし、指摘に基づいて自動修正するループ
search-loosedrawing
Loose Drawingから画像を検索、または表現に適したイラストの組み合わせを提案する
search-irasutoya
いらすとやから画像を検索、または表現に適したイラストの組み合わせを提案する
search-cluster-creators-guide
Cluster Creators Guide（creator.cluster.mu）からクリエイター向け情報を検索・調査する。 「clusterの〜について調べて」「〜の使い方」「〜する方法」「〜を探して」などのリクエストで使用。 Bashでスクリプトを実行してサイト検索・記事取得を行い、関連情報を抽出して提示する。
review-current-branch
シニアソフトウェアエンジニアとして現在のブランチのプルリクエストをレビューする
reply-fix-to-review-comments
GitHub PR のレビューコメント（インライン）に対し、直前の会話で対応した commit を紐付けて「<commit URL> で修正しました」という Reply をまとめて投稿する。「レビュー Reply して」「レビューコメントに返信して」「修正報告投稿して」などのリクエストで使用。コード修正そのものは扱わず、修正・commit 済みの状態から呼ぶ前提。
memo-tech
現在のセッションから汎用知識のみを抽出し、話題ごとに自動タイトルで分割・保存（Obsidian直下、引数不要）
implement-handoff
実装計画に従って作業後、次のフェーズ担当者への申し送り事項を作成する
fix-review-comments
直前の会話に含まれるレビュー結果を精査し、妥当な指摘に対して修正を実施する。レビュアーの指摘がすべて正しいとは限らないため、各コメントを批判的に評価する。「レビュー対応して」「レビューコメント修正して」「指摘を直して」「レビュー指摘に対応して」などのリクエストで使用。