# Idea Refine

> Refine raw product or feature ideas into one concrete direction worth taking into engineering. Use when the request is still idea-shaped, solution-led, or ambiguous at the user/problem level and the repository is not ready for `spec-first-brainstorming` or specialist spec work yet. Skip once the direction is already chosen and the task mainly needs engineering framing.

- **Type:** Skill
- **Install:** `agentstack add skill-dankosik-go-service-template-rest-idea-refine`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [Dankosik](https://agentstack.voostack.com/s/dankosik)
- **Installs:** 0
- **Category:** [Databases](https://agentstack.voostack.com/c/databases)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [Dankosik](https://github.com/Dankosik)
- **Source:** https://github.com/Dankosik/go-service-template-rest/tree/main/.agents/skills/idea-refine

## Install

```sh
agentstack add skill-dankosik-go-service-template-rest-idea-refine
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# 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](https://github.com/Dankosik)
- **Source:** [Dankosik/go-service-template-rest](https://github.com/Dankosik/go-service-template-rest)
- **License:** MIT

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

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-dankosik-go-service-template-rest-idea-refine
- Seller: https://agentstack.voostack.com/s/dankosik
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.