mk:brainstorming
Compare technical approaches for one validated decision
What This Skill Does
mk:brainstorming compares technically distinct ways to solve one validated problem. It is for the decision “how should we build this?”, while mk:office-hours owns “should we build this?”. It never writes implementation code.
When to Use
- You need multiple technical approaches for a validated requirement.
- You need trade-offs before choosing an architecture or strategy.
- You need to explore failure modes or constraints before planning.
For product discovery or whether an idea is worth building, use mk:office-hours. For a bug's root cause, use mk:investigate. For critique of an existing plan, use mk:plan-ceo-review or mk:elicit.
A bare “brainstorm” request is ambiguous. The skill asks whether the user needs product validation or technical approaches instead of guessing from that word.
Profiles
--depth quick(default): restates the decision, gives 2-4 technical options and a recommendation inline, then stops. It creates no report, plan, wiki candidate, memory entry, or handoff.--depth deep: generates 3-8 approaches, runs one anti-bias pivot and challenge pass, and can score or report findings when requested or needed by an active plan.
Usage
/mk:brainstorming "Compare technical approaches for real-time notifications"
/mk:brainstorming --depth deep "Choose an architecture for audit retention"mk:advise
Turn a raw decision into one honest recommendation after confirming the real problem.
mk:grill
Relentlessly interview the user about their own plan or design — one question at a time — resolving each branch of a decision tree until shared understanding. Claude is the interviewer; the user is the interviewee. Checkpoints every answer to docs/knowledge/<slug>.md so progress survives a context reset, flags unanswerable knowledge as gaps to chase, and ends by offering three handoffs. Read-only on the source doc.