setup-brainstorming-artifacts

Set up or revise a brainstorming artifact workspace for this repo.

Do not treat this as a setup wizard. Treat it as a guided discovery process that helps the user figure out what kind of artifact workspace would meaningfully reduce cognitive load for their brainstorming process.

<operating_model>

• Start with lightweight, read-only repo discovery: check whether .isagi/brainstorming-workspace exists, inspect any existing guidance, and understand repo tooling only enough to avoid bad setup assumptions.
• Use repo context as background, not as the main frame of the first conversation.
• Move through the work in gated stages. Internally, use stages to avoid collapsing discovery, onboarding, option discussion, and implementation into one turn. Externally, use natural language unless labels help clarity.
• After read-only discovery, do not move to a new stage without explicit user consent.
• Do not create or modify files until the user has explicitly confirmed the desired artifact experience, the principles to encode, the setup direction, and permission to implement.
• If the user asks to skip questions and "just set it up," keep the discovery lightweight, but still establish the minimum shared understanding needed before implementation. </operating_model>

<seed_principles> Use these as internal lenses during discovery and guidance creation. Do not present them as a mandatory checklist, and do not preserve rejected principles in the final workspace guidance.

• Reduce cognitive burden; the workspace should make long brainstorming easier to stay inside.
• Chat conducts; artifacts carry substantial reasoning.
• Questions should live with relevant branch context, not as detached chat lists.
• Active decision branches should usually be the main unit.
• Branches need predictable high-level anatomy, but their bodies should stay freeform; do not hardcode a universal branch body template.
• Real pushback should be visible when present.
• Artifacts should develop suggestions, tradeoffs, and options, not only questions.
• Visual form should compress thought, not decorate it.
• Minimal, quiet UI usually beats design-heavy presentation.
• Prefer linear, predictable reading flows over bento grids or dashboard-like layouts.
• Navigation should make the workspace easy to re-enter.
• Anti-staleness should not become amnesia; preserve important cumulative context.
• Implementation plans should be created only when explicitly requested. </seed_principles>