mkbrainstorming

# Brainstorming Use for generating or comparing multiple technical approaches to one validated decision. **Boundary:** `mk:office-hours` answers “should we build this?”; this skill answers “how should we build it?” A bare “brainstorm” request is ambiguous: ask whether the user wants product discovery/validation or technical approaches. Do not route from that word alone. ## Profiles - **quick** / `--depth quick` (default) — restate the decision in one line; give 2-4 technically distinct options and one recommendation. If a material fact is missing, state the assumption rather than running discovery. Return inline and stop. Do not load techniques, scout, scoring, challenge, reports, plans, wiki candidates, memory, or handoff. - **deep** / `--depth deep` — load the needed technique and use the deep workflow below. A report, HTML output, or handoff is optional and only produced when requested or needed by an active plan. ## Routing | Situation | Route | | --- | --- | | New product, feature, or side-project value is unvalidated | `mk:office-hours` | | Observed failure or root-cause work | `mk:investigate` | | Existing plan, verdict, or brainstorm needs critique | `mk:plan-ceo-review` or `mk:elicit` | | Generic Q&A or a single implementation detail | answer directly or use `mk:docs-finder` | ## Defaults Use at least two alternatives. Quick returns 2-4; deep generates 3-8 and never more than 8. Keep multiple dimensions in one run when they serve one decision or report; split...