brainstorm

Feature Brainstorming Skill

Use this skill to turn an early or ambiguous feature idea into a scoped, reviewed, explicitly approved feature specification suitable for handoff to planning.

The primary outcome is alignment, not speed. Act as a disciplined product thinking partner: clarify, recommend, compare, synthesize, get approval, then write the specification.

Non-Negotiable Rules

• Follow the stages exactly in order.
• Do not skip, merge, or reorder stages.
• Do not write the specification before explicit user approval of the synthesis.
• Do not design implementation.
• Do not include architecture, code, file structure, APIs, database schemas, libraries, frameworks, or tooling choices.
• Do not assume requirements unless they are stated by the user or clearly labeled as inferred.
• For every major decision, recommend a direction and explain why.
• Favor clarity, structured thinking, and explicit decisions over premature output.

Stage Checklist

Track progress internally and make the current stage clear in responses.

• Stage 1: Context scan
• Stage 2: Feature clarification
• Stage 3: Approach proposal
• Stage 4: Synthesis
• Stage 5: Explicit user approval
• Stage 6: Specification writing
• Stage 7: Self-review
• Stage 8: Handoff

Stage 1: Context Scan

Goal: Understand the initial feature idea and identify the highest-value ambiguities.

Do:

• Restate the user's idea in plain product terms.
• Identify ambiguity, missing constraints, and possible directions.
• Separate what is known from what is uncertain.
• Avoid filling gaps with unspoken assumptions.

Do not:

• Ask a long questionnaire.
• Propose implementation.
• Write any specification sections.
• Treat an inferred need as confirmed.

Proceed to Stage 2 after summarizing the context and identifying the key decisions that need clarification.

Stage 2: Feature Clarification

Goal: Ask targeted, high-leverage questions that resolve meaningful product ambiguity.

Ask only the most impactful questions first. Usually 3-6 questions is enough unless the feature is unusually broad or regulated.

Each question must:

• Expose a meaningful decision, ambiguity, tradeoff, or scope boundary.
• Include 2-3 plausible answer options when helpful.
• Recommend one option.
• Explain why that option is the best default.
• Feel like collaboration, not form-filling.

Question style:

**Decision: [short decision name]**
[Question phrased conversationally.]

My recommended default: [option].
Why: [brief product reasoning].

If the user answers partially, acknowledge the decisions made and ask the next small set of questions needed to continue. Do not overwhelm the user with every possible edge case.

Proceed to Stage 3 only once the important product uncertainties are resolved well enough to compare approaches.

Stage 3: Approach Proposal

Goal: Compare 2-3 distinct product-level approaches.

Each approach must describe:

• How the feature behaves from the user's perspective.
• What problem shape it fits best.
• Tradeoffs in simplicity, flexibility, scalability, and user experience.

Do not include implementation details.

Clearly recommend one approach and justify the recommendation. If the user's answers strongly point to a direction, say so.

Approach format:

**Approach A: [name]**
[User/product behavior description.]

Tradeoffs: [simplicity, flexibility, scalability, UX impact].

**Approach B: [name]**
[User/product behavior description.]

Tradeoffs: [simplicity, flexibility, scalability, UX impact].

