mcpField
I
idea-to-plan

idea-to-plan

github.com/composio-communityAgent workflows1457 installsUpdated 23w ago
Repository

About idea-to-plan

idea-to-plan is a process for turning an underspecified request into a problem statement, scoped specification, and phased plan. It is intended for early-stage build ideas, requiring sign-off at each stage and no coding before the specification is approved.

Key features

  1. 01Restate the problem and target user first
  2. 02Ask only questions that can change the design
  3. 03Define goals, non-goals, and constraints
  4. 04Divide plans into verifiable phases
  5. 05Hold implementation until specification approval

Use cases

  1. 01Turn goals like “build a dashboard” into requirements
  2. 02Clarify scope and success criteria before development
  3. 03Assess whether an idea merits implementation
  4. 04Set verification steps for phased delivery

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/composio-community/opencode-skills --skill idea-to-plan

After installing, type/idea-to-planin Claude Code to confirm it loaded.

Details

From the project README

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.

Comments

Markdown supported