idea-to-spec

Overview

Vague ideas produce vague implementations. This skill transforms any idea — no matter how fuzzy — into a concrete specification with clear scope, acceptance criteria, and non-goals.

When to Use

• At the start of any new feature
• When a request is ambiguous
• Before creating tasks or writing any code

Process

Step 1: Capture the Core Problem

1. Write: "Users currently can't [do X], which causes [pain Y]."
2. Identify: who has this problem? How often? What's the impact?
3. Distinguish problem from solution — don't spec a solution until the problem is understood.

Verify: You can state the problem without mentioning any implementation.

Step 2: Define Success

1. Write 3–7 acceptance criteria in this format:

   Given [context]
   When [action]
   Then [outcome]
   

2. Each criterion must be binary — either it passes or it doesn't.
3. Include negative cases: "Given X, the system must NOT do Y."

Verify: A QA engineer can test each criterion without asking for clarification.

Step 3: Define Scope

1. In scope: List what is explicitly included.
2. Out of scope: List what is explicitly excluded — as important as what's included.
3. Open questions: List any decisions that still need resolution before implementation.

Verify: The out-of-scope list has at least 2 items.

Step 4: Define Non-Functional Requirements

1. Performance: response time, throughput, scale targets.
2. Security: auth requirements, data sensitivity.
3. Reliability: uptime SLA, acceptable error rate.

Verification

• Problem statement written without mentioning implementation
• Acceptance criteria in Given/When/Then format
• Each criterion is binary (pass/fail)
• Explicit out-of-scope list
• Open questions listed

References

• think-before-coding skill
• task-decomposition skill