singleton-sd Refine Idea
Use this skill when the user has a rough idea, feature thought, transcript, pain point, opportunity, or solution proposal and wants help deciding what the idea actually is and whether it is worth pursuing.
This skill is deliberately before requirements discovery. Do not turn the idea directly into implementation tickets unless the user explicitly asks to skip discovery and the idea is already decision-complete.
Goal
Produce a concise Refined Idea Brief that answers:
- What problem are we solving?
- Who has the problem?
- Why does it matter?
- What outcome would make the idea valuable?
- What assumptions are we making?
- What alternatives exist?
- What is the smallest useful version?
- What is intentionally not part of the idea?
- What material unknowns still need requirements discovery, research, design, or technical validation?
The agent is expected to challenge the premise. A valid outcome is do not build, defer, combine with existing capability, or run discovery first.
Conversational discovery
Do not dump a questionnaire on the user. Progressively resolve the highest-value uncertainty first.
Prefer one focused question at a time when user input is needed. Use existing repository, architecture, GitHub issues, and conversation context before asking questions the answer may already contain.
Typical sequence:
- Restate the idea in one sentence.
- Identify the user/problem, not just the proposed solution.
- Clarify desired outcome and why now.
- Separate the core capability from adjacent ideas.
- Challenge major assumptions and obvious alternatives.
- Define MVP / first useful slice.
- Identify risks, dependencies, and unknowns.
- Decide whether the idea is ready for
discover-requirements.
Do not force all steps when the idea is already clear.
External capability brainstorming
When the idea could plausibly benefit from external data, validation, enrichment, automation, or third-party services, use discover-public-apis during refinement.
The purpose is product brainstorming, not vendor selection. Use public API catalogs such as public-apis/public-apis to surface capabilities that may:
- make the MVP materially cheaper or faster to validate;
- improve the user's outcome with data or functionality that would be expensive to build;
- reveal useful adjacent features the user may not have considered;
- provide a simpler integrate-versus-build alternative.
Bring only material candidates back into the Refined Idea Brief. Classify them as MVP, later/optional, or rejected distraction. Explain the user value before naming specific providers.
Do not add features simply because an API exists. Provider choice, pricing, privacy, rate limits, reliability, licensing, and other implementation suitability must be verified through discover-public-apis and official provider sources before becoming delivery decisions.
What to challenge
When relevant, test the idea against:
- existing capability that may already solve the problem;
- whether the proposed solution addresses the real user pain;
- who benefits and who bears operational cost;
- security, privacy, compliance, support, and abuse implications;
- tenant/user configurability versus unnecessary complexity;
- build versus buy versus integrate;
- coupling to existing pillars or architecture boundaries;
- expected frequency and severity of the problem;
- whether an MVP can validate value before a large investment;
- whether multiple ideas have been accidentally bundled together.
for the target repository, inspect the Architecture Doc and existing GitHub issues when doing so would materially change the recommendation. Browsing is not claiming work.
Split bundled ideas
If one statement contains multiple independently valuable capabilities, split them conceptually before requirements work.
For each candidate capability identify:
- the problem it solves;
- whether it can ship independently;
- whether it depends on another capability;
- whether it belongs in the current idea or should become a separate follow-up.
Do not create implementation slices yet. That is the responsibility of
idea-to-delivery after discover-requirements marks the work
READY FOR DESIGN / DELIVERY PLANNING. A single existing GitHub issue
goes to backlog-refinement instead.
Readiness states
Finish with exactly one readiness recommendation:
READY FOR REQUIREMENTS
Use when the problem, users, desired outcome, MVP boundary, and major product assumptions are sufficiently clear. Hand off to discover-requirements.
NEEDS VALIDATION
Use when the core value proposition or feasibility depends on evidence not yet available. State the smallest research/spike/prototype needed to resolve it.
HOLD / DO NOT BUILD
Use when the idea is low value, duplicates existing capability, creates disproportionate cost/risk, or is solving the wrong problem. Explain why and, when useful, give a simpler alternative.
Refined Idea Brief
Use this structure as the normal output:
Idea
<one-sentence refined concept>
Problem
<user pain / opportunity>
Target users
<primary actors>
Desired outcome
<observable value>
Proposed capability
<solution at product level, not implementation design>
MVP
- <minimum useful capability>
Later / optional
- <valuable but non-essential capability>
Non-goals
- <explicit boundary>
Assumptions challenged
- <assumption> -> <assessment>
Alternatives considered
- <alternative> -> <why chosen/rejected>
Risks / unknowns
- <item>
Readiness
READY FOR REQUIREMENTS | NEEDS VALIDATION | HOLD / DO NOT BUILD
Next step
<discover-requirements, research/spike, or stop>
Keep the brief proportional to the idea. Small ideas do not need ceremony.
Persisting the brief
Resolve engineeringHost from consumer .skills/profile or
../../config/tracker-profiles/
(infer from git remote when missing). Host issues own engineering work, including technical
discovery — there is no separate pre-host "ideas" queue for anything that has already crossed
into engineering framing.
When the target repo is known, only when the user asks to store the brief:
- READY FOR REQUIREMENTS or NEEDS VALIDATION (a spike is genuinely engineering
discovery): open (or update) a host issue capturing the brief. Do not mark it agent-ready —
that happens later, via
discover-requirements→backlog-refinement/idea-to-delivery, once the open questions are resolved. - HOLD / DO NOT BUILD: no issue is needed unless the user wants the rejection recorded for future reference (a comment on a related existing issue is usually enough).
- A private business/commercial idea that has not yet crossed the engineering boundary is out of this skill's scope to file as an engineering issue — that is business planning (ClickUp product), not engineering discovery.
Browsing/refinement is not claiming: filing the issue does not assign it to anyone.
Create:
# GitHub (engineeringHost: github)
gh issue create --title "..." --body "..."
# GitLab (engineeringHost: gitlab)
glab issue create --title "..." --description "..."
Handoff contract
When READY FOR REQUIREMENTS, hand the Refined Idea Brief to discover-requirements.
discover-requirements may send the work back here if it uncovers a fundamental product ambiguity such as an unclear target user, unresolved value proposition, or multiple incompatible product directions.
Use discover-public-apis as a supporting discovery skill when external APIs or public data may materially change the MVP, alternatives, or value proposition. It does not replace product refinement or requirements discovery.
Do not duplicate the responsibilities of:
discover-public-apis— external capability brainstorming and provider discovery/validation;discover-requirements— detailed behavior, rules, actors, scenarios, NFRs, data/integration requirements;backlog-refinement— making an existing backlog item decision-complete and agent-ready;idea-to-delivery— parent/tracking issues, delivery-slice issues, dependencies, and parallel lanes.