feat(brainstorming): v0.1.0 — divergent phase adapted from obra/superpowers @ 6.2.0 (visual-companion dropped); trig: «забрендшторми», «поштормим», «накидай идеи»

README.md

@@ -114,6 +114,7 @@ an explicit `adapted-from` marker in its frontmatter.
 | `caveman`, `caveman-commit`, `caveman-compress`, `caveman-help`, `caveman-review` | `adapted-from: JuliusBrussee/caveman` (MIT) — vendored copy, upstream pin TBD |
 | `find-skills` | `adapted-from: vercel-labs/skills` (MIT) — vendored copy, upstream pin TBD |
 | `grilling` | `adapted-from: mattpocock/skills @ 84fdeffd` (MIT) — family collapsed to one skill (pi hides `disable-model-invocation` wrappers) |
+| `brainstorming` | `adapted-from: obra/superpowers @ 6.2.0` (MIT) — divergent phase, visual-companion dropped |
 | all other `skills/*` | `author: ours` |
 
 Adaptation policy: a clone is rewritten to our conventions (`.tasks/` boards,

README.ru.md

@@ -84,6 +84,7 @@ bash scripts/build.sh caveman          # один
 | `caveman`, `caveman-commit`, `caveman-compress`, `caveman-help`, `caveman-review` | `adapted-from: JuliusBrussee/caveman` (MIT) — вендорная копия, пин апстрима TBD |
 | `find-skills` | `adapted-from: vercel-labs/skills` (MIT) — вендорная копия, пин апстрима TBD |
 | `grilling` | `adapted-from: mattpocock/skills @ 84fdeffd` (MIT) — семейство схлопнуто в один скил (pi прячет `disable-model-invocation` обёртки) |
+| `brainstorming` | `adapted-from: obra/superpowers @ 6.2.0` (MIT) — расходящаяся фаза, visual-companion выброшен |
 | остальные `skills/*` | `author: ours` |
 
 Политика адаптации: клон переписывается под наши конвенции (доски `.tasks/`,

skills/brainstorming/SKILL.md

@@ -0,0 +1,181 @@
+---
+name: brainstorming
+adapted-from: obra/superpowers @ 6.2.0 (MIT)
+version: 0.1.0
+description: >
+  The divergent phase of the design cycle: take a raw idea and explore it into a
+  sharpened design through collaborative dialogue — questions one at a time,
+  then 2-3 approaches with trade-offs, then a presented design the user approves
+  before any implementation. Trigger (user): «забрендшторми», «поштормим», «накидай идеи»,
+  «что думаешь про идею», «есть идея, давай поразмышляем», "brainstorm this",
+  "help me think through", "what should we build". NOT a recommendation
+  (→ recommend-dont-menu), NOT a stress-test of a finished plan (→ grilling).
+---
+
+# Brainstorming
+
+Turn a raw idea into a fully formed design through natural collaborative
+dialogue. This is the **divergent phase** of the three-phase cycle:
+
+1. **Brainstorming** (this skill) — explore intent, diverge, present a design
+2. **Discussion** — recommend-dont-menu as the style of the agent's moves
+   (one position, not a menu)
+3. **Grilling** — convergent phase, sharpen the design into an implementable
+   plan («хватит, к промоушену» / "enough, sharpen it" — the switch)
+
+The terminal state of this skill is **an approved design** — then grilling (or
+the promotion pipeline) takes over. It does NOT write code.
+
+<HARD-GATE>
+Do NOT write code, scaffold a project, invoke an implementation skill, or take
+any implementation action until you have presented a design and the user has
+approved it. This applies to EVERY request regardless of perceived simplicity.
+</HARD-GATE>
+
+## Anti-Pattern: "This Is Too Simple To Need A Design"
+
+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.
+
+## Checklist
+
+Complete these in order:
+
+1. **Explore project context** — check files, docs, recent commits. Don't
+   propose changes to a codebase you haven't looked at.
+2. **Ask clarifying questions** — one at a time, understand
+   purpose/constraints/success criteria.
+3. **Propose 2-3 approaches** — with trade-offs and your recommendation.
+4. **Present design** — in sections scaled to their complexity, get user
+   approval after each section.
+5. **Write design doc** — save to the project's spec location (below), commit.
+6. **Spec self-review** — inline check for placeholders, contradictions,
+   ambiguity, scope (see below).
+7. **User reviews written spec** — ask the user to review the spec file before
+   proceeding.
+8. **Transition** — to grilling (convergence) or the promotion pipeline.
+
+## The Process
+
+**Understanding the idea:**
+
+- Check out the current project state first (files, docs, recent commits).
+- Before asking detailed questions, assess scope: if the request describes
+  multiple independent subsystems, flag it immediately. Don't spend questions
+  refining details of a project that needs to be decomposed first.
+- If the project is too large for a single spec, help the user decompose into
+  sub-projects: what are the independent pieces, how do they relate, what order
+  should they be built? Then brainstorm the first sub-project through the
+  normal flow. Each sub-project gets its own spec cycle.
+- For appropriately-scoped projects, ask questions **one at a time**. Prefer
+  multiple choice questions when possible, but open-ended is fine too.
+- Focus on understanding: purpose, constraints, success criteria.
+
+**Exploring approaches:**
+
+- Propose 2-3 different approaches with trade-offs. Lead with your
+  recommended option and explain why.
+- Present options conversationally, not as a menu (recommend-dont-menu style:
+  one position, argued).
+- YAGNI ruthlessly — remove unnecessary features from every approach.
+
+**Presenting the design:**
+
+- Once you believe you understand what's being built, present the design.
+- Scale each section to its complexity: a few sentences if straightforward,
+  up to 200-300 words if nuanced.
+- Ask after each section whether it looks right so far.
+- Cover: architecture, components, data flow, error handling, testing.
+- Be ready to go back and clarify if something doesn't make sense.
+
+**Design for isolation and clarity:**
+
+- Break the system into smaller units that each have one clear purpose,
+  communicate through well-defined interfaces, and can be understood and tested
+  independently.
+- For each unit, you should be able to answer: what does it do, how do you use
+  it, and what does it depend on?
+- Can someone understand what a unit does without reading its internals? Can
+  you change the internals without breaking consumers? If not, the boundaries
+  need work.
+- Smaller, well-bounded units are also easier for you to work with — you reason
+  better about code you can hold in context at once, and your edits are more
+  reliable when files are focused. When a file grows large, that's often a
+  signal that it's doing too much.
+
+**Working in existing codebases:**
+
+- Explore the current structure before proposing changes. Follow existing
+  patterns.
+- Where existing code has problems that affect the work (a file grown too
+  large, unclear boundaries, tangled responsibilities), include targeted
+  improvements as part of the design.
+- Don't propose unrelated refactoring. Stay focused on what serves the current
+  goal.
+
+## Spec location
+
+Where the design doc goes (per project-discipline Rule 1 — specs → wiki):
+
+- regular project → `.wiki/concepts/<topic>-design.md`
+- workshop zone → `.brainstorm/<topic>.md` (running record), then the
+  promotion pipeline takes over (workshop-promote-brainstorm)
+- user preference overrides the default
+
+Commit the design document to git.
+
+## Spec Self-Review
+
+After writing the spec, look at it with fresh eyes:
+
+1. **Placeholder scan** — any "TBD", "TODO", incomplete sections, or vague
+   requirements? Fix them.
+2. **Internal consistency** — do any sections contradict each other? Does the
+   architecture match the feature descriptions?
+3. **Scope check** — is this focused enough for a single implementation plan,
+   or does it need decomposition?
+4. **Ambiguity check** — could any requirement be interpreted two different
+   ways? If so, pick one and make it explicit.
+
+Fix any issues inline. No re-review — just fix and move on.
+
+## User Review Gate
+
+After the self-review passes, ask the user to review the written spec before
+proceeding:
+
+> "Spec written and committed to `<path>`. Please review it and let me know if
+> you want any changes before we move to convergence."
+
+Wait for the user's response. If they request changes, make them and re-run the
+self-review. Only proceed once the user approves.
+
+## Transition
+
+Once the design is approved and the spec is reviewed:
+
+- if the design still has open decisions or needs sharpening → invoke
+  **grilling** («хватит, к промоушену» / "enough, sharpen it")
+- otherwise → the promotion pipeline / task creation takes over
+  (workshop-promote-brainstorm in the workshop zone)
+
+Do NOT skip to implementation just because the design is approved — the
+convergent phase is what turns a design into an implementable plan.
+
+## Cross-agent applicability
+
+Pure dialogue methodology — no harness-specific tool references. Works on pi,
+Claude, or any agent. The spec-location line references our project-discipline
+convention; on a different setup, follow that project's own wiki/spec layout.
+
+## Out of scope
+
+- Does NOT stress-test a finished plan (that's grilling).
+- Does NOT give a single recommendation on demand (that's recommend-dont-menu).
+- Does NOT write code or invoke implementation skills — the HARD-GATE holds
+  until the user approves the design.
+- No visual companion / browser mockup server (upstream has one; we skip it —
+  if a visual question genuinely needs showing, offer a sketch/diagram in the
+  doc instead).