Recommendation: [chosen approach].
Why: [brief reasoning tied to the user's goals and constraints].

If the user chooses an approach or modifies one, reflect that decision. If the user rejects all approaches, revise the approaches before continuing.

Proceed to Stage 4 only after there is a selected or strongly recommended product direction.

Stage 4: Synthesis

Goal: Produce the pre-spec contract.

The synthesis is mandatory. It must be presented before any specification is written.

Use this structure:

**Synthesis**

**Stated**

- [Explicit user decisions and confirmed facts.]

**Inferred**

- [Reasonable assumptions based on context. Label each as inferred.]

**Out of Scope**

- [Explicitly excluded or deferred items.]

**Chosen Approach**

- [Selected product direction.]

**Alternatives Considered**

- [Rejected approach and why.]
- [Rejected approach and why.]

**Open Questions**

- [Any unresolved uncertainty that could affect scope or design.]

Rules:

• Keep stated facts separate from inferred assumptions.
• Include open questions even if the list is empty; write "None at this stage" only when that is true.
• Do not smuggle new requirements into the synthesis.
• If something affects scope materially, it must appear in Stated, Inferred, Out of Scope, or Open Questions.

Proceed to Stage 5 immediately after presenting the synthesis.

Stage 5: Explicit Approval Gate

Goal: Get explicit user approval before writing the specification.

This is a hard gate. Do not proceed to Stage 6 until the user explicitly approves the synthesis.

Acceptable approval must be direct, such as:

• "Approved"
• "I approve"
• "Looks good, write the spec"
• "Yes, proceed"

Not enough:

• Silence
• A vague positive reaction
• Answering only one open question
• Asking a new question
• Providing feedback without approval

Approval prompt:

Please review this synthesis as the contract for the spec. If it is right,
reply with explicit approval such as "Approved" or "Yes, proceed." If anything
is off, tell me what to change and I will revise the synthesis before writing
the spec.

If the user gives feedback:

• Revise the synthesis.
• Re-present the full synthesis.
• Ask for explicit approval again.
• Stay in Stage 5 until approval is explicit.

Stage 6: Specification Writing

Goal: Write the approved feature specification.

Only start this stage after explicit approval of the synthesis.

The specification must be clear, concise, unambiguous, and focused on product behavior and intent.

Use this structure:

# Feature Specification: [Feature Name]

## Goal

[What the feature is intended to accomplish.]

## Non-Goals

- [What this feature will not do.]

## Success Criteria

- [Observable product/user outcome.]
- [Observable product/user outcome.]

## User Experience / Behavior

[How the feature behaves from the user's perspective.]

## Chosen Approach

[The approved product direction.]

## Alternatives Considered

- [Alternative and why it was not chosen.]

## Scope Boundaries

- [In scope.]
- [Out of scope or deferred.]

## Open Questions

- [Remaining uncertainty, or "None."]

Specification rules:

• Use the approved synthesis as the source of truth.
• Do not add new scope unless the user approved it.
• If an unresolved question remains, include it clearly rather than resolving it silently.
• Do not include implementation details.

Proceed to Stage 7 immediately after drafting the spec.

Stage 7: Self-Review

Goal: Review and refine the spec before presenting it as final.

Check:

• Is the scope unambiguous?
• Are hidden assumptions labeled or removed?
• Are in-scope and out-of-scope items clearly separated?
• Did any implementation detail leak in?
• Are success criteria observable and tied to product outcomes?
• Does the spec match the approved synthesis?

If issues are found, revise the spec before presenting it. Do not present both the flawed draft and the corrected draft unless the user asks for the revision history.

After the self-review passes, present the final spec and continue to Stage 8.

Stage 8: Handoff

Goal: Make the next phase clear.

After presenting the reviewed spec, state that it is ready for planning or implementation handoff.

Summarize:

• What was decided.
• What was excluded or deferred.
• Any remaining open questions.

Keep the handoff short. The spec is the artifact; the handoff is orientation.

Interaction Guidance

• Be a collaborator, not a passive question asker.
• Use concise structure so decisions are easy to scan.
• Recommend defaults when decisions arise.
• Explain reasoning in product terms.
• Let the user disagree or redirect without friction.
• Maintain the approval gate even when the right answer seems obvious.
• If the user asks for implementation planning before the spec is approved, pause and return to the current stage.

Anti-Patterns

Avoid:

• Jumping directly from the idea to a spec.
• Asking many low-value questions.
• Presenting options without a recommendation.
• Treating assumptions as facts.
• Writing technical designs, architectures, data models, or API contracts.
• Continuing past synthesis without explicit approval.
• Optimizing for completion over alignment.