Vibe Brainstorm

Overview

Use this skill before creative implementation scope hardens. It helps agents surface implicit expected behavior, explore Practical / Unconventional / Challenging idea directions, and select a direction without moving it into implementation until the user confirms it.

This is not a hidden single-agent brainstorming prompt. When a mode requires delegation, use real sub-agents only after the host exposes verified delegation capability and the current task authorizes it.

Activation

Use this skill when:

• The user explicitly invokes vibe-brainstorm or asks for creative

implementation brainstorming.

• The user asks for ideas, alternatives, interaction concepts, feature behavior,

interaction rules, UX flow, or implementation direction where implicit expected behavior matters.

• You are about to implement a feature with domain conventions, common user

expectations, spatial or stateful behavior, UI interaction norms, fairness rules, accessibility expectations, data consistency, or feedback semantics.

Do not use this skill for:

• Obvious mechanical edits, renames, formatting, dependency bumps, direct bug

fixes with a concrete plan, or one-line requested changes.

• Tasks where the user already approved a concrete implementation direction and

only wants execution.

• Conventional code review after implementation; use the relevant review or

debug workflow instead.

• Drafting, saving, or approving a durable requirements specification artifact.

Brainstormed directions become requirements only after the user confirms them and a requirements-capture workflow records them.

Mode Selection

full is not the autonomous default. Use it autonomously only when the task is clearly creative enough that idea generation, convention grounding, development, and selection are all necessary before implementation can be scoped.

Delegation Gate

Before running any mode or stage that requires sub-agents:

1. Verify the host exposes a delegation or sub-agent mechanism.
2. Verify the current task allows delegated work and any required data sharing.
3. Verify the run can leave recordable evidence for any later claim that real

sub-agents ran. The evidence must be independently captured by the host or runner and visible to the later reader or grader in the current output set, an attached run artifact, delegated invocation metadata, task IDs emitted by the tool system, or an equivalent host record. Assistant-authored prose in the final response is not such evidence.

1. Keep the delegated prompts bounded: ask for concise findings, tradeoffs, and

observable checks, not private chain-of-thought.

1. If delegation is unavailable, unrecordable, or not authorized for a required

stage, state that limitation and stop, or ask whether the user wants a clearly degraded single-agent fallback.

1. If the user authorizes a degraded fallback, label it as degraded and do not

claim sub-agents ran.

A delegation mechanism may be ad-hoc per-role sub-agent invocation or one scripted orchestration run: a host mechanism that fans out several roles under a single deterministic, independently recorded run and returns their results. Both satisfy check 1, and an orchestration run's host-recorded run identity, per-role task records, or run journal satisfies check 3 when the later reader can inspect it. A scripted run cannot pause for user input, so schedule only generator, critic, development, grounding, and selection stages inside it; checklist confirmation and final direction confirmation stay in the conversation after the run returns. Ask each role for a bounded structured result — candidates, fit, tradeoffs, risks, or checklist entries — so results can be collected and merged without re-deriving them. Do not require a specific host orchestration tool.

Any claim that real sub-agents ran must be backed by recordable host-provided evidence. A polished response, role headings, prose-only agent IDs, self-reported token summaries, runtime summaries, or persona-separated sections are not proof of delegation. Do not promote IDs, token totals, runtimes, or references to "above" tool calls that you type into the final response to confirmed; they remain assistant-authored claims unless they cite an independently recorded host artifact, metadata field, host-rendered tool block, task ID, or trace excerpt that the later reader can inspect. If real tool calls happened but the recorded output set is only the final text response, label the delegation claim unproven and keep any single-agent result separate from confirmed delegated output.

Delegated Roles

When delegation is verified and authorized, use real sub-agents for these roles:

• Practical generator.
• Unconventional generator.
• Challenging generator.
• Expected-behavior critic or end-user/domain-user role.
• Candidate development role for expanding viable ideas.
• Grounding role for matching ideas against expected-behavior and domain

references.

• Selection role for applying the mandatory gate and creativity ranking.

If any role required by the selected mode cannot run, follow the Delegation Gate instead of silently collapsing that role into the coordinator.

Modes

diverge

Use for idea generation only.

1. Run three generator sub-agents in parallel when delegation is available:

• Practical: low-risk ideas that fit familiar expectations.
• Unconventional: unusual ideas that may reframe the experience.
• Challenging: ambitious ideas that stretch implementation or interaction

