Refine Ideas Into Validated Designs

This skill turns raw ideas into clear, validated designs and specifications through structured dialogue before any implementation begins, explicitly to prevent premature implementation, hidden assumptions, misaligned solutions, and fragile systems - while the skill is active, no implementing, coding, or behavior modification is allowed. It operates as a design facilitator and senior reviewer, not a builder: no creative implementation, no speculative features, no silent assumptions, no skipping ahead. The process runs in seven steps. First, understand the current context (mandatory, before any questions) by reviewing existing files, documentation, plans, and prior decisions, noting implicit-but-unconfirmed constraints. Second, understand the idea one question at a time - preferring multiple-choice questions, splitting deep topics into several questions - covering purpose, target users, constraints, success criteria, and explicit non-goals. Third, explicitly clarify or propose assumptions for non-functional requirements: performance expectations, scale, security/privacy constraints, reliability/availability needs, and maintenance/ownership - proposing reasonable defaults clearly marked as assumptions when the user is unsure. Fourth is the Understanding Lock, a hard gate: before proposing any design, produce a 5-7 bullet understanding summary (what's being built, why, for whom, key constraints, explicit non-goals), list all assumptions, list open questions, then explicitly ask the user to confirm or correct it - proceeding to design is not allowed without explicit confirmation. Fifth, explore 2-3 viable design approaches, leading with the recommended option and explaining trade-offs (complexity, extensibility, risk, maintenance), ruthlessly avoiding premature optimization (YAGNI) - this still isn't the final design. Sixth, present the design incrementally in 200-300 word sections, checking "Does this look right so far?" after each, covering architecture, components, data flow, error handling, edge cases, and testing strategy as relevant. Seventh, maintain a running Decision Log throughout - what was decided, alternatives considered, and why - preserved for documentation. After the design is validated, it's written to a durable shared format (e.g. Markdown) including the understanding summary, assumptions, decision log, and final design, persisted per the project's standard workflow; only then, optionally, does the skill ask whether to set up for implementation, creating an explicit implementation plan if the user says yes. Exit from brainstorming mode requires all of: Understanding Lock confirmed, at least one design approach explicitly accepted, major assumptions documented, key risks acknowledged, and a complete Decision Log - any unmet criterion means continuing refinement rather than proceeding to implementation. For high-impact, high-risk, or elevated-confidence designs, the finalized design and Decision Log must be handed off to a multi-agent-brainstorming skill before implementation.

Use this skill when turning a raw idea into a validated design or specification before writing any code - especially for decisions with real cost to get wrong. Do not use it once a design is already validated and the exit criteria are met (that's when implementation, not brainstorming, is appropriate), and do not skip its hard gates (Understanding Lock, exit criteria) even under time pressure, since bypassing them is exactly the premature-implementation failure mode this skill exists to prevent.

Input is a raw idea plus the current project's existing files, documentation, and prior decisions. Output is a durable design document containing an understanding summary, explicit assumptions, a running decision log, and a validated final design - optionally followed by an implementation plan once the user confirms readiness.

Hands off high-impact, high-risk, or elevated-confidence designs to a companion multi-agent-brainstorming skill before implementation begins, and can isolate the follow-on implementation work (e.g. a separate branch or workspace) if the project's workflow supports it, only after explicitly asking "Ready to set up for implementation?"

Anyone turning a raw idea into a backend/system/feature design who wants explicit assumption surfacing, incremental validation, and a documented decision trail before a single line of implementation code is written.