with one click
brainstorm
// Collaborative discovery — explore problem space, evaluate approaches, write design spec. Use before any creative work.
// Collaborative discovery — explore problem space, evaluate approaches, write design spec. Use before any creative work.
[HINT] Download the complete skill directory including SKILL.md and all related files
| name | brainstorm |
| description | Collaborative discovery — explore problem space, evaluate approaches, write design spec. Use before any creative work. |
Turn ideas into fully formed designs through collaborative dialogue.
This skill MAY: research (read-only), discuss, ask questions, write the brainstorm document. This skill MAY NOT: edit code, create files beyond the brainstorm document, run tests, deploy, implement anything.
NEVER write code during this skill. This is a discussion, not implementation.
/unipi:brainstorm <string(greedy)>
string(greedy) — the topic or problem to brainstorm aboutDo NOT write any code, scaffold any project, or take any implementation action until design is presented and user approved. This applies to EVERY project regardless of perceived simplicity.
Every project goes through this process. A todo list, a utility, a config change — all of them. "Simple" projects are where unexamined assumptions cause wasted work. Design can be short, but MUST present and get approval.
.unipi/docs/specs/YYYY-MM-DD-<topic>-design.md
Committed to current branch. Accessible across worktrees via git.
Exit: Context gathered. Ready to ask questions.
Ask one question at a time. Don't dump a questionnaire.
Start with:
Use ask_user for structured decisions (approach selection, scope tradeoffs) when the tool is available. If ask_user is not available, use conversational text with clearly numbered options (e.g., "1. Option A — ... 2. Option B — ... Please pick one."). Use conversational text for open-ended exploration. Prefer multiple choice when natural options exist. Validate assumptions explicitly.
Exit: Problem statement clear and reframed. Both agree on what solving.
Propose 2-3 different approaches with trade-offs:
Present conversationally with recommendation and reasoning.
If open questions emerge: MUST ask user about each one. Don't assume. Use ask_user with clearly labeled options and descriptions for each approach when available; otherwise present numbered options conversationally.
Exit: Approach chosen. User signals decision.
Once approach chosen, present design in sections:
ask_user for "approve / needs changes / go back" checkpoints if available; otherwise ask conversationally and wait for response)Design for isolation and clarity:
Exit: Design approved by user.
Write to .unipi/docs/specs/YYYY-MM-DD-<topic>-design.md:
---
title: "{Topic}"
type: brainstorm
date: YYYY-MM-DD
---
# {Topic}
## Problem Statement
{The actual problem, reframed}
## Context
{Key findings — what exists, what's been tried}
## Chosen Approach
{High-level description}
## Why This Approach
{Decision rationale, alternatives rejected}
## Design
{Architecture, components, data flow}
## Implementation Checklist
- [ ] Task 1 — description
- [ ] Task 2 — description
- [ ] Task 3 — description
## Open Questions
{Questions for planning phase}
## Out of Scope
{Explicitly excluded}
The ## Implementation Checklist section uses - [ ] markdown checkboxes. These are critical:
[ ] = unplanned — not yet covered by a plan[x] = planned — marked when /unipi:plan covers this item[x] does NOT mean done — implementation progress is tracked in the plan file (unstarted: / in-progress: / completed:)After writing, review with fresh eyes:
Fix issues inline. No need to re-review — fix and move on.
After self-review passes:
"Spec written and committed to
.unipi/docs/specs/YYYY-MM-DD-<topic>-design.md. Please review and let me know if you want changes before we plan."
Wait for user response. If changes requested, make them and re-run self-review.
Ask user what to do next. If ask_user is available, prefer structured options so the plan handoff can run automatically:
ask_user({
question: "What would you like to do next?",
options: [
{
label: "Proceed to /unipi:plan",
description: "Turn decisions into an implementation plan",
value: "plan",
action: "new_session",
prefill: "/unipi:plan specs:YYYY-MM-DD-<topic>-design",
},
{ label: "Keep exploring", description: "Refine questions or decisions", value: "explore" },
{ label: "Done for now", description: "Return later", value: "done", action: "end_turn" },
],
allowFreeform: false,
})
If ask_user is unavailable, ask conversationally with the same options. Keep this copyable fallback command visible:
/unipi:plan specs:YYYY-MM-DD-<topic>-design
Before delivering, verify:
[ ] markers/unipi:plan can start from this document without asking "what did you decide about X?"