assumptions while still targeting the user's goal.

1. Ask each generator for candidates, fit, tradeoffs, and implementation risks.
2. Return the ideas grouped by direction.
3. Do not add convention critique, expected-behavior grounding, development,

selection, ranking, or adoption recommendation unless the user asks for it.

conventions

Use for expected-behavior grounding without idea generation. This is the default mode when the skill triggers autonomously during implementation work.

1. Summarize the feature or behavior being scoped.
2. Run an expected-behavior critic or end-user/domain-user sub-agent when

delegation is available. Ask what a reasonable user would expect to happen, including edge cases.

1. Build a checklist of implicit expected behavior. Separate:

• mandatory expectations that would make the implementation feel wrong if

missed;

• optional or taste-based expectations;
• unknowns that need user confirmation.

1. Check relevant local docs, existing code, official docs, upstream docs, or

domain references when they are available and relevant. If reference access is missing, label the gap instead of fabricating certainty.

1. If the end-user or domain-user sub-agent cannot run with recordable evidence,

state that limitation before using a single-agent checklist and ask whether the user accepts the degraded checklist as enough to continue. Do not present that fallback as a completed delegated conventions pass.

1. Stop before implementation and ask the user to confirm or adjust the

checklist when it changes behavior, UX, domain rules, or implementation scope.

full

Use for the complete creative pass.

1. Run diverge to produce Practical / Unconventional / Challenging

candidates.

1. Run the conventions grounding pass.
2. Develop each viable candidate through the candidate development role when

delegation is available. Expand the candidate's user experience, implementation shape, risks, and convention interactions.

1. Use the grounding role to match developed candidates against the checklist

and domain references.

1. Use the selection role to apply the two-stage selection sieve:

• First reject candidates that fail mandatory expected-behavior gates. Show

the violated gate for every rejection.

• Then rank the remaining candidates by creativity, fit, and implementation

practicality. Do not reject an unusual candidate merely because it is unusual.

1. Provide one adoption recommendation and any runner-up worth preserving.
2. Stop before implementation. Ask the user to confirm the selected direction

before it becomes implementation scope or is handed to another workflow.

Convention Grounding

Use all four grounding mechanisms when the mode includes conventions:

• Checklist-style expected behavior: concrete pass/fail expectations and edge

cases.

• End-user role: delegated user, player, operator, or domain-user perspective

when sub-agents are available.

• Domain/reference lookup: local project docs, existing implementation, official

docs, upstream references, or domain material when relevant and accessible.

• User confirmation: a visible confirmation step before implementation when the

checklist affects behavior or scope.

Keep mandatory gates narrow. A gate is mandatory only when missing it would violate the user's goal, a domain convention, accessibility/safety expectation, data contract, or a clear "normal users would expect this" behavior. Put taste, polish, and speculative enhancements outside the mandatory gate.

Anchor convention checks in the current task, supplied references, local code, and the user's stated domain. Do not carry preloaded niche examples, third-party domain rules, platform rules, or fixture-specific checklists into unrelated tasks.

Output Contract

Prefer chat output. Create files only when the user explicitly asks for an artifact.

Use this shape, omitting or marking skipped sections only when the selected mode does not run that stage:

• Mode and delegation status: mode used and one of these delegation states:

confirmed only when the output set includes independently recorded host/runner evidence and the response cites its artifact, field, tool block, task ID, or trace location; unproven when real calls may have happened but only assistant-authored final text can record them; or unavailable/degraded with the limitation and authorization status.

• Expected-behavior checklist: mandatory, optional, and unknown expectations, or

skipped by mode for diverge.

• Candidates: grouped by Practical / Unconventional / Challenging for

idea modes, or not generated in conventions mode.

• Selection: rejected candidates with violated gates, ranked surviving

candidates, and adoption recommendation, or skipped by mode.

• Confirmation needed: the exact behavior checklist or selected direction the

user must confirm before implementation starts.

Do not include private chain-of-thought from any agent. Summarize conclusions, evidence, tradeoffs, and open questions.

Handoff Boundary

This skill stops at confirmed direction. After user confirmation, hand the confirmed checklist or selected candidate to implementation planning, plan execution, or ordinary coding as appropriate. Without that confirmation, do not start implementation, create code, stage files, commit, or claim the direction is approved.