Requirements interview
Skill JochenYang/Jochen-ai-rules/skills/requirements-interview
Conduct deep multi-round requirements interviews to produce executable SPEC, PRD, and PLAN drafts. Use when user says "clarify requirements", "采访需求", "extract requirements", "define scope", "analyze needs", or when requirements are ambiguous and need interactive clarification. Do NOT use when requirements are already complete.From its SKILL.md
npx -y skills add JochenYang/Jochen-ai-rules --skill requirements-interviewAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 20 stars20 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
5.1 KB, as published. Nobody here has run it
Requirements Interview
Run structured, multi-round requirement interviews, then convert answers into actionable documents.
When to Use
Use this skill when:
- Requirements are incomplete, ambiguous, or contradictory.
- The user asks to "clarify requirements" through Q&A.
- You need interview-driven outputs (SPEC/PRD/PLAN), not only a static PRD.
Do not use this skill when:
- The user already provided clear and complete requirements.
- The user only needs a standard PRD summary (use
product-manager).
Inputs
- Existing
SPEC.md(optional) - Existing
PRD.md(optional) - Existing
PLAN.md(optional)
Tool Strategy
Primary: AskUserQuestionTool (or equivalent interactive question tool).
Fallback: If the tool is unavailable, continue with plain conversational questions and keep the same interview structure.
Core Rules
- Ask deep, non-trivial questions (avoid obvious yes/no prompts).
- Minimum 2 rounds of clarification unless user explicitly stops.
- After each round, update assumptions and unresolved items.
- Separate confirmed facts from hypotheses.
- Do not skip final document outputs.
Interview Dimensions (Mandatory)
Cover these areas:
- Business goals and success metrics
- Target users and key scenarios
- Scope boundaries and explicit non-goals
- UX expectations and acceptance criteria
- Technical constraints and integration boundaries
- Security/compliance/performance requirements
- Risks, tradeoffs, and alternatives
- Milestones, priority, and delivery sequence
Workflow
- Read existing
SPEC.md/PRD.md/PLAN.mdif they exist. - Summarize known facts and gaps.
- Run interview round 1 with focused open questions.
- Update SPEC/PRD/PLAN drafts.
- Run interview round 2+ until requirements are actionable.
- Produce final deliverables and a concise uncertainty log.
Outputs
Always provide or update:
SPEC.md: problem definition, scope, constraints, acceptance checksPRD.md: user value, requirements, priorities, success metricsPLAN.md: implementation phases, dependencies, risks, test strategy
Completion Criteria
- Requirements are implementation-ready.
- Key assumptions and tradeoffs are explicit.
- Acceptance criteria are testable.
- Open questions are listed with owner and next action.
Handoff Guidance
If implementation is next:
- handoff to
dev-plannerfor execution planning, or - handoff to
product-managerfor roadmap-level prioritization.
Examples
Example 1: Ambiguous Feature Request
User says: "I want to add user authentication" Actions:
- Ask about auth method (OAuth, password-based, SSO?)
- Clarify user roles and permissions
- Determine session management preferences
- Define password reset and recovery flows Result: Complete auth SPEC.md with acceptance criteria
Example 2: New Project Startup
User says: "Help me define requirements for a CRM system" Actions:
- Identify target users (sales, support, management?)
- Define core workflows (contact management, deals, tasks)
- Clarify integrations (email, calendar, phone)
- Establish success metrics Result: Full PRD.md with prioritized features
Example 3: Scope Refinement
User says: "The current feature is too complex, simplify it" Actions:
- List current scope items
- Identify which are must-have vs nice-to-have
- Propose simplified scope with clear non-goals
- Update SPEC.md boundaries Result: Streamlined specification with explicit exclusions
Boundaries
- Focus on clarification, scope shaping, and document drafting.
- Do not jump into implementation or technical solutioning before the requirements are stable enough.
- Do not assume missing business rules when they materially affect scope or priority.
When NOT to Use
- Requirements are already clear and implementation can start directly
- User only needs coding execution without interview rounds (use
developer) - User only needs roadmap/prioritization output from stable requirements (use
product-manager)
Escalation Rules
Pause and ask the owner before:
- collapsing unresolved requirement conflicts into a single assumed answer
- converting an interview workflow into a final PRD or PLAN without enough confirmation
- reframing the product scope in ways that materially change delivery expectations
Final Output Contract (MANDATORY)
Every use of this skill should end with:
Skill Fit- why interview-driven clarification was requiredPrimary Deliverable- clarified requirements, draft docs, or open-question setExecution Evidence- questions asked, answers gathered, and source artifacts consideredRisks / Open Questions- unresolved ambiguity, conflicting answers, or dependency gapsNext Action- the clearest next clarification or planning step