---

description: Matt Pocock-style docs-anchored grilling for a BizOps plan or design. Walks the user's plan against the BizOps canon (Lean, Theory of Constraints, Gartner TPRM, DORA) one question at a time, recommends an answer per question, and refuses to invoke any sub-skill until the lane-defining decisions are locked. Use before running /cs:bizops on a fuzzy plan. argument-hint: "<plan, design, or fuzzy problem statement>"

/cs:grill-bizops — BizOps grill against the canon

Apply Matt Pocock's grill-with-docs discipline to this BizOps plan / problem:

$ARGUMENTS

Five rules (preserved from Matt Pocock, MIT)

1. One question per turn. Never bundle.
2. Recommend an answer with each question. Defaulting to "what do you think?" is lazy.
3. Explore the workspace before asking. If Glob/Read/Grep resolves it, do that first.
4. Walk the decision tree depth-first. Finish a branch before opening another.
5. Track dependencies. Resolve A before B if B depends on A.

The BizOps decision tree (depth-first)

Walk these branches in order. Skip a branch only if the workspace already resolves it.

Branch 1 — Which lane?

• PROCESS / VENDOR / CAPACITY / COMMS / KNOWLEDGE / PROCUREMENT
• Canon source: this skill's signal table + references/ per lane

Branch 2 — Measurement state

For PROCESS: "Do you have measured cycle times per stage, or estimates?" — Recommended: insist on measured for top-3 longest stages. Anti-pattern (Goldratt 1984): map estimates → optimize wrong constraint.

For VENDOR: "Tier-1 threshold — spend or operational dependency?" — Recommended: operational dependency. Anti-pattern (Target/HVAC breach, Verkada): spend-only tiering misses critical low-spend vendors.

For CAPACITY: "Plan for utilization or throughput?" — Recommended: throughput (Little's Law). Anti-pattern (DORA): planning for utilization > 80% destroys throughput.

For COMMS: "Push or pull comms?" — Recommended: depends on change magnitude. ADKAR model (Hiatt 2006): high-uncertainty change needs push + 7+ touchpoints.

For KNOWLEDGE: "SOP or runbook?" — Recommended: SOP if humans, runbook if 50% automated. Atlassian/Google SRE distinction.

For PROCUREMENT: "Spend or supplier consolidation goal?" — Recommended: consolidation if Pareto says top-20% suppliers = 80% spend. Else spend categorization.

Branch 3 — Owner + accountability

"Who owns this when the recommendation lands?" — Recommended: named human, not a team. Anti-pattern: 'the ops team owns it' = no one owns it.

Branch 4 — Reversibility

"Is this decision reversible in < 30 days at < $X cost?" If no, propose an ADR (per Matt's grill-with-docs ADR criteria: hard to reverse + surprising-without-context + real trade-off).

Branch 5 — Now invoke the sub-skill

Only after branches 1-4 are resolved, invoke /cs:bizops to route to the right sub-skill.

Output format per turn

Q[i]/[total resolved branches]: [precise question]
Recommended: [answer + 1-sentence canon-cited rationale]

(Confirm, or override?)

Stop conditions

• All branches resolved → invoke /cs:bizops <synthesized inquiry>
• User says "stop grilling, just run it" → invoke /cs:bizops with whatever's resolved, flag the unresolved branches in the digest
• User abandons → no sub-skill invocation, save the partial grill to bizops-grill-{timestamp}.md

Distinct from

• engineering/grill-me (Matt Pocock) — generic plan grilling, no domain canon
• engineering/grill-with-docs (Matt Pocock) — codebase + ADR-anchored grilling for engineering. This is BizOps-domain grilling.
• /cs:bizops — that executes the routing. This interrogates before executing.