Mk brainstorming

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 only 3+ independently shippable concerns.

Quick Workflow

1. Restate the validated decision and any material assumption.
2. Give 2-4 technically distinct options with the key trade-off for each.
3. Recommend one option and return inline. Do not create a report, plan, wiki candidate, or memory entry.

Deep Workflow

1. Confirm the decision, binding constraint, success criterion, and excluded scope. Ask at most three focused questions when needed.
2. If 3+ independently shippable concerns are bundled, ask to choose one. Use a compact scout summary only when current codebase touchpoints change the decision.
3. Load one technique from references/techniques/; generate 3-8 technical approaches without scoring while generating.
4. Run one anti-bias pivot, then the challenge pass in references/challenge-pass.md before recommending.
5. Load scoring only for deep scoring. Write a report, HTML output, or handoff only when requested or needed by an active plan. For a requested report, an optional mewkit wiki handoff suggest follows .agents/skills/wiki/references/terminal-handoff-advisory.md; it is fail-open and never runs for quick.

--advice (composable, off by default)

Opt-in strategic supervision for one run, deep workflow only. GUIDE fires after the frame and before generation, REVIEW after the challenge pass and before the recommendation reaches the user; hard cap 4.

Athena supplies decision criteria and reads the chosen direction. It never generates the option set, scores it, chooses for the user, or adds a gate.

Without the flag there are zero calls and no state is written.

Checkpoints: references/advice-checkpoints.md. Contract: .agents/skills/rule-advice-supervision/SKILL.md (load only when the flag is present).

References

• references/context-budget.md — deep clarification, count, pivot, and challenge limits
• references/techniques/ — choose one technique for a deep run
• references/challenge-pass.md and references/scoring-criteria.md — deep convergence only
• references/editorial-html.md — HTML only for a requested report
• references/advice-checkpoints.md — --advice checkpoint boundaries, caps, and what supervision may not touch