How do I install the Idea To Plan skill?

Run npx skillmds@latest add composio-community/idea-to-plan in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Idea To Plan safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Idea To Plan?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Idea To Plan free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Idea To Plan?

composio-community (@composio-community) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Idea To Plan by composio-community — Agent Skill

Name: Idea To Plan
Author: composio-community

Idea To Plan

Turn a vague idea or feature request into a written, reviewable spec and implementation plan before any code is written. Use when the user says "I want to build X", "help me think through", "I have an idea", or hands over an underspecified request.

File contents

Idea to Plan

Convert an underspecified request into (1) a one-paragraph problem statement, (2) a scoped spec, and (3) a phased implementation plan — each shown to the user for sign-off before moving on. Never jump to code from a vague prompt.

When to use

The request is a goal, not a specification ("build a dashboard", "add auth").
Requirements, constraints, or success criteria are missing or implied.
The user is exploring whether something is worth building.

Do not use this for well-specified tasks, bug fixes with a clear repro, or mechanical changes — those go straight to implementation.

Procedure

1. Restate the problem (before asking anything)

Write one paragraph: who has what problem, why now, and what "solved" looks like. Show it. If you can't write it, you don't understand the request — that gap is your first question.

2. Ask only decision-changing questions

Batch 3–6 questions that would change the design if answered differently. Skip anything with a safe default — state the default instead and move on. Good targets:

Scope boundaries (what is explicitly out)
Hard constraints (stack, deadline, data, compliance)
Success criteria (how we'll know it works)
The one assumption that, if wrong, wastes the most work

3. Write the spec

## Problem
## Goals / Non-goals
## Constraints
## Approach (1–3 sentences)
## Open questions

Keep it under one screen. Show it, get explicit "yes" on Goals/Non-goals before planning.

4. Write the phased plan

Break into phases that each deliver something verifiable:

Phase 1: <smallest end-to-end slice that proves the approach> — verify by <X>
Phase 2: ...

Each phase: concrete deliverable, the files/areas touched, and how it's verified. Flag dependencies and the riskiest phase. Front-load risk.

5. Hand off

Output the spec + plan as the final artifact. Recommend the first phase and stop — implementation is a separate step the user triggers.

Quality bar

Problem statement fits in one paragraph and names a real user.
Non-goals are explicit (a spec with no non-goals is not scoped).
Every phase is independently verifiable.
No question asked that has an obvious default.
Zero code until the spec is signed off.

Anti-patterns

Asking 15 questions when 4 decide the design.
"Phase 1: set up the project" with no verifiable outcome.
Restating the user's prompt back as if it were a spec.
Designing the gold-plated version before the wedge is agreed.

---name: idea-to-plandescription: Turn a vague idea or feature request into a written, reviewable spec and implementation plan before any code is written. Use when the user says "I want to build X", "help me think through", "I have an idea", or hands over an underspecified request.---# Idea to PlanConvert an underspecified request into (1) a one-paragraph problem statement, (2) a scoped spec, and (3) a phased implementation plan — each shown to the user for sign-off before moving on. Never jump to code from a vague prompt.## When to use- The request is a goal, not a specification ("build a dashboard", "add auth").- Requirements, constraints, or success criteria are missing or implied.- The user is exploring whether something is worth building.Do **not** use this for well-specified tasks, bug fixes with a clear repro, or mechanical changes — those go straight to implementation.## Procedure### 1. Restate the problem (before asking anything)Write one paragraph: *who* has *what* problem, *why now*, and what "solved" looks like. Show it. If you can't write it, you don't understand the request — that gap is your first question.### 2. Ask only decision-changing questionsBatch 3–6 questions that would change the design if answered differently. Skip anything with a safe default — state the default instead and move on. Good targets:- Scope boundaries (what is explicitly **out**)- Hard constraints (stack, deadline, data, compliance)- Success criteria (how we'll know it works)- The one assumption that, if wrong, wastes the most work### 3. Write the spec```## Problem## Goals / Non-goals## Constraints## Approach (1–3 sentences)## Open questions```Keep it under one screen. Show it, get explicit "yes" on Goals/Non-goals before planning.### 4. Write the phased planBreak into phases that each deliver something verifiable:```Phase 1: <smallest end-to-end slice that proves the approach> — verify by <X>Phase 2: ...```Each phase: concrete deliverable, the files/areas touched, and how it's verified. Flag dependencies and the riskiest phase. Front-load risk.### 5. Hand offOutput the spec + plan as the final artifact. Recommend the first phase and stop — implementation is a separate step the user triggers.## Quality bar- Problem statement fits in one paragraph and names a real user.- Non-goals are explicit (a spec with no non-goals is not scoped).- Every phase is independently verifiable.- No question asked that has an obvious default.- Zero code until the spec is signed off.## Anti-patterns- Asking 15 questions when 4 decide the design.- "Phase 1: set up the project" with no verifiable outcome.- Restating the user's prompt back as if it were a spec.- Designing the gold-plated version before the wedge is agreed.

Frequently asked questions