Strategic Review

Strategic Review

Pressure-test whether a project has a defensible strategic position before it goes public. The output is an honest read on vision, positioning, and market — what's strong, what rests on unproven assumptions, and where the wedge is closing — ending in strategic options with trade-offs and a recommendation (not flattery, and not a single forced verdict unless asked).

This is the strategy lens. For what's actually built and whether it works, run project-review; the two compose into a full pre-public review (see templates/full-review-prompt.md).

First: match the response to the size of the question

Not every positioning question is a strategic review, and running the five steps below on a small one is the most common way this skill makes an answer worse than no skill at all.

The test is what the user asked you to produce, not how uncertain they sound.

• They asked for a specific small artifact — a tagline, a headline, a benefit bullet, a word choice, one competitor comparison. Deliver that artifact.
• They asked about the position itself — "what makes us different", "is this space too crowded", "are we ready to go public". That is the review. Run it, even though no document was named.

For the small case: write the words, in the same response. Pick the option, draft the copy, give the one-line reason. Do not make it conditional on research the user has not been asked for — where the positioning is genuinely unclear, name the reading you assumed and answer under it. This is not a gate on delivering: state the assumption and deliver in the same reply. A draft they correct beats a question they have to go away and answer.

Then name the strategic question in a sentence or two, if there is one. "Every competitor already claims fast, so that word cannot differentiate you" is this skill's real contribution to a copy question, and it belongs in the answer.

What does not belong is the apparatus. No market scan, no thesis statement, no strategic forks table, no discovery-data request, no "give me your win/loss notes first" — unless the user asked for the review, or the small question genuinely cannot be answered without it. Offer the review; do not start it: one line on what it would cover and what it needs, and let them choose. Steps 1-5 describe that review and begin only once it has been asked for.

Exit condition, said in the reply itself: "Here are the tagline and the three bullets. The underlying question is that 'fast' is table stakes in your category — I can run the full positioning review on that if you want it."

Ground rule: a thesis is a claim, not a fact

State the project's strategic thesis in one sentence, then treat every load-bearing assumption inside it as a claim to be tested, not granted. The most valuable thing this review produces is naming the assumption the whole strategy rests on — and whether there's evidence for it. Mark every market finding confirmed (cited source, dated) or inferred, and date-bound everything ("as of ") because the competitive landscape moves.

Step 1: Articulate and critique the vision

Extract, from the project's own materials, the core narrative:

• Vision / mission — what change in the world, for whom.
• Value proposition — the specific job it does and why someone switches to it.
• The thesis — the one-sentence bet (e.g. "developers will adopt a neutral standard layer because they run multiple tools and feel the lock-in pain").

Then critique it: Is the value proposition concrete or aspirational? Is the target user real and reachable? Which assumption is load-bearing, and is it proven? (How many users actually have the pain? Would they pay / switch / adopt?)

Step 2: Scope and positioning

• Positioning — what band does this compete in, and against what? Where does it sit relative to incumbents and to the platforms it runs on?
• The defensible wedge — what can this do that the obvious larger players won't or can't, and how durable is that? Separate a real moat (standard, network, data, switching cost) from a temporary head start.
• Where positioning is strong vs. where it leans on unproven assumptions — be explicit about the difference.

Step 3: Market comparative analysis (live)

Survey the field with current evidence, not memory:

• Refresh the known bands — for each established competitor band, who's in it now and what shipped recently.
• Hunt for new entrants — date-bound searches for products that appeared recently in this space, adjacent standards, and platform features that may absorb the category.
• For a deep, multi-source, fact-checked sweep, delegate to deep-research and fold its cited report in. For a lighter pass, use WebSearch/WebFetch directly. (This skill runs in a forked context — if the deep-research skill is not invocable from here, do the lighter pass yourself and note under Open questions that a deep-research sweep is the recommended follow-up.)
• Tag each comparable with its relationship: competitor, complement, or integration target — and what it means for this project.
• Label every finding confirmed-vs-inferred and date it.

Step 4: Trajectory and wedge-closure risk

The dangerous competitor is often the platform, not a peer. Assess:

• Absorption risk — is a larger platform shipping features that close the wedge? What's the trajectory over the last 6–12 months?
• Timing — is the window opening or closing, and what evidence says so?
• What would invalidate the thesis — name the observable event that would mean "stop."

Step 5: Synthesis — potential, weak points, strategic forks

Integrate the above into a decision instrument:

• Potential — the genuine strengths and the conditions under which the bet pays off.
• Weak points, ranked — lead with the assumption most likely to be false.
• Strategic forks — present 2–4 distinct paths (e.g. double down / narrow scope / reposition / pivot), each with its trade-offs, then name a recommended path and why. Configurable: if the user wants options only or a hard go/no-go, honor that — default is options + a recommendation.
• A readiness picture mapped to the project's own gates, if it has them.

Write the full review to a file — default a gitignored path (e.g. .local/strategic-review-<date>.md) — and state its path in your final summary. This skill runs in a forked context: only the summary returns, everything unwritten is lost. The summary leads with the thesis verdict and the top weak point, and carries the strategic forks and the recommended path inline — state them in the reply itself, not as a promise of what the written review will contain. This is not a gate on writing the file: write it and put the forks and the recommendation in the summary. A reply that defers them to the file has withheld the deliverable — the file may go unread, and in a forked context the summary is what the user actually receives. Anything that needs the user's judgment (their risk appetite or time horizon, an unverifiable market assumption, missing vision docs) goes in an Open questions section of the report and is mentioned in the summary — never silently decided. Recommending a fork is not one of these. Step 5 requires you to name a recommended path and why; the user decides whether to take it. Filing the recommendation itself under Open questions is the one thing this section must not do — it withholds the deliverable the review exists to produce.

For the rendered deliverable (interactive HTML, scorecards, a forks comparison panel), hand off to artifact-design.

Principles Applied

• Honesty over hype — surface the uncomfortable finding first; a review that validates the founder's optimism is worse than none.
• Assumptions are the product — the review's value is naming what must be true.
• Current and cited — date-bound, confirmed-vs-inferred, sourced.
• Options with a recommendation — give the decision-maker the forks and a view.

Cross-Skill References

• project-review — the execution half of a pre-public review (roadmap, implementation, evidence).
• deep-research — for the deep, fact-checked market fan-out; fold its report into Step 3.
• project-proposal — when the question is a forward-looking go/no-go business case, not a review.
• metrics-and-okrs — to convert the readiness picture into measurable gates.
• artifact-design — to render the review as a polished interactive decision instrument.