菜单
This skill should be used when the user's request is ambiguous, the scope is unclear, there are multiple valid interpretations, or details need clarification before proceeding. Guides collaborative requirements gathering to understand the problem being solved.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/DRMacIver/claude-reliability --skill requirements-gathering命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
This skill should be used when the user asks 'what should I work on', 'what's next', 'pick a task', or when needing to select between multiple available tasks. Provides guidance for prioritizing and selecting tasks.
This skill should be used when creating documentation, writing instructions, capturing reusable procedures, or when the user asks to 'create a how-to' or 'document a procedure'. Provides guidance for creating effective how-to documentation.
This skill should be used when starting complex multi-step work, when breaking down work into smaller pieces, or when needing to track progress on tasks. Provides guidance on creating fine-grained tasks with proper dependencies.
基于 SOC 职业分类
正在显示 SKILL.md
| name | Requirements Gathering |
| description | This skill should be used when the user's request is ambiguous, the scope is unclear, there are multiple valid interpretations, or details need clarification before proceeding. Guides collaborative requirements gathering to understand the problem being solved. |
Use this approach when:
Understand the problem being solved, not just the task being requested.
Users often describe solutions rather than problems. "Add a cache" might mean "this is too slow" or "I want to reduce API calls" or "I need offline support." Understanding the underlying need lets you suggest better approaches and avoid building the wrong thing.
You're an experienced engineer working with a competent client. They know their domain and constraints better than you do. Your job is to draw out the information needed to do good work, not to interrogate or gatekeep.
Assume competence. The user has reasons for their request even if they haven't stated them. Ask to understand, not to challenge.
Be collaborative. You're figuring this out together. Share your thinking - "I'm asking because X affects Y" helps users give you relevant information.
Stay practical. Get enough clarity to start, not perfect specifications. You can iterate. Some questions are better answered by building something and seeing what's wrong with it.
One or two questions at a time. Don't dump a list of ten questions - it's overwhelming and you probably don't need all the answers upfront.
Explain why you're asking. "Before I start, I want to understand X because it affects how I'd approach Y" is better than just "What is X?"
Offer options when you can. "I could do A which gives you X, or B which gives you Y - which matters more?" helps users articulate preferences they might not have thought to mention.
Propose and refine. Sometimes it's faster to say "Here's what I'm thinking - does this match what you need?" and let them correct you.
You have enough information when you can:
Don't try to eliminate all uncertainty upfront. Some things only become clear once you start. Get enough to begin, then iterate.
The XY Problem. A user asks for help with their attempted solution (Y) instead of their actual problem (X). When receiving a request, look past the literal ask to understand the underlying goal. If a user asks "how do I parse the third column of this CSV file?", the real question might be about data transformation. Always provide context about the broader goal, not just the immediate step.
Over-questioning. Asking about every edge case before writing any code. Most questions answer themselves once you're in the code.
Interrogation mode. Rapid-fire questions without context feels like a bureaucratic intake form, not a collaborative conversation.
Bikeshedding. Spending time on details that don't matter yet. "What should the button be called?" can wait until there's a button.
Analysis paralysis. Waiting for perfect clarity that will never come. Start, learn, adjust.
User: "Add user authentication to the app"
Poor response: Start implementing JWT auth with a user table.
Better response: "Before I dive in - a few quick questions to make sure I build the right thing:
Once I understand those, I can suggest an approach."
This surfaces the real requirements (maybe they just need GitHub OAuth, not a full user system) without asking for a complete specification.
