Idea to Blueprint

Overview

Turn a raw idea into a single markdown document that is complete enough for a coding agent to build the product epic by epic, in fresh sessions, without ever having to guess. The blueprint is not a "PRD" in the loose sense: it is the product's only shared memory between the human, the research, and every future build session.

The skill runs intake questions, web research and competitor benchmarking, then writes one Markdown blueprint: architecture drivers and style, a version-pinned stack with evidence tags, a quality gate, personas, flows, UX copy, edge cases, and epics broken into stories with Given/When/Then acceptance criteria, tests and a Definition of Done. The blueprint embeds a session protocol so Claude Code or Codex builds it one epic per fresh session.

This is the author's own skill, published at iniesohidham/idea-to-blueprint under the MIT license (see LICENSE). The files in references/, assets/ and scripts/ are unchanged copies of the upstream files; this SKILL.md adds the catalog sections (Overview, When to Use, Examples, Limitations, safety notes) around the upstream instructions.

When to Use This Skill

• Use when someone shares a product, app, bot or feature idea (even 2–3 lines) and wants a PRD, spec, backlog, epics, user stories, roadmap or MVP plan, even without saying "PRD".
• Use when the user wants deep web research, market research or competitor benchmarking before anything is built.
• Use when the user wants an architecture or tech-stack recommendation with justification and pinned versions, or code-quality and review standards for a new product.
• Use when the user asks for "a plan for Claude Code/Codex" that a coding agent can execute one epic at a time.
• Prefer it over lighter PRD skills when research depth, rigor or zero hallucination matters.
• Do not use it to review an existing PRD, to compare two frameworks in isolation, or to write a single piece of UX copy.

How It Works

Run this skill on the strongest model available at the highest effort/thinking setting the harness offers. If you cannot tell whether that is the case, say so once at the start and continue.

Why this document has to be different

A build session that starts from a blank context has exactly two sources of truth: the repo and this blueprint. Whatever is missing, vague, or wrong in the blueprint becomes a guess in code. So the whole skill is organized around three habits:

1. Evidence or silence. Every claim about the outside world (a library, a version, a competitor, a regulation, a market figure, a service's availability in a country) carries an evidence tag: [VERIFIED — <source>, <date>], [ASSUMED — <why>], or [UNKNOWN → OQ-nn] (routed to Open Questions). You never fill a gap with a plausible-sounding guess, because the reader has no way to tell your guess from a fact.
2. Decide, don't hedge. "Use X or Y" pushes the decision onto an agent with less context than you have now. Make the call, record the alternatives and why they lost.
3. Write for zero context. No "as discussed", no "the usual way". Every ID (persona, flow, screen, copy line, story, criterion) is unique and cross-referenced so a fresh session can resolve everything by search.

Everything below serves those three habits.

Workflow

…