Normalizes ambiguous GitHub issues into structured requirements, scopes, and checklists to streamline planning.
Install
mkdir -p .claude/skills/issue-to-requirement && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/15325" && unzip -o skill.zip -d .claude/skills/issue-to-requirement && rm skill.zipInstalls to .claude/skills/issue-to-requirement
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
GitHub Issue の曖昧な要求を、このプロジェクトで実装可能な要件へ正規化する。機能分類、層別要件、実装スコープ、判定待ち項目を整理し、issue-to-plan へ渡す。Key capabilities
- →Normalize ambiguous GitHub Issue requirements into implementable requirements
- →Classify issues into categories like new search conditions or UI/UX improvement
- →Organize requirements by architectural layer (front, API, service, client, test)
- →Define implementation scope, including files to add or change
- →Identify non-goals and pending decisions
How it works
The skill parses natural language requirements from GitHub Issues, classifies them, and organizes them by architectural layer. It defines implementation scope, identifies non-goals, and extracts pending decisions for subsequent planning.
Inputs & outputs
When to use issue-to-requirement
- →Formalizing vague feature requests
- →Preparing tasks for project planning
- →Defining implementation scope for new features
About this skill
Issue To Requirement
目的
- Issue の自然言語要求を、実装可能な要件に落とし込む。
- 異なる種類の Issue でも共通フォーマットで整理する。
- 後続の
issue-to-planが判断チェックリストを作れる入力を作る。
この skill を使う条件
- GitHub Issue URL または Issue 本文を渡されたとき。
- 要求が抽象的で、実装範囲が不明確なとき。
出力フォーマット
以下の見出しを必ず出力する。
Issue の要約Issue 分類層別要件実装スコープ概要非ゴール判定待ち項目次アクション
追質問ルール（必須）
- 追質問は最大 4 項目までに制限する。
- 1 項目につき 1 決定のみを問う（複数決定を 1 問に混ぜない）。
判定待ち項目は次の形式で出力する。ID: 例Q-1質問: 1 文選択肢: 2-4 個未回答時の仮置き案: 1 つ
Issue 分類ルール
Issue は次のいずれかに分類する。
- 新規検索条件追加型
- UI/UX 改善型
- API 仕様リファクタリング型
- 非機能改善型
分類が曖昧な場合は第1候補と第2候補を提示する。
層別要件の抽出ルール
次の層ごとに「追加 / 変更 / 新規」の観点で要件を整理する。
- フロント層:
src/app/_components,src/app/page.tsx - API 層:
src/app/api/**/route.ts - Service 層:
src/lib/server/*_service.ts - Client 層:
src/lib/server/*_api_client.ts - テスト層:
src/lib/server/__tests__,src/app/api/**/__tests__
要件が存在しない層は「変更なし」と明記する。
実装スコープ概要の作り方
実装候補を以下の粒度でまとめる。
- 追加するファイル
- 変更するファイル
- 既存拡張で済むか、新規モジュールが必要か
- 影響する API contract
非ゴールの作り方
Issue 本文に含まれていない大型テーマを除外対象として明記する。
例:
- 地図 UI の全面リデザイン
- 本格キャッシュ戦略の導入
- 別画面の UX 改善
判定待ち項目の作り方
issue-to-plan で意思決定が必要になる項目を抽出する。
例:
- データソースは新規 API か既存 API 拡張か
- endpoint は既存拡張か新規追加か
- 並び順は距離/価格/結合スコアのどれか
Issue 追記用フォーマット（推奨）
別セッションで継続しやすくするため、以下の 5 見出しで出力する。
要件正規化結果設計判断チェックリスト現時点の回答追加で確定が必要な項目次セッション開始プロンプト
外部参照ルール
- 外部記事や他実装は「参考」として扱い、実装コードと説明文は独自に作成する。
- データソースを採用する場合は、利用条件とライセンス確認項目を
判定待ち項目に含める。 - 他者コードの複製を前提とする指示は作らない。
品質基準
- 要件が層別に整理されている。
- 判定待ち項目が次のチェックリスト作成に十分な粒度である。
- 既存アーキテクチャ境界（route 薄く、service 委譲）と矛盾しない。
参照
designdoc.mdsrc/app/api/search/route.tssrc/lib/server/accommodation_search_service.ts
接続
この skill の出力をそのまま issue-to-plan の入力として渡す。
最終的な実装計画は task-orchestration へ委譲する。
When not to use it
- →When the GitHub Issue is already clear and implementable
- →When the task does not involve preparing an issue for planning
- →When external code replication is required
Limitations
- →Requires a GitHub Issue URL or body as input
- →Limits follow-up questions to a maximum of 4 items
- →Treats external articles or implementations only as references
How it compares
This skill transforms vague GitHub Issue descriptions into structured, implementable requirements, providing a clear input for planning, unlike directly attempting to plan from an abstract issue.
Compared to similar skills
issue-to-requirement side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| issue-to-requirement (this skill) | 0 | 4mo | No flags | Intermediate |
| error-handling-guide | 0 | 4mo | No flags | Intermediate |
| dependency-upgrade | 26 | 5mo | Review | Intermediate |
| markdown-to-html | 16 | 6mo | Review | Beginner |
Try saying
Example prompts that trigger this skill in your AI assistant.
You might also like
error-handling-guide
komunite
Design and document a error handling guide with structured process, quality checks, and system integration
dependency-upgrade
wshobson
Manage major dependency version upgrades with compatibility analysis, staged rollout, and comprehensive testing. Use when upgrading framework versions, updating major dependencies, or managing breaking changes in libraries.
markdown-to-html
github
Convert Markdown files to HTML similar to `marked.js`, `pandoc`, `gomarkdown/markdown`, or similar tools; or writing custom script to convert markdown to html and/or working on web template systems like `jekyll/jekyll`, `gohugoio/hugo`, or similar web templating systems that utilize markdown documents, converting them to html. Use when asked to "convert markdown to html", "transform md to html", "render markdown", "generate html from markdown", or when working with .md files and/or web a templating system that converts markdown to HTML output. Supports CLI and Node.js workflows with GFM, CommonMark, and standard Markdown flavors.
run-nx-generator
nrwl
Run Nx generators with prioritization for workspace-plugin generators. Use this when generating code, scaffolding new features, or automating repetitive tasks in the monorepo.
upgrading-expo
sickn33
Upgrade Expo SDK versions
pnpm
antfu
Node.js package manager with strict dependency resolution. Use when running pnpm specific commands, configuring workspaces, or managing dependencies with catalogs, patches, or overrides.