/spec-generator — Interview-driven spec generation

Interview the user in-depth using AskUserQuestion to produce a comprehensive, detailed specification file.

Workflow

1. •Read the user's instructions (passed as arguments)
2. •Begin an in-depth interview using AskUserQuestion
3. •Ask probing, non-obvious questions across all dimensions
4. •Continue interviewing until thorough coverage is achieved
5. •Write the final spec to a file

Interview Strategy

Phase 1: Core Vision

• •What problem does this solve and for whom?
• •What does success look like? What are the measurable outcomes?
• •What existing solutions have been considered and why are they insufficient?

Phase 2: Technical Deep-Dive

• •Architecture: monolith vs microservices, data flow, state management
• •Data model: entities, relationships, constraints, migrations
• •API design: endpoints, auth, rate limiting, versioning
• •Infrastructure: hosting, scaling, caching, CDN, CI/CD
• •Dependencies: third-party services, libraries, licensing concerns

Phase 3: UI & UX

• •User flows: entry points, happy paths, error states
• •Interaction patterns: real-time vs batch, optimistic updates
• •Accessibility: screen readers, keyboard nav, color contrast
• •Responsive behavior: breakpoints, mobile-first considerations
• •Loading states, empty states, skeleton screens

Phase 4: Edge Cases & Constraints

• •Concurrency: race conditions, optimistic locking, conflict resolution
• •Failure modes: network errors, partial failures, retry strategies
• •Security: auth model, data encryption, input validation, CSRF, XSS
• •Performance budgets: load times, bundle sizes, database query limits
• •Data volume: pagination, infinite scroll, search indexing

Phase 5: Tradeoffs & Decisions

• •Build vs buy decisions
• •Consistency vs availability tradeoffs
• •Speed-to-market vs long-term maintainability
• •Scope: what is explicitly out of scope for v1?
• •Migration path: how to get from current state to target state

Phase 6: Operational Concerns

• •Monitoring and alerting requirements
• •Logging and debugging strategy
• •Rollback and deployment strategy
• •Testing strategy: unit, integration, e2e, visual regression
• •Documentation needs: API docs, runbooks, onboarding

Interview Rules

• •Ask ONE focused question at a time (never batch multiple questions)
• •Do NOT ask obvious or surface-level questions
• •Follow up on vague answers — push for specifics
• •Challenge assumptions respectfully when they seem risky
• •Adapt questions based on previous answers (skip irrelevant phases)
• •If the user says "that's it" or "done", wrap up immediately
• •Aim for 10-20 questions depending on project complexity

Output Format

Write the spec to SPEC.md (or a filename specified by the user) with this structure:

# [Project Name] — Specification

## Overview
[1-2 paragraph summary of what this is and why it exists]

## Goals & Success Criteria
- [Measurable outcome 1]
- [Measurable outcome 2]

## User Stories
- As a [role], I want [capability] so that [benefit]

## Technical Architecture
### System Design
[Architecture decisions, data flow diagrams in text]

### Data Model
[Entities, relationships, constraints]

### API Design
[Endpoints, auth, contracts]

## UI/UX Specification
### User Flows
[Step-by-step flows for key interactions]

### Wireframe Descriptions
[Text descriptions of key screens/components]

## Edge Cases & Error Handling
[Documented edge cases and how they're handled]

## Security Considerations
[Auth, encryption, validation, threat model]

## Performance Requirements
[Budgets, benchmarks, scaling expectations]

## Tradeoffs & Decisions
[Key decisions made during the interview with rationale]

## Out of Scope (v1)
[Explicitly excluded items]

## Open Questions
[Unresolved items that need further discussion]

Prompt

Follow the user instructions and interview me in detail using the AskUserQuestion tool about literally anything: technical implementation, UI & UX, concerns, tradeoffs, etc. Make sure the questions are not obvious — be very in-depth and continue interviewing me continually until it's complete. Then, write the spec to a file.

Guidelines

• •Never skip the interview — always ask questions, even if instructions seem complete
• •Prefer depth over breadth — 3 deep questions on architecture beats 10 shallow ones
• •The spec should be detailed enough that another developer can implement from it alone
• •Include direct quotes from user answers when they capture intent well
• •Flag any contradictions discovered during the interview