feature-spec git:20260303.19bc151A

Immutable. This exact content never changes and is served at /api/v1/blob/c10c3840e22c40a0.

---
name: feature-spec
description: >
  Write a concise feature spec for engineering handoff. Use when the user says "write a spec",
  "feature spec", "one-pager for eng", "spec this out", "write up this feature",
  "I need to hand this off to engineering", "shape this up", or wants a concise
  technical brief - even if they don't say "feature spec".
---

## Overview

Based on **Shape Up** by Ryan Singer (Basecamp). A feature spec is not a PRD. A PRD justifies building something. A spec tells engineers exactly what to build - but at the right altitude. Shape Up's principle: give engineers a shaped problem with clear boundaries, not a detailed recipe. Ambiguity in the spec becomes a bug in production. Over-specification kills ownership.

## Workflow

### Step 1: Write the header
```
# Feature Spec: [Feature Name]
**PM:** [your name]
**Eng Lead:** [engineer name]
**Appetite:** [1-2 weeks / 4-6 weeks]
**Status:** Draft | In Review | Approved
**Related PRD / Ticket:** [link]
```

### Step 2: Write the Problem (2-3 sentences)
What is broken or missing? Who is affected? Shape Up framing: "Jobs to be done" - what job is the user hiring this feature to do?

### Step 3: Write the Solution at the right altitude
Shape Up's "fat marker sketch" - describe the solution broadly. Engineers need room to make technical decisions. Write at the level of user-visible behavior, not implementation.

Structure:
- **Key interactions** - what users can do (not how)
- **Boundaries** - explicit scope limits
- **Rabbit holes** - specific traps to avoid

### Step 4: Write Functional Requirements
Number each. Cover in order:
1. Happy path
2. Error states
3. Empty states
4. Edge cases

### Step 5: Write Non-Functional Requirements
Only include what's genuinely constrained:
- Performance targets
- Accessibility level (WCAG AA minimum)
- Browser/device support
- Security or compliance requirements

Don't pad. If there's no real constraint, don't list one.

### Step 6: Define No-Gos (Shape Up)
Explicit list of what this spec does NOT include. This is Shape Up's most important contribution to spec writing - stating what you're NOT building is as important as what you are.

### Step 7: List Open Questions
```
Q: [question]
Owner: [name]
Due: [date]
```
No spec should be approved with unresolved questions. Assign owners.

### Step 8: Link assets
Figma files, API specs, data models. A spec without visuals is incomplete for UI work.

## Anti-Patterns

**1. Over-specifying implementation**
Bad: "The button is blue, 48px, positioned top-right with 16px margin."
Good: "Users can trigger X from the main action area. Exact placement per Figma [link]."
Shape Up: over-speccing removes creative ownership from engineers and designers.

**2. Missing error states**
Bad: "User submits the form and sees confirmation."
Good: Cover success, validation error, server error, empty state, and loading state.

**3. No rabbit holes section**
Bad: Spec that describes what to build but not what to avoid.
Good: "Don't rebuild the notification system for this - use existing email infrastructure."

**4. Spec approved with open questions**
Bad: "TBD" items in an approved spec.
Good: All open questions resolved or explicitly deferred with a named owner and date.

## Quality Checklist

- [ ] Appetite defined (small or big batch)
- [ ] Problem framed as "job to be done"
- [ ] Solution at the right altitude - behavior not implementation
- [ ] Requirements cover happy path, errors, empty states, edge cases
- [ ] No-Gos explicitly listed
- [ ] Rabbit holes called out
- [ ] Open questions have owners and due dates
- [ ] Figma / mockup links included for UI work
- [ ] Spec fits on one page (split if it doesn't)