You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
68
Does it follow best practices?
If you maintain this skill, you can automatically optimize it using the tessl CLI to improve its score:
npx tessl skill review --optimize ./path/to/skillValidation for skill structure
Help turn ideas into fully formed designs through collaborative dialogue, enhanced by parallel research scouts.
Deploy scouts to explore project context in parallel, synthesize their findings, then ask questions one at a time to refine the idea. Once you understand what you're building, present the design and get user approval.
<HARD-GATE> Do NOT invoke any implementation skill, write any code, scaffold any project, or take any implementation action until you have presented a design and your human partner has approved it. This applies to EVERY project regardless of perceived simplicity. </HARD-GATE>Every project goes through this process. "Simple" projects are where unexamined assumptions cause the most wasted work. The design can be short, but you MUST present it and get approval.
You MUST create a task for each of these items and complete them in order:
docs/plans/YYYY-MM-DD-<topic>-design.md in the worktree (do NOT commit)When brainstorming is re-invoked after implementation feedback (already in a worktree):
Detection:
# Check if we're in a worktree (not the main working tree)
git worktree list --porcelain | grep -A2 "$(pwd)"If already in a worktree:
docs/plans/*-design.md to understand prior design decisionsdocs/plans/ directorydigraph brainstorming {
"Already in worktree?" [shape=diamond];
"Create team, spawn scouts" [shape=box];
"Scouts explore in parallel" [shape=box];
"Synthesize scout findings" [shape=box];
"Ask clarifying questions" [shape=box];
"Propose 2-3 approaches" [shape=box];
"Present design sections" [shape=box];
"STOP — wait for explicit approval" [shape=doubleoctagon, style=bold];
"User approves design?" [shape=diamond];
"Create worktree (kit:git-worktrees)" [shape=box];
"Write design doc (no commit)" [shape=box];
"Shutdown team" [shape=box];
"Invoke writing-plans skill" [shape=doublecircle];
"Already in worktree?" -> "Ask clarifying questions" [label="yes — skip scouts"];
"Already in worktree?" -> "Create team, spawn scouts" [label="no — fresh start"];
"Create team, spawn scouts" -> "Scouts explore in parallel";
"Scouts explore in parallel" -> "Synthesize scout findings";
"Synthesize scout findings" -> "Ask clarifying questions";
"Ask clarifying questions" -> "Propose 2-3 approaches";
"Propose 2-3 approaches" -> "Present design sections";
"Present design sections" -> "STOP — wait for explicit approval";
"STOP — wait for explicit approval" -> "User approves design?";
"User approves design?" -> "Present design sections" [label="no, revise"];
"User approves design?" -> "Create worktree (kit:git-worktrees)" [label="yes (fresh start)"];
"User approves design?" -> "Write design doc (no commit)" [label="yes (re-entry)"];
"Create worktree (kit:git-worktrees)" -> "Write design doc (no commit)";
"Write design doc (no commit)" -> "Shutdown team";
"Shutdown team" -> "Invoke writing-plans skill";
}The terminal state is invoking writing-plans. Do NOT invoke any other implementation skill.
REQUIRED (fresh start only): Use kit:team-orchestration to create the team.
Name: "brainstorm-<topic>"
Spawn 2-3 Explore-type teammates to investigate different aspects in parallel:
Spawn all scouts in a single message for maximum parallelism.
Collect all scout reports. Build comprehensive understanding before engaging your human partner.
Understanding the idea:
Exploring approaches:
Presenting the design:
Worktree (fresh start only):
Documentation:
docs/plans/YYYY-MM-DD-<topic>-design.mdShutdown:
Implementation:
5f1a022
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.