Idea Superpowers Suite

Idea Superpowers Suite

This skill is a superpowers-style umbrella workflow for idea development.

It coordinates the focused stages:

• idea-to-design-doc for product/design thinking
• idea-to-ui-design-brief for optional Full-mode UI direction and image-generation concepts
• idea-to-implementation-doc for build-ready implementation planning

Use this skill when the user wants a bigger, multi-step workflow that feels like a reusable system rather than a one-off prompt.

Purpose

Turn a rough thought into a structured chain of artifacts:

1. Idea capture — create or update a local idea note from the user's high-level concept.
2. Clarifying interview — capture the rough plan, philosophy, target experience, and constraints.
3. Design doc — flesh the idea into a full product/UX/technical design document.
4. Optional UI design brief — in Full mode only, define screens, layout, visual direction, states, and optional image-generation concept prompts.
5. Research pass — compare similar products and identify what to emulate or avoid.
6. Implementation spec — translate the design into practical build strategy.
7. Build handoff — produce one Markdown file with tasks, prompts, tests, acceptance criteria, and Superpowers handoff guidance.
8. Spec review — judge readiness before execution.

Design Philosophy

This workflow should:

• capture fast;
• clarify deeply;
• research before building;
• separate product thinking from engineering thinking;
• separate UI direction from implementation details when interface quality matters;
• save every stage as its own Markdown artifact;
• remain skippable and resilient when the user wants speed.

The UI brief is optional. It improves interface-heavy projects, but it must not make Lite mode heavier or break existing design-doc → implementation-doc flow.

Mode Selection

At the start, choose one of two modes unless the user explicitly picks one:

• Lite mode — for sketches, small utilities, early thoughts, and ideas the user wants captured quickly.
• Full mode — for serious app/product ideas that may later be built by an AI coding agent or Superpowers.

Default to Lite mode when the idea is vague or exploratory. Default to Full mode when the user asks for a product spec, implementation plan, build handoff, research pass, UI/mockup direction, or agent-ready artifact.

Default File Layout

Use local Markdown files first. If the user later wants Obsidian export, treat that as a separate step.

Lite mode layout

ideas/<idea-slug>.md
ideas/index.md

Optional only if requested:

ideas/<idea-slug>.implementation.md
ideas/<idea-slug>.build-prompt.md
ideas/<idea-slug>.ui-brief.md

Full mode layout with UI stage

ideas/<idea-slug>/
  README.md
  00-idea-capture.md
  01-design-doc.md
  02-ui-design-brief.md
  03-implementation-spec.md
  04-agent-build-handoff.md
  05-spec-review.md

Full mode fallback layout when UI stage is skipped

If the UI stage is skipped, preserve the previous simpler numbering:

ideas/<idea-slug>/
  README.md
  00-idea-capture.md
  01-design-doc.md
  02-implementation-spec.md
  03-agent-build-handoff.md
  04-spec-review.md

Use whichever numbering is already established in a package. Keep the README artifact map consistent.

Workflow Stages

Stage 1: Capture

When the user says they have an idea, create a working note with:

• title;
• short summary;
• rough problem statement;
• initial bullet points;
• mode: Lite or Full.

If needed, ask for a name, but prefer to proceed with a temporary title and refine later.

Stage 2: Interview

Ask one question at a time. Use references/interview-question-bank.md for stronger prompts.

In Lite mode, ask only enough to capture the idea clearly, then draft.

In Full mode, cover:

• target user and problem;
• what the app should do;
• desired behavior and product experience;
• scope and non-goals;
• main screens or sections;
• what should be visible at a glance;
• where users take action;
• details that can be hidden until needed;
• desired visual taste: minimal, playful, professional, dense, dashboard-like, calm, command-center, etc.;
• empty, loading, error, success, first-run, and permission states where relevant;
• data, integrations, and platform constraints;
• data location and hosting preference;
• platform targets: web, desktop, mobile web, iOS, Android, etc.;
• topology: one app or multiple pieces such as desktop app + hosted web app + API + worker;
• authentication, secrets, API keys, public/private sharing, and client/server boundaries;
• what would make the result feel excellent, not merely functional.

Do not push into stack decisions too early unless the user has made a technical constraint explicit. When technical planning starts, recommend practical defaults first, then let the user accept or change them.

Stage 3: Design Doc

Write 01-design-doc.md to capture product direction and enough technical shape to support planning.

Suggested sections:

• one-line summary;
• problem / purpose;
• product philosophy;
• target user;
• core concept;
• desired behavior;
• key features;
• layout / information architecture;
• UX notes;
• technical shape;
• data / integrations / platform needs;
• hosting / data location / deployment preference;
• platform targets;
• recommended technical defaults and accepted/changed decisions;
• non-goals;
• open questions;
• next steps.

Stage 4: Optional UI Design Brief

This stage is Full-mode only by default. Do not add it to Lite mode unless the user explicitly asks for UI, mockups, generated images, or visual design direction.

Load idea-to-ui-design-brief when this stage runs.

Create 02-ui-design-brief.md when interface quality matters. It should define:

• purpose of the UI;
• product feel and design principles;
• primary screens/surfaces;
• screen-by-screen notes;
• layout and information architecture;
• component inventory;
• key user flows;
• states to design: empty, loading, error, success, first-run, permissions;
• visual direction;
• accessibility and responsiveness;
• content/copy notes;
• optional image-generation concepts;
• selected direction;
• handoff notes for implementation.

Optional image-generation pass

Image generation is concept exploration, not the implementation source of truth.

Use it when:

• the user wants possible UI designs;
• taste is ambiguous;
• a dashboard/app/landing page needs visual exploration before code;
• comparing 2-3 directions would help.

Default concepts:

1. Conservative — familiar, low-risk, easy to implement.
2. Strong-fit — best interpretation of the product brief.
3. Divergent — more distinctive, useful for taste discovery.

If image generation is unavailable or skipped, write the prompts and continue text-only. If images are generated, use vision/manual review to translate them back into written requirements, component notes, and acceptance criteria. Do not ask Superpowers to copy an image blindly.

Stage 5: Research Pass

For the specific idea, look for similar products and note:

• what already exists;
• what is common / commodity;
• what is different;
• what should be avoided;
• where the idea fits.

Keep this practical and bounded. Research should strengthen the spec, not become an endless market report.

Stage 6: Implementation Thinking

Translate the idea into 03-implementation-spec.md if the UI brief exists, otherwise 02-implementation-spec.md.

Include:

• major system pieces;
• data needs;
• recommended database/storage choice and why;
• hosting/deployment target;
• platform target decisions;
• app topology decisions;
• frontend structure and how it respects the UI design brief if present;
• backend/service needs;
• recommended technical stack defaults;
• security/secrets model;
• integration points;
• workflow/milestones;
• risks and tradeoffs;
• executable build tasks;
• testing and verification plan;
• acceptance criteria / done means;
• a build sequence a developer or AI coding agent could follow.

Use recommend-then-confirm for technical choices:

1. infer sensible defaults from product constraints;
2. present a concise recommendation table;
3. ask whether the user accepts or changes items;
4. record accepted defaults and explicit overrides;
5. if unsure, proceed with defaults as assumptions.

Stage 7: Final Agent Build Handoff

Create or update README.md using templates/idea-package-readme-template.md.

Create the final handoff as:

• 04-agent-build-handoff.md if the UI brief exists;
• 03-agent-build-handoff.md if the UI brief was skipped.

Load idea-to-implementation-doc when creating the handoff because the canonical handoff template lives there.

The handoff must include:

• mission;
• product vision;
• non-negotiable requirements;
• UI/design direction or explicit UI assumptions;
• out of scope;
• technical architecture;
• implementation phases;
• build tasks;
• testing requirements;
• verification commands/checks;
• acceptance criteria;
• done means checklist;
• prompt for the build agent;
• explicit Superpowers handoff instructions.