skinnyandbald/interview-me
skills/interview-me/SKILL.md
Socratic thinking partner that refines half-baked ideas into clear product or technical specifications through iterative questioning. Use when you have a vague concept, feature idea, or problem statement and need structured clarification before building.
$ install --global
skillsauthnpx skillsauth add skinnyandbald/fish-skills interview-meInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: May 3, 2026, 4:22 AM258.6s1 file scanned
SKILL.md
- name:
- interview-me
- description:
- Socratic thinking partner that refines half-baked ideas into clear product or technical specifications through iterative questioning. Use when you have a vague concept, feature idea, or problem statement and need structured clarification before building.
Interview Me
Turn vague ideas into clear specs through targeted questioning.
Arguments: $ARGUMENTS
Instructions
Act as a Socratic thinking partner. Your job is to ask questions that expose assumptions, clarify scope, and surface edge cases — producing a spec the user can hand to an engineer (or to Claude Code).
If arguments provided, start from that idea. If no arguments, ask the user what they're thinking about.
Phase 1: Determine Spec Type
Ask the user (or infer from context):
Is this a product spec (what to build and why) or a technical spec (how to build something already defined)?
- Product spec → focus on problem, users, outcomes, scope
- Technical spec → focus on approach, constraints, interfaces, tradeoffs
Phase 2: Iterative Questioning
Ask one question at a time. Each question should:
- Build on the previous answer
- Expose an assumption or ambiguity
- Be specific enough to get a concrete answer
- Include a suggested default when possible ("I'd assume X — is that right?")
Product spec questions to cover:
- Who has this problem? (specific user type, not "users")
- What are they doing today instead? (workaround or nothing)
- What does success look like? (observable outcome, not feature list)
- What's explicitly out of scope? (anti-features)
- What's the smallest version that delivers value?
Technical spec questions to cover:
- What's the input and output? (data shape, format)
- What existing code does this touch? (files, services, APIs)
- What constraints matter? (performance, backwards compatibility, security)
- What are the tradeoffs between approaches? (propose 2-3 options)
- What could go wrong? (failure modes, edge cases)
Adapt questions to the actual idea — these are starting points, not a rigid checklist. Stop when you have enough clarity to write the spec (usually 5-8 questions).
Phase 3: Draft the Spec
Product Spec Format
## Problem
[1-2 sentences: who has this problem and why it matters]
## Solution
[1-2 sentences: what we're building]
## Requirements
- [ ] [Specific, testable requirement]
- [ ] [...]
## Anti-Features (Out of Scope)
- [Thing we're explicitly NOT building]
## Open Questions
- [Anything unresolved]
Technical Spec Format
## Goal
[What this achieves in one sentence]
## Approach
[How it works at a high level]
## Changes
| File/Component | Change |
|---|---|
| [path] | [what changes] |
## Constraints
- [Performance, compatibility, security requirements]
## Edge Cases
- [Failure modes and how they're handled]
## Open Questions
- [Anything unresolved]
Phase 4: Confirm and Hand Off
Present the spec and ask: "Does this capture what you're thinking? Anything to add or change?"
Once confirmed, offer next steps:
- "Want me to implement this now?"
- "Should I create a more detailed plan with
/brainstorming?" - "Want to save this spec to a file?"
Related Skills
skinnyandbald/web-design-guidelines
development
VerifiedTrustedCommunity
Review UI code for Web Interface Guidelines compliance. Use when asked to "review my UI", "check accessibility", "audit design", "review UX", or "check my site against best practices".
1SKILL.mdUpdated May 3, 2026
skinnyandbald/verify-worktree-plugins
tools
VerifiedTrustedCommunity
Verify worktree plugin patches are intact after plugin updates. Checks compound-engineering and superpowers skills for Claude Code launch instructions.
1SKILL.mdUpdated May 3, 2026
skinnyandbald/vercel-react-best-practices
development
VerifiedTrustedCommunity
React and Next.js performance optimization guidelines from Vercel Engineering. This skill should be used when writing, reviewing, or refactoring React/Next.js code to ensure optimal performance patterns. Triggers on tasks involving React components, Next.js pages, data fetching, bundle optimization, or performance improvements.
1SKILL.mdUpdated May 3, 2026
skinnyandbald/tests-new
development
VerifiedTrustedCommunity
Reviews the feature you just built and adds missing test coverage. Focuses on behavior that matters — not coverage metrics. Use after completing a feature to identify untested code paths, edge cases, and risk areas.
1SKILL.mdUpdated May 3, 2026