Idea Refine

Idea Refine

Purpose

Turn a raw concept into one concrete direction that is specific enough to hand off into engineering framing and later spec work.

Outcome-First Operating Rules

• Start by naming the skill-specific outcome, success criteria, constraints, available evidence, and stop rule.
• Treat workflow steps as decision rules, not a ritual checklist. Follow exact order only when this skill or the repository contract makes the sequence an invariant.
• Use the minimum context, references, tools, and validation loops that can change the deliverable; stop expanding when the quality bar is met.
• Before acting, resolve prerequisite discovery, lookup, or artifact reads that the outcome depends on; parallelize only independent evidence gathering and synthesize before the next decision.
• Prefer bounded assumptions and local evidence over broad questioning; ask only when a missing fact would change correctness, ownership, safety, or scope.
• When evidence is missing or conflicting, retry once with a targeted strategy or label the assumption, blocker, or reopen target instead of treating absence as proof.
• Finish only when the requested deliverable is complete in the required shape and verification or a clearly named blocker/residual risk is recorded.

Scope

• restate the idea as a user/problem statement instead of a proposed implementation
• identify the target user or operator, desired outcome, and success signal
• explore a small set of plausible directions, then converge on one recommendation
• surface critical assumptions, MVP boundaries, and a clear Not Doing list
• produce a compact handoff artifact that can feed spec-first-brainstorming

Lazy Reference Loading

References are compact rubrics and example banks, not exhaustive checklists or product-management documentation. Load at most one reference by default: choose the one decision pressure that is most likely to change the output. Load a second reference only when the task clearly spans independent pressures, such as a solution-led prompt that is also blocked by destructive-action policy uncertainty.

| Reference | Symptom | Behavior Change | | --- | --- | --- | | references/problem-vs-solution-framing.md | The idea starts as a feature, implementation, vendor/tool choice, AI mechanism, or "we need X" request while the underlying pain is blurry. | Reframes the proposal into a user/operator problem instead of repeating the requested solution as the recommendation. | | references/target-user-and-success-signal.md | The actor, operator, job, or success signal is generic, mixed-audience, business-only, or output-shaped. | Chooses one primary actor and behavior/outcome signal instead of accepting "all users" and "ship the feature." | | references/clarifying-questions-and-safe-assumptions.md | The idea is thin enough to tempt a long questionnaire, but not so ambiguous that progress is impossible. | Uses one or two gating questions plus labeled safe assumptions instead of stalling or inventing certainty. | | references/direction-options-and-convergence.md | Several product directions remain plausible, or the raw idea is a grab bag of unrelated features. | Compares a small option set and recommends one first direction instead of merging every option into a bundle. | | references/assumptions-and-kill-criteria.md | The idea depends on enthusiasm, AI magic, uncertain demand, risky behavior, policy, trust, or weak evidence. | Names falsifiable bets and kill/pivot criteria instead of listing vague assumptions that cannot affect the recommendation. | | references/mvp-scope-and-not-doing.md | Scope is expanding, the MVP boundary is vague, or Not Doing would be missing or toothless. | Sets a learning-shaped MVP boundary with concrete exclusions instead of calling a platform-sized bundle an MVP. | | references/spec-first-handoff-examples.md | The pass has converged and needs to hand off into spec-first-brainstorming. | Produces a product-direction handoff with assumptions and open questions instead of smuggling architecture, endpoints, or tasks into the next step. |

Boundaries

Do not:

• write final architecture, API, data, security, reliability, or rollout decisions
• turn the output into a task breakdown or coder plan
• keep several equally valid directions alive just to avoid choosing
• hide weak assumptions behind generic enthusiasm
• ignore real repository constraints when the idea clearly lands in this codebase

Escalate When

Escalate if:

• no clear user or operator can be identified
• success cannot be described in concrete terms
• the idea hides high-risk semantics like destructive actions, money movement, identity, privacy, or irreversible state and needs explicit policy input
• the user is really asking for engineering framing, not ideation
• multiple directions remain viable but no recommendation can be defended

Core Defaults

• Prefer one recommended direction over a menu of half-committed options.
• Prefer the smallest meaningful MVP that can validate the core bet.
• Prefer explicit trade-offs over aspirational scope.
• Prefer a short list of strong assumptions over a longer list of vague unknowns.
• Prefer saying what we are not doing yet; focus is part of the deliverable.

Workflow

1. Clarify The Real Problem

• Restate the idea as a user/problem statement.
• Make the target user or operator explicit.
• Name the desired outcome and what success looks like.
• If the request is still too vague, ask only the minimum questions needed to remove ambiguity.

2. Expand, Then Converge

• Explore a small set of genuinely different directions.
• Stress-test them against:
• user value
• feasibility in this repository and stack
• simplicity of MVP scope
• differentiation or real payoff
• Converge on one direction instead of carrying several into spec work.

3. Surface The Bets

• List the assumptions that must be true for the recommendation to hold.
• Name what could kill the idea or force a different direction.
• Mark constraints that the later spec work must preserve.

4. Define The Handoff Boundary

• State the MVP scope in plain language.
• State the Not Doing list explicitly.
• End with what engineering framing should do next, not with implementation detail.

Deliverable Shape

Return ideation work in this order:

• Problem
• Target User / Operator
• Recommended Direction
• Why This Direction
• Key Assumptions To Validate
• MVP Scope
• Not Doing
• Open Questions
• Next Handoff

Next Handoff should usually point to spec-first-brainstorming.

Artifact Guidance

• Keep the result inline when the conversation is short and the handoff is obvious.
• When the result should be preserved, save it under specs//research/idea-refine.md or another user-approved location.
• Do not invent a feature folder only for archival neatness.

Definition Of Done

The pass is complete when:

• one recommended direction exists
• the user/problem and success signal are explicit
• the MVP boundary is narrow enough to guide framing
• the Not Doing list removes obvious scope creep
• the output is ready to hand off into spec-first-brainstorming

Escalate Or Reject

• brainstorming that never converges on one direction
• shipping implementation detail instead of idea refinement
• a yes-machine response that never challenges weak assumptions
• handoff output with no MVP boundary or Not Doing list

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: Dankosik
• Source: Dankosik/go-service-template-rest
• License: MIT

Install and usage instructions live in the source repository linked above.