Founder pack
Claude Skill
Idea-to-Spec Partner
Pressure-tests a rough idea into an approved design through one-question-at-a-time dialogue — before anyone writes code.
What it does
Turns a half-formed idea into a concrete, approved spec through collaborative dialogue: explores the context, asks clarifying questions one at a time, proposes 2-3 approaches with trade-offs and a recommendation, then presents a design for sign-off. The hard rule: nothing gets built until the design is approved — even for things that look simple.
When to use
- ✓A new feature or product idea that's still vague
- ✓Before committing engineering time to anything non-trivial
- ✓The team keeps building the wrong thing because the idea was never pinned down
When not to use
- ✗The spec is already written and approved — go straight to the execution plan
- ✗A truly mechanical change with no design decisions to make
Install
Download the .zip, then unzip into your Claude skills folder.
mkdir -p ~/.claude/skills
unzip ~/Downloads/idea-to-spec-partner.zip -d ~/.claude/skills/
# Restart Claude Code session.
# Skill is now available — Claude will use it when relevant.SKILL.md
SKILL.md
---
name: idea-to-spec-partner
description: Use before any build work — a new feature, product, or behavior change — to turn an idea into an approved design. Triggers on "I have an idea", "help me think through", "before we build", "pressure-test this", "turn this into a spec".
---
# Idea-to-Spec Partner
Turn an idea into a design through dialogue, then get it approved before anyone builds. The most expensive bugs are unexamined assumptions baked in at the idea stage.
## The hard gate
Do not write code, scaffold, or take any implementation action until you've presented a design and the user has approved it. This applies to every project, regardless of how simple it looks.
## "This is too simple to need a design"
It isn't. A todo list, a one-function utility, a config change — all of them go through this. "Simple" is exactly where unexamined assumptions cause the most wasted work. The design can be short — a few sentences for a genuinely small thing — but you must present it and get a yes.
## The process
1. **Explore context** — read the relevant files, docs, recent commits before asking anything
2. **Ask clarifying questions one at a time** — purpose, constraints, success criteria. Not a questionnaire dump; a conversation. Each answer shapes the next question.
3. **Propose 2-3 approaches** — with honest trade-offs and your recommendation
4. **Present the design** — in sections scaled to their complexity; get approval per section
5. **Write the design doc** — capture what was decided, so the plan and the build have a source of truth
6. **Self-review the spec** — scan for placeholders, contradictions, ambiguity, scope creep
7. **Hand off to planning** — once approved, the spec feeds an execution plan
## Why one question at a time
A wall of ten questions gets shallow answers and hides the contradictions. Asking sequentially lets each answer redirect the next — that's where the real requirements surface.
## Anti-patterns
- Jumping to a solution before understanding the problem
- Dumping all questions at once
- Skipping the design because the task "looks trivial"
- Presenting one approach as if it were the only option
- Starting to build before the user actually said yes
Example prompts
Once installed, try these prompts in Claude:
- I have a rough idea for an in-app onboarding flow. Pressure-test it into a spec — ask me questions one at a time.
- Help me think through this feature before we build it. Give me 2-3 approaches with trade-offs and a recommendation.