From claude-reliability
Guides collaborative requirements gathering for ambiguous requests, unclear scopes, or missing details to understand the underlying problem before coding.
npx claudepluginhub drmaciver/claude-reliability --plugin claude-reliabilityThis skill uses the workspace's default tool permissions.
Use this approach when:
Analyzes ambiguous requests using 5W1H decomposition to surface assumptions and generate up to 3 actionable clarifying questions before execution. Use for non-trivial tasks or multi-interpretable requests.
Elicits detailed user requirements via structured AskUserQuestion interviews confirming goals, scope, constraints, priorities, and success criteria before coding to prevent assumptions.
Analyzes ambiguous task requests using 5W1H decomposition to surface assumptions and generate up to 3 targeted clarifying questions before execution.
Share bugs, ideas, or general feedback.
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.