From orchestrator-supaconductor
Guides ideas into approved designs through dialogue: explores context, clarifies requirements one question at a time, proposes approaches with trade-offs, iterates sections until approval, then documents.
npx claudepluginhub ibrahim-3d/orchestrator-supaconductor --plugin orchestrator-supaconductorThis skill uses the workspace's default tool permissions.
Help turn ideas into fully formed designs and specs through natural collaborative dialogue.
Guides collaborative brainstorming to turn ideas into approved design specs before implementation: explores context, asks questions, proposes approaches, writes reviewed docs.
Guides pre-implementation ideation for features, components, and changes by exploring context, clarifying requirements, proposing trade-offs, and creating approved design docs.
Brainstorms ideas into validated designs by clarifying intent, exploring 2-3 approaches with trade-offs, and presenting specs incrementally before implementation.
Share bugs, ideas, or general feedback.
Help turn ideas into fully formed designs and specs through natural collaborative dialogue.
Start by understanding the current project context, 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.
Do NOT invoke any implementation skill, write_file any code, scaffold any project, or take any implementation action until you have presented a design and the user has approved it. This applies to EVERY project regardless of perceived simplicity.Every project goes through this process. A todo list, a single-function utility, a config change — all of them. "Simple" projects are where unexamined assumptions cause the most wasted work. The design can be short (a few sentences for truly simple projects), but you MUST present it and get approval.
You MUST create a task for each of these items and complete them in order:
conductor/tracks/{track_id}/design.md (if track exists) or conductor/designs/YYYY-MM-DD-<topic>-design.md and commitdigraph brainstorming {
"Explore project context" [shape=box];
"Ask clarifying questions" [shape=box];
"Propose 2-3 approaches" [shape=box];
"Present design sections" [shape=box];
"User approves design?" [shape=diamond];
"write_file design doc" [shape=box];
"Invoke writing-plans skill" [shape=doublecircle];
"Explore project context" -> "Ask clarifying questions";
"Ask clarifying questions" -> "Propose 2-3 approaches";
"Propose 2-3 approaches" -> "Present design sections";
"Present design sections" -> "User approves design?";
"User approves design?" -> "Present design sections" [label="no, revise"];
"User approves design?" -> "write_file design doc" [label="yes"];
"write_file design doc" -> "Invoke writing-plans skill";
}
The terminal state is invoking writing-plans. Do NOT invoke frontend-design, mcp-builder, or any other implementation skill. The ONLY skill you invoke after brainstorming is writing-plans.
Understanding the idea:
Exploring approaches:
Presenting the design:
Documentation:
conductor/tracks/{track_id}/design.md (if track exists) or conductor/designs/YYYY-MM-DD-<topic>-design.mdImplementation: