strategy-review

Strategy Review

Pressure-test strategy documents to find where they'll break before reality does it for you. The primary job isn't to evaluate prose quality or check formatting — it's to find the gaps, hidden failure paths, and under-accounted risks that will kill the strategy in execution. A strategy that survives this review has a meaningfully better chance of surviving contact with the real world.

This skill complements the beagle-analysis:strategy-interview skill. Strategy-interview helps build a strategy through guided conversation; strategy-review subjects an existing strategy to rigorous adversarial evaluation using the same kernel framework (diagnosis, guiding policy, coherent actions) and bad-strategy filter.

What makes this different from generic feedback

Most strategy feedback falls into two useless categories: vague praise ("this is really thoughtful") or surface-level nitpicking ("consider adding a timeline"). Neither helps the author see whether their thinking actually holds up under stress.

This review does three things that generic feedback doesn't:

1. Tests structural integrity — whether the logical chain from diagnosis through guiding policy to coherent actions actually holds together, or whether the "therefore" between them is secretly an "and also."
2. Hunts for failure paths — not just what's wrong with the document, but what goes wrong in the real world because of what's missing. The slow drift scenario, the capability gap that stalls the load-bearing action, the competitor response nobody modeled, the political resistance the strategy pretends doesn't exist.
3. Surfaces invisible assumptions — every strategy is a bet, but most strategies don't name their bets. This review finds the load-bearing assumptions the author hasn't stated and maps the risk of each one being wrong.

Before you start

Read references/review-dimensions.md — it contains the seven evaluation dimensions and their criteria. This is the backbone of the review. Keep it in working memory throughout.

Hard gates (evidence-bound)

These steps are easy to rationalize without evidence; each gate has a pass condition before you advance.

1. Ratings (Step 3). Do not assign Strong, Adequate, or Weak for any dimension until you have at least one of: a quoted or section-referenced passage from the strategy inputs, a strategy-notes.md (or equivalent) cross-reference, or an explicit Missing note stating that no relevant passage exists. Pass: every dimension that is rated has one of those anchors on record (in chat, in dimension-ratings.md if using durable state, or inline in the final review).
2. Critical findings (Step 5). Do not list an item under Critical findings unless it ties to the same kind of anchor (quote, section ref, notes cross-ref, or explicit absence). Pass: no critical finding is only a generic critique with no tie to the document or notes.
3. Judge artifact mode. Order: finalize prose strategy-review.md → derive strategy-review.json from that prose → run the validation checklist in references/judge-artifact-schema.md → emit or save JSON only after the checklist passes (parses, required fields, score arithmetic). Pass: JSON validates and matches the prose labels and evidence.
4. Durable state (when .beagle/.../reviews/.../ exists). Before you call the review complete, ensure review-state.md exists and its current_step and lens/kernel fields match what you actually did (Steps 1–5 and files on disk). Pass: ledger reflects the true step and inputs; if dimension-ratings.md or kernel-extraction.md were created, the final strategy-review.md does not contradict them.

Complementary review lenses

The kernel evaluation (diagnosis, guiding policy, coherent actions) is always the backbone. Four additional lenses load conditionally when the strategy document warrants them. Do not force them. Most reviews use one or two; some use none. A lens loads when the document's content triggers it — not as a mandatory checklist.

Lenses sharpen the existing seven dimensions rather than adding new ones. When a lens reveals a gap, the finding belongs under the relevant dimension. The lens is the tool that found the gap; the dimension is where it lives.

| Lens | When it loads | What it adds | Primary dimensions | |------|--------------|-------------|-------------------| | McKinsey 7S (Execution Alignment) | Strategy requires organizational change — new structure, processes, cultural shift, or cross-functional coordination | Checks whether the strategy accounts for alignment across structure, systems, shared values, style, staff, and skills. The most common gap: the strategy changes direction but assumes the organization will follow. | Dim 3, Dim 6 | | Balanced Scorecard (Objective Translation) | Success criteria are one-dimensional (usually financial only) or vague | Checks whether success is measurable across financial, customer, process, and learning perspectives. Financial metrics are lagging — the strategy needs leading indicators that signal problems before revenue confirms them. | Dim 7 | | Porter's Five Forces (Competitive Pressure Audit) | Diagnosis addresses competitive dynamics — market position, pricing pressure, new entrants, substitution risk | Checks whether the diagnosis saw the full competitive picture, not just direct rivalry. Many strategies diagnose one force while ignoring the others. | Dim 1 | | Hoshin Kanri (Strategy Deployment) | Strategy involves multiple organizational levels — actions need to cascade from executive intent to team execution | Checks whether actions survive translation from strategy to operations. Strategy fails at the translation layers — each level of the org loses fidelity. | Dim 3 |

Lens selection happens during Step 2 (reading and extracting the kernel). After identifying the kernel elements, mentally check each lens trigger. Load references/review-lenses.md for the relevant lenses and weave their pressure-test questions into the Step 3 dimension evaluation.

The reviewer uses lens thinking to find gaps — not lens vocabulary to lecture the user. A finding that says "the strategy changes direction but doesn't address whether the current org structure supports the new approach" is a 7S-informed finding. The user doesn't need to know it came from McKinsey's framework.

Review workflow

Step 1 — Gather the documents

Ask the user what they want reviewed. Typical inputs:

• strategy-draft.md + strategy-notes.md — the pair produced by strategy-interview. The notes file dramatically enriches the review because it contains assumptions, open questions, and the reasoning journey. Always ask for both if only one is provided.
• A standalone strategy document — any doc that claims to be a strategy. Could be a Google Doc paste, a PDF, a deck summary, or a markdown file.
• A slide deck or brief — extract the strategic claims and evaluate those. Don't critique slide design.

If the document is ambiguous about what it's trying to be (strategy? plan? vision? goals?), name it: "This reads more like a goals document than a strategy — it describes what you want to achieve but not the theory of how. Want me to review it as-is, or should we first identify the missing strategic elements?"

Check the working directory for existing strategy files before asking the user to provide them — they may have already been produced by a previous strategy-interview session.

Step 2 — Read and extract the kernel

Read the full document. Identify (or note the absence of) the three kernel elements:

1. Diagnosis — What does the document say is actually going on? Is there a clear statement of the challenge?
2. Guiding policy — What overall approach has been chosen? Does it make a directional choice?
3. Coherent actions — What concrete steps carry out the policy? Do they reinforce each other?

If the d