idea-validation

Files (3)

• SKILL.md
• openai.yaml · agents/
• workflow.md · references/

SKILL.md (first lines)

# Idea Validation

Turn an interactive marketing opportunity into a field of meaningfully different concepts, then make the strongest ones survive contact with accessible inputs, concrete outputs, distribution logic, and public evidence. Optimize for ideas people would actually use—not concepts that merely sound persuasive in a workshop.

For a full engagement, read [the complete workflow](references/workflow.md) before beginning. It defines the phase gates, concept schemas, scorecard, public-example test, and stopping rules. For a narrowly requested phase, read that phase and every upstream rule it depends on.

## Preserve these invariants

- Diverge through creative territories before proposing polished concepts.
- Include a **transform something familiar** territory: identify recurring workflows the audience already performs and explore how to compress, automate, or improve them.
- Treat input access and user willingness as first-class feasibility. Prefer public sources and a few easy typed inputs. Penalize private uploads, proprietary telemetry, lengthy user research, unavailable integrations, and coordinated multi-user input unless the user explicitly permits them.
- Test functional or audience coverage explicitly. A concept moved from marketing to sales with the same mechanism is not automatically a different idea.
- Make the user action, immediate payoff, capability proof, distribution mechanism, and smallest viable build concrete for every concept.
- Do not count a lead form as user value or a generic share button as distribution.
- Separate the core mechanism from its name and copy. Replace clichés unless they contain an unusual interaction, dataset, transformation, or insight.
- Preserve creative risk through wildcard and magic-moment passes; business usefulness is not an excuse for beige output.
- Use numeric scoring as a comparison aid, never as the final source of truth. Evidence from running the concept may override the original ranking.
- Run operability proxy tests against real public examples. Never label demand, distribution, conversion, or technical feasibility validated when only the core transformation has been tested.

## Run the engagement

1. Establish the subject, audience, strategic objective, capability or advantage to demonstrate, desired audience reaction, build constraints, accessible inputs, prohibited dependencies, coverage requirements, and creative-risk appetite. Ask no more than three tightly related questions unless the answers expose a new material ambiguity.
2. Build a broad Creative Horizon of at least 12 fundamentally different territories. For each, state its mechanism, likely user action and accessible inputs, payoff, capability proof, sharing logic, and constraint fit. Show territories rather than a list of product ideas.
3. Use one territory-level alignment gate unless the user explicitly requests an autonomous run. Revise and re-present Phase 1 until the user approves continuation. After approval, complete the remaining phases without repeatedly asking permission unless materially blocked.
4. Generate the concept field, run the originality and magic passes, test distribution, score and develop the finalists, identify asymmetric winners, and run the finalists against public examples exactly as defined in the workflow.
5. Re-rank from observed evidence, revisit the four asymmetric winner categories, state what changed after proxy testing, and identify the next cheapest uncertainty to resolve. Use **Prototype**, **Test**, **Hold**, and **Kill** dispositions only when the user asks for a build decision.

## Research and evidence

- Use public, legally accessible information for proxy tests unless the user supplies or authorizes another source.
- Cite sources that materially support an input or conclusion. Distinguish observed facts, inferred patterns, and illustrative outputs.
- Prefer an imperfect live test over a polished fictional example. If required data cannot be obtained, treat that as evidence about operability.
- Do not imply market demand, originality, technical feasibility, or conversion performance from concept quality alone.

## Working state

Maintain a lightweight Working Brief, Territory Map, Concept Ledger, Cliché/Rejection Log, Scorecard, and Public-Example Proxy Log. Preserve rejected concepts and reasons long enough to prevent them from returning under new names.

At every gate ask: **What would have to be true for this idea to work, and can the intended user actually supply it?**

From hugobernardo/skills-library, MIT.

More from hugobernardo/skills-library