/cs-grill-bizops

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.