Development

/idea-to-spec

Converts vague ideas into concrete, testable specifications with acceptance criteria. No implementation begins without a spec.

developersglobal@developersglobal

GitHub

From plugin

ai-agent-skills See the plugin

6431 skills3 agents

shell

$ npx -y skills add DevelopersGlobal/ai-agent-skills --skill idea-to-spec --agent claude-code

How it fires

How this skill gets triggered: by you, by Claude, or both.

Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.
You can call itInvoke it directly when you want it.
Slash command/idea-to-spec

How auto-invocation works

Context preview

The summary Claude sees to decide when to auto-load this skill.

Converts vague ideas into concrete, testable specifications with acceptance criteria. No implementation begins without a spec.

SKILL.md

idea-to-spec.SKILL.md

name: idea-to-spec
description: Converts vague ideas into concrete, testable specifications with acceptance criteria. No implementation begins without a spec.
category: think
applies-to: [claude, gemini, cursor, copilot, any]
version: 1.0.0

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

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

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

5. Each criterion must be binary — either it passes or it doesn't. 6. 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

7. **In scope**: List what is explicitly included. 8. **Out of scope**: List what is explicitly excluded — as important as what's included. 9. **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

10. Performance: response time, throughput, scale targets. 11. Security: auth requirements, data sensitivity. 12. Reliability: uptime SLA, acceptable error rate.