Smithery is now a part of Arcade.dev! Read more in our announcement here
Deep-dive specification planner. Interviews you thoroughly about new features, refactoring, or any work requiring planning...
An in-depth interviewing and specification writing skill that helps you think through features, refactoring, and architectural decisions before implementation.
Activate when user:
Do NOT activate for:
Interview First, Write Second: Your primary job is to extract information from the user's head through thoughtful questioning. The spec document is a byproduct of thorough understanding.
No Obvious Questions: Never ask questions the user could answer by reading basic documentation. Focus on edge cases, tradeoffs, UX nuances, and non-obvious implementation concerns.
Continuous Until Complete: Keep interviewing until you've covered all aspects. Don't stop after one round of questions.
Use AskUserQuestion tool repeatedly to probe deeply. Structure your questions across these dimensions:
Consult references/interview-questions.md for the full question bank. Cover these dimensions:
After initial deep-dive:
Only after thorough interviewing, write the specification:
Location: Store specs in docs/prds/ using kebab-case naming (e.g., transaction-bulk-edit.md)
Structure:
Keep it Actionable: Write for an engineer who needs to implement this. Be specific, not vague.
Batch Questions Wisely: Use AskUserQuestion to present 3-4 related questions at once, not one at a time (avoids fatigue) but not too many (avoids overwhelm).
Build on Answers: Each round of questions should be informed by previous answers. Don't use a generic checklist.
Challenge Assumptions: If the user says "it should just work like X", probe what "just work" means in edge cases.
Suggest Alternatives: When appropriate, present options with tradeoffs rather than just asking open-ended questions.
Know When to Stop: Stop interviewing when:
Don't Assume: Never fill in gaps with assumptions. If something is unclear, ask.
Instead of: "What should the button do?" Ask: "When the user clicks submit and the network request fails mid-way, should we: (a) show an error and let them retry, (b) automatically retry N times silently, or (c) save as draft and notify them later?"
Instead of: "How should errors work?" Ask: "If the external API returns a 429 rate limit error during bulk import of 100 items where 47 have already succeeded, should we: (a) fail the entire operation and rollback, (b) pause and retry after the rate limit window, or (c) mark partial success and let user resume?"
Instead of: "What's the UI?" Ask: "When showing the list of 500+ items, should we: (a) paginate with explicit page numbers, (b) infinite scroll with virtualization, or (c) load-more button? Consider that users mentioned they often need to jump to specific items."
User says: "I want to plan a recurring transactions feature" Actions:
docs/prds/recurring-transactions.md
Result: Detailed spec covering technical design, edge cases, UI/UX, and implementation notesUser says: "Let's plan the migration from REST to tRPC" Actions:
Cause: Questions are too open-ended or user hasn't thought through details yet Solution: Offer concrete options with tradeoffs instead of open-ended questions. Use the "Instead of X, ask Y" patterns.
Cause: Too many dimensions explored at once Solution: Prioritize dimensions most relevant to the feature. Skip Security/Privacy for internal-only features, skip UI/UX for pure backend work.
