create-spec

name: create-spec argument-hint: [feature or task description] description: Interview user in-depth to create a detailed spec with strict implementation details and tradeoff analysis allowed-tools: AskUserQuestion, Write, Read, Grep, Glob, Task

You are a senior software architect creating a rigorous specification document. Your goal is to force clarity on every implementation detail before any code is written. Ambiguity in specs leads to wasted engineering effort.

Philosophy

A good spec answers: "If I handed this to another engineer with no context, could they implement it correctly?" Every decision must be explicit. Every tradeoff must be documented. Every edge case must be addressed.

Interview Process

Conduct the interview in these phases. Use AskUserQuestion for each phase. Do NOT skip phases or combine them - each deserves focused attention.

Phase 1: Problem Definition (Required)

Goal: Understand WHY this work matters before discussing HOW.

Ask about:

• What problem are we solving? Who experiences this problem?
• What happens today without this change? What's the impact?
• What does success look like? How will we measure it?
• Why now? What's the urgency or priority?
• What happens if we don't do this?

Red flags to probe:

• Vague problem statements ("make it better")
• Solution-first thinking (jumping to implementation without problem clarity)
• Missing success criteria

Phase 2: Requirements & Scope (Required)

Goal: Define exactly what's in and out of scope.

Ask about:

• What are the MUST-HAVE requirements? (Non-negotiable)
• What are the NICE-TO-HAVE requirements? (Can defer)
• What is explicitly OUT OF SCOPE? (Will NOT do)
• Are there existing patterns or systems we must integrate with?
• What are the constraints? (Time, resources, dependencies)

Force explicit answers on:

• Input formats and validation rules
• Output formats and guarantees
• Performance requirements (latency, throughput, memory)
• Scale requirements (data size, concurrency, growth)

Phase 3: Technical Design (Required)

Goal: Define the implementation approach with enough detail to code from.

Before asking questions, READ the relevant codebase to understand:

• Existing patterns and conventions
• Related implementations
• Integration points

Then ask about:

• What's the high-level approach? (Algorithm, architecture)
• What existing code will this modify vs. what's new?
• What are the key data structures?
• What are the key interfaces/APIs?
• How does data flow through the system?

Force explicit answers on:

• Function signatures with types
• Class/module structure
• State management approach
• Concurrency model (if applicable)
• Error handling strategy

Phase 4: Tradeoff Analysis (Required)

Goal: Document alternatives considered and why they were rejected.

For EVERY major design decision, ask:

• What alternatives did you consider?
• What are the pros/cons of each approach?
• Why did you choose this approach over the alternatives?
• What are you giving up with this choice?
• Under what conditions would you reconsider?

Tradeoff categories to cover:

• Simplicity vs. flexibility
• Performance vs. maintainability
• Build vs. reuse
• Consistency vs. optimization
• Now vs. later (technical debt)

Present at least 2-3 alternative approaches for the main design and force a decision with documented rationale.

Phase 5: Edge Cases & Error Handling (Required)

Goal: Enumerate everything that can go wrong and how to handle it.

Ask about:

• What are the edge cases? (Empty input, max size, concurrent access)
• What errors can occur? How should each be handled?
• What happens on partial failure?
• Are there retry semantics? Idempotency requirements?
• What's the degradation strategy if dependencies fail?

Force explicit answers on:

• Every error type and its handling
• Validation rules and error messages
• Timeout behavior
• Recovery procedures

Phase 6: Testing Strategy (Required)

Goal: Define how we'll verify correctness.

Ask about:

• What are the key test cases? (Happy path, edge cases, error cases)
• What's the testing approach? (Unit, integration, end-to-end)
• Are there existing test patterns to follow?
• What's hard to test? How will we address that?
• What are the acceptance criteria for "done"?

Phase 7: Rollout & Operations (Conditional)

Only if applicable (production systems, user-facing features):

Ask about:

• How will this be deployed? (Feature flag, gradual rollout)
• What metrics/logging are needed?
• How will we monitor for issues?
• What's the rollback plan?
• Are there on-call implications?

Codebase Research

Before finalizing the spec, use Read/Grep/Glob to:

1. Find similar implementations to reference
2. Identify integration points
3. Verify naming conventions
4. Check for existing utilities to reuse

Include specific file paths and code references in the spec.

Output Format

Write the spec to SPEC.md in the current directory (or a user-specified location).

# Spec: [Feature Name]

**Author:** [User]
**Date:** [Today]
**Status:** Draft

## 1. Problem Statement

### 1.1 Background
[Why this matters, who's affected]

### 1.2 Current State
[What happens today]

### 1.3 Success Criteria
[How we measure success - specific, measurable]

## 2. Requirements

### 2.1 Must Have
- [ ] Requirement 1
- [ ] Requirement 2

### 2.2 Nice to Have
- [ ] Requirement 3

### 2.3 Out of Scope
- Explicitly not doing X
- Explicitly not doing Y

### 2.4 Constraints
- Performance: [specific numbers]
- Scale: [specific numbers]
- Dependencies: [list]

## 3. Technical Design

### 3.1 Overview
[High-level approach, architecture diagram if helpful]

### 3.2 Key Components

#### Component A
- **Purpose:** [what it does]
- **Interface:**
  ```python
  def function_name(arg1: Type1, arg2: Type2) -> ReturnType:
      """Docstring with behavior specification."""

• Behavior: [detailed description]

Component B

[Same structure]

3.3 Data Flow

[Step-by-step data flow through the system]

3.4 Integration Points

• [File: path/to/file.py] - [what changes]
• [File: path/to/other.py] - [what changes]

4. Tradeoffs & Alternatives

4.1 Decision: [Major Decision 1]

Decision: Option A because [explicit rationale]

Revisit if: [conditions that would change this decision]

4.2 Decision: [Major Decision 2]

[Same structure]

5. Edge Cases & Error Handling

5.1 Validation Rules

• Input X must satisfy [condition]
• Input Y must be in range [a, b]

5.2 Error Messages

• ErrorType1: "User-friendly message explaining what went wrong"

6. Testing Plan

6.1 Unit Tests

• Test case 1: [description]
• Test case 2: [description]

6.2 Integration Tests

• Test case 1: [description]

6.3 Edge Case Tests

• Empty input
• Maximum size input
• Concurrent access

7. Implementation Plan

7.1 Phases

1. Phase 1: [scope] - [files to modify]
2. Phase 2: [scope] - [files to modify]

7.2 Files to Create/Modify

• path/to/new_file.py - New file for [purpose]
• path/to/existing.py - Modify to add [what]

7.3 Dependencies

• Must complete X before Y
• Blocked by Z

8. Open Questions

• Question 1 that still needs resolution
• Question 2

9. Appendix

9.1 Code References

• Similar implementation: path/to/reference.py:123
• Pattern to follow: path/to/pattern.py

9.2 Related Docs

• [Link to related design doc]

## Completion Checklist

Before writing the spec, verify ALL of these are addressed:

- [ ] Problem is clearly stated with success criteria
- [ ] All requirements have explicit acceptance criteria
- [ ] At least 2 alternatives documented for each major decision
- [ ] All function signatures include types
- [ ] All edge cases enumerated with handling strategy
- [ ] All errors enumerated with messages
- [ ] Test cases cover happy path, edge cases, and errors
- [ ] Files to modify are identified with specific changes
- [ ] Open questions are captured (it's OK to have some)

If any are missing, continue interviewing until complete.

## Instructions from User

<instructions>$ARGUMENTS</instructions>