Prompts for discovery and software scope
Turn an early idea into a useful brief, then turn an approved workflow into acceptance criteria before asking an agent to build it.
011 · Turn an idea into a decision-ready brief
Use when: the idea is still broad and you do not know what the first build should include. Start in Claude Code or Codex with read-only access to relevant material.
Bring: a description of the audience, current workaround, known constraints, and any source notes. Check: the output separates facts from assumptions and describes a complete user journey.
Act as a product discovery partner. Do not edit files or build the product.
Audience: [who will use this]
Problem and current workaround: [what happens today]
Desired outcome: [what should improve]
Known constraints: [budget boundary, date, stack, integrations]
Source context: [notes or attached references]
Produce a short brief with one core user journey, the smallest useful first release, explicit exclusions, and dependencies that need investigation. Separate confirmed requirements from assumptions. Ask only the questions that would materially change scope or feasibility. Do not invent demand, user research, or results.
Finish with the decisions a founder and engineer need to make before implementation.022 · Define acceptance and failure cases
Use when: the core journey is agreed but “done” is still vague. This is a planning task before implementation.
Bring: the approved brief, user roles, data boundaries, and relevant existing behavior. Check: the expected results can be verified independently, including a denied-access and a failure case where relevant.
Create acceptance criteria for the approved journey below. Do not implement changes.
Approved journey: [user, task, expected result]
Roles and access rules: [who can see and change which records]
Relevant existing behavior: [files, docs, or examples]
Out of scope: [explicit exclusions]
Describe observable success, empty input or results, invalid input, permission denial, and meaningful integration failures. For write operations, cover repeated submission and partial failure where relevant.
Give a small set of checks with explicit inputs and expected outcomes. Identify missing requirements as questions rather than choosing business rules silently. Flag dependencies that need a technical check before a delivery estimate.03Move from the brief into design
Have the founder confirm the outcome and an engineer examine the technical unknowns. Then bring the approved journey into the design stage.