/mindstorming

name: mindstorming
description: Use before drafting any non-code knowledge-work deliverable, including strategic memos, business reviews, OKR defences, PRDs, decision docs, briefing docs, exec talking points, Slack messages to leadership, frameworks, post-mortems, one-pagers, BRDs. Triggers on asks like "help me write up X", "draft this memo", "what should I say to Y", even casually phrased. NOT for software implementation; for creating features, components, or code changes use superpowers:brainstorming instead; for authoring the PRD document itself, use this skill. For non-code deliverables this skill supersedes generic brainstorming. Do not skip for simple asks; simple tasks hide the costliest assumptions.

Mindstorming: Brainstorming for Knowledge Work

Overview

mindpowers does one loop: shape, draft, review, fact-check, and remember what you like. This skill is the "shape" step.

Help turn rough ideas into locked specs for knowledge-work deliverables (memos, business reviews, decision docs, PRDs, briefing docs, comms, frameworks, talking points, post-mortems) through Socratic dialogue.

The skill enforces a verbal design-approval gate and a final approval of the written spec on disk. For routine reuse of a prior locked spec, the user's explicit reuse instruction plus answers to every stated delta satisfies the verbal gate; do not ask for a second verbal approval. Drafting begins only after the applicable verbal gate and the written-spec approval.

Do NOT draft any deliverable, write any prose, or otherwise produce output until you have presented a design, written it to disk, and the user has approved the written spec. This applies to EVERY task regardless of perceived simplicity.

Anti-Pattern: "This is too simple to need a spec"

Every task goes through this process. A Slack reply, a one-paragraph note, a routine update, all of them. Simple tasks are where unexamined assumptions cause the most wasted work and miscommunication. The spec can be short (3-5 lines for trivially simple tasks), but you MUST write it and get user approval.

Shared Reasoning and Language Contract

**Think precisely; respond plainly.** In user-facing responses, prefer common words and short sentences. Explain an unavoidable technical term on first use. When a rule could be misunderstood, give one short, concrete example. If the user says an explanation is unclear, explain it again from scratch rather than defining the same jargon with more jargon.

For a material conclusion about evidence, readiness, a recommendation, or a blocker, give a compact reasoning receipt:

• the recommendation or conclusion;
• what you checked;
• the main reasons;
• what remains uncertain; and
• the next step.

Keep this natural and proportional. Do not dump the internal rubric, expose a scorecard, or turn the response into a checklist.

Before reaching that conclusion, judge evidence internally by:

• relevance to the claim and intended action;
• recency;
• coverage of the stated users and scope;
• reliability, including where it came from and how it was collected;
• limitations; and
• counterevidence or a plausible alternative explanation.

Evidence is sufficient only for a stated scope and the next important action the deliverable is meant to support. Evidence presence, evidence type, directness, or user acceptance does not by itself prove sufficiency. An early, reversible discussion and an irreversible rollout can require different evidence. Use judgment rather than a visible scoring system or one universal sample-size rule. Keep detailed problem-validation methods in `validating-problems`.

Internally track the full set of assumptions that could materially change the claim, direction, scope, product behaviour, measurement, or risk. Do not stop after finding one defensible assumption. In exploratory dialogue, preserve the one-information-target-per-turn rule while resolving that set.

The 10-Step Process

Track these steps as todos if your harness has a task list, and complete them in order:

1. **Explore context.** Check recent specs in `docs/mindpowers/specs/`, sorted by filename descending (the date prefix keeps them in chronological order); read the frontmatter of the 5-10 most recent. Also check `docs/mindpowers/preferences.md` if it exists; it holds per-template-type notes on what this user likes. Also scan legacy `docs/brainstorm/` if it exists; always write new files under `docs/mindpowers/`. If the user supplies a problem brief, or the topic matches one under `docs/mindpowers/problems/`, read it before elicitation and apply the "Optional Problem Brief" rules below. Do not scan unrelated problem briefs. Follow "Source Boundaries" for every other source. 2. **Detect template match.** Does the task fit one of the 9 templates? (See "Template Selection" below.) If yes, load that template's reference file. Also classify: is this routine (a template type with prior locked specs and/or a recorded preference in `preferences.md`) or exploratory (first time, novel or personal topic)? 3. **Offer visual companion (if applicable).** Defer until the dialogue is heading into visually-shaped territory. May not happen at all for text-only tasks. 4. **Adaptive elicitation.** Batched only when template match AND routine. Otherwise one-question-at-a-time. 5. **Propose 2-3 approaches.** When self-shaping, before presenting the design, propose alternatives with trade-offs and your recommendation. (For template-matched routine tasks, this often happens inside the template's elicitation.) 6. **Present design sections.** Scaled to complexity, get verbal approval after each section. Exception: when routine reuse of a prior locked spec is explicit and the user has supplied every stated delta, skip this step entirely: do not present design sections in chat and do not ask another verbal approval question; proceed directly to writing the spec. If the user rejects a structure, invoke Research as Recovery before re