strategy-review

What this skill does

# 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 [strategy-interview](../strategy-interview/SKILL.md) 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