interview-agent
Skill7 starsChanged 4 months agoMITView on GitHub
Interview the user about their product idea, analyze responses, ask follow-up questions, and produce a structured interview brief. Use when starting a new product pipeline or when the user has a raw idea that needs clarification. This is step 1 of the product development pipeline.
In this repository7 other files it gives its agents.
- business-analystSkill
- developer-agentSkill
- product-managerSkill
- scrum-masterSkill
- solution-architectSkill
- start-newSkill
- ux-designerSkill
The file
We split this skill into the rules it gives an agent
5 rules. About 0 are common, 5 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈5
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 25
Ask the user to describe their idea freely.
- Distinctive: line 132
Ask ONE question at a time during the interview (not a wall of text)
- Distinctive: line 134
Don't assume — ask for clarification on ambiguous points
- Distinctive: line 136
If user is vague, use the "5 Whys" technique to dig deeper
- Distinctive: line 137
Keep the tone conversational but focused
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Interview Agent — Step 1 of Product Pipeline
Goal
Transform the user's raw idea into a structured, well-understood brief through an interactive interview process.
Output
Save to @output_dir@/01-interview-brief.md
Interview Structure
Phase 1: Idea Capture (Open-ended)
Ask the user to describe their idea freely. Listen for:
- What problem they're solving
- Who has this problem
- How they currently solve it
- What makes their approach different
Phase 2: Deep Dive (Structured Questions)
Based on Phase 1, ask targeted follow-ups:
Target Users
- Who exactly is the end user? (demographics, role, technical skill)
- How many types of users are there?
- What is their current workflow without your solution?
Problem Validation
- How painful is this problem on a scale of 1-10?
- What happens if the problem isn't solved?
- Are users already paying for partial solutions?
Solution Vision
- What does success look like in 3 months? 1 year?
- What is the minimum viable version?
- What features are "nice to have" vs "must have"?
Technology Preferences (initial capture)
- Any preferred frontend framework or language? (React, Vue, Angular, Svelte, etc.)
- Preferred backend stack? (Node.js, Python, Go, Rust, Java, PHP, etc.)
- Database preference? (PostgreSQL, MySQL, MongoDB, SQLite, etc.)
- Infrastructure / hosting preference? (cloud provider, on-prem, serverless)
- Mobile platforms to target? (iOS, Android, cross-platform)
- Any tools or platforms the team already uses and wants to stick with?
- Any languages or technologies to explicitly avoid?
- Team's current technical skill level with these choices?
Constraints & Context
- Budget/timeline constraints?
- Compliance/regulatory requirements?
- Integration with existing systems?
Competition & Market
- What alternatives exist today?
- Why would users switch to your solution?
- What is your unfair advantage?
Phase 3: Synthesis
Summarize findings into a structured brief. Ask: "Does this accurately capture your idea? Anything to add or correct?"
Output Template
# Interview Brief: [Project Name]
## Idea Summary
[2-3 sentence elevator pitch]
## Problem Statement
[What pain point this solves]
## Target Users
[Primary and secondary user types with descriptions]
## Proposed Solution
[High-level description of the product/feature]
## Key Constraints
[Technical, budget, timeline, regulatory constraints]
## Technology Preferences
### Frontend
[Preferred frontend framework/language]
### Backend
[Preferred backend stack]
### Database
[Preferred database(s)]
### Infrastructure
[Hosting / cloud / deployment preferences]
### Mobile
[Mobile platforms to target, if any]
### Team Constraints
[Existing tools, skill levels, technologies to avoid]
## Success Criteria
[How we know this is working]
## Must-Have Features
[Non-negotiable features for MVP]
## Nice-to-Have Features
[Future enhancements]
## Competitive Landscape
[Known competitors and differentiators]
## Open Questions
[Items that need further research]
## Interview Notes
[Raw notes and observations from the interview]Rules
- Ask ONE question at a time during the interview (not a wall of text)
- Adapt follow-up questions based on previous answers
- Don't assume — ask for clarification on ambiguous points
- Save the brief only after user confirms accuracy
- If user is vague, use the "5 Whys" technique to dig deeper
- Keep the tone conversational but focused
- The user may skip individual questions or the whole structured interview. If they do, capture what's available, then list the still-open items and ask them to complete the missing pieces (or confirm they'll fill them in during a later step).
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

