Consolidating the divergence between this repo and local-dev's embedded ~/dev/.skills/ (the two had drifted; the 19 overlapping skills were byte-identical). - Import the 17 skills that existed only in local-dev: discovery-framing, stage-gate-review, web-shot, and the 14 superpowers-* skills. This repo is now the superset / single source of truth. - SKILLS_INDEX.md: add rows for the 17. - install.sh + Taskfile.yml: git.d-ma.be host (was stale gitea.d-ma.be, which broke the one-line curl|bash installer post-rename). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
Claude Opus 4.8
@@ -0,0 +1,147 @@
|
||||
---
|
||||
name: stage-gate-review
|
||||
description: Run or prepare a stage-gate product governance review — the go/no-go checkpoint where a council approves an initiative to advance through fixed innovation stages (Frame → Concept → Prototype → Validate → Scale), each gate guarded by a per-discipline readiness checklist. Use when preparing a Product Council / steering-group ask, building a go/no-go checklist, designing an innovation governance process, or auditing whether an initiative is genuinely ready to advance vs faking the gate. Trigger phrases include "stage gate", "product council", "go/no-go", "advance to the next stage", "is this ready to progress", "gate review", "phase gate", "innovation governance".
|
||||
---
|
||||
|
||||
# Stage-Gate Review
|
||||
|
||||
A governance pattern for moving product/innovation initiatives through fixed stages
|
||||
under explicit go/no-go control. A standing council (or steering group) approves each
|
||||
advance; every gate is guarded by a **per-discipline readiness checklist**. The point
|
||||
is not bureaucracy — it is to kill weak bets early and fund strong ones with conviction.
|
||||
|
||||
This skill is the **transferable pattern**, stripped of any client instance. When a real
|
||||
engagement uses it, the client's council names, internal tooling, stage labels, and named
|
||||
contacts stay inside the client boundary (see *Client instances* below) — never bake them
|
||||
into this skill.
|
||||
|
||||
---
|
||||
|
||||
## The gate ladder
|
||||
|
||||
Five stages, escalating commitment. Each arrow is a council ask.
|
||||
|
||||
| Stage | Question it answers | Funding posture |
|
||||
|-------|---------------------|-----------------|
|
||||
| **Frame** | Is this opportunity worth exploring? | Cheap time only |
|
||||
| **Concept** | Is there a solution worth prototyping? | Small dedicated resource |
|
||||
| **Prototype** | Does the solution work and is the business case real? | Build budget |
|
||||
| **Validate** (market test) | Will a real customer pay / adopt? | Pilot budget + infra |
|
||||
| **Scale** (commercialize) | Should we invest to grow this? | Full commercial investment |
|
||||
|
||||
Key rule: **the earliest gate (Frame → Concept) is usually feedback-only**, not approval.
|
||||
You bring it to the council to sharpen thinking, not to pass judgment — killing ideas at
|
||||
Frame teaches teams to stop framing. Approval pressure starts at Concept.
|
||||
|
||||
The bar rises each gate: hypothesis → tested hypothesis → validated evidence + business
|
||||
case → signed pilot commitment → full commercial commitment.
|
||||
|
||||
---
|
||||
|
||||
## The discipline checklist
|
||||
|
||||
Every gate is a matrix: **the same disciplines, a higher bar each stage.** A gate ask is
|
||||
"ready" only when every applicable discipline clears its bar for that stage. Adapt the
|
||||
discipline set to the domain; this is the default spine.
|
||||
|
||||
| Discipline | What it guards | Rises from Frame → Scale |
|
||||
|------------|----------------|---------------------------|
|
||||
| **Ownership** | A named, committed product owner exists | identified → secured → full commitment to commercialize |
|
||||
| **Strategy fit** | Aligns with org strategy & objectives | alignment asserted → tie to portfolio confirmed |
|
||||
| **Economics** | Revenue + fully-loaded cost through the horizon | rough estimate → validated business case, approved |
|
||||
| **Customer/market evidence** | Real demand, tested with real people | hypotheses commissioned → tested → signed pilot partner |
|
||||
| **Experience / design** | Desirability and usability validated | design lead secured → evaluative testing + quality score |
|
||||
| **Technical feasibility** | Build assumptions reviewed by engineering | assumptions noted → reviewed → infra cost approved |
|
||||
| **Legal / risk / compliance** | Regulatory and contractual exposure surfaced | initial review → SME overviews → docs initiated |
|
||||
| **Go-to-market / region** | Launch market and support model identified | market aware → aligned → support & business model agreed |
|
||||
| **Timeline** | A credible plan to complete the next stage | — |
|
||||
| **System of record** | The initiative is tracked in the canonical tool | — |
|
||||
|
||||
A discipline that clearly doesn't apply gets **explicitly waived** ("no regulatory surface —
|
||||
legal waived"), never silently dropped. Silent omission is the most common way a gate rots.
|
||||
|
||||
---
|
||||
|
||||
## Running a gate review
|
||||
|
||||
**Preparing an ask (you are the team):**
|
||||
1. Identify the target gate and pull its column from the matrix.
|
||||
2. For each discipline, gather the evidence that clears *this stage's* bar — evidence, not
|
||||
intent. "We will test" does not clear a "tested" bar.
|
||||
3. Mark every discipline: cleared / waived (with reason) / gap.
|
||||
4. If any gap is on a discipline that gates the whole bet, **do not bring the ask** — close
|
||||
the gap or bring a feedback-only ask instead.
|
||||
|
||||
**Chairing a review (you are the council):**
|
||||
1. Ask for the evidence behind each "cleared", not the claim. Claims are theatre.
|
||||
2. Probe the one discipline most likely to be faked for this stage (see anti-patterns).
|
||||
3. Decide: advance / hold (named gaps, re-ask) / kill. A council that never kills is a
|
||||
rubber stamp and the gate is worthless.
|
||||
|
||||
---
|
||||
|
||||
## Anti-patterns (gate theatre)
|
||||
|
||||
- **Checklist completion ≠ readiness.** Every box ticked, zero evidence. Demand artifacts.
|
||||
- **The pre-approved gate.** Decision made in the hallway; council ratifies. The gate adds
|
||||
cost and zero filtering.
|
||||
- **Evidence inflation.** "Validated" demand that is one friendly customer's enthusiasm.
|
||||
- **Skipping the kill.** Weak bets get "hold and re-ask" forever instead of a clean death.
|
||||
- **Frame-stage judgment.** Approving/rejecting at Frame teaches teams to stop exploring.
|
||||
- **Bar that never rises.** Same evidence accepted at Prototype as at Frame — the ladder
|
||||
collapses into one gate.
|
||||
|
||||
---
|
||||
|
||||
## Operator judgment (hard-won)
|
||||
|
||||
The matrix above is generic best practice. This section is the part that comes from running
|
||||
real reviews — apply it over the spine.
|
||||
|
||||
### Which gates to collapse, and when
|
||||
- **Low uncertainty + high strategic fit** (you already know the customer wants it): collapse
|
||||
**Prototype + Validate** — build the real thing *as* the pilot. The separate prototype gate
|
||||
buys nothing when desirability isn't the risk.
|
||||
- **Moonshot / high uncertainty**: never skip **Validate** — that's the whole bet. You can
|
||||
skip the formal **Concept** gate (run it feedback-only) but you cannot skip proving demand.
|
||||
|
||||
### Where the gate gets faked — tells by stage
|
||||
- **Concept:** "customer research" that's really 3 friendly stakeholder chats with no
|
||||
disconfirming evidence sought. Worse and more common: a Concept backed only by **selective
|
||||
external research carried over from Frame** — the team cherry-picks the framing-stage
|
||||
evidence that flatters the idea and runs no fresh test. Reused evidence is not validation.
|
||||
- **Validate:** a "signed" pilot that is actually a warm LOI — no money committed, no go-live
|
||||
date. Intent dressed as commitment.
|
||||
|
||||
### Minimum real evidence — calibrate to what the stage *can* know
|
||||
Don't demand certainty a stage can't yield. The honest question is "how much **can** we know
|
||||
at this point?" — and against that bar, **any genuine external signal beats internal
|
||||
conviction**. Often the highest-value move at an early gate is simply getting *the first real
|
||||
evidence at all*, where before there was only opinion. So:
|
||||
- Reject "cleared" that rests purely on internal belief or reused framing evidence.
|
||||
- Accept directional external evidence early; raise the bar to **committed** evidence (paid
|
||||
pilot, money down, a date) by Validate.
|
||||
- **Economics:** distrust a polished Year-3 revenue model. Trust fully-loaded cost plus one
|
||||
defensible near-term number over a confident long-horizon fiction.
|
||||
|
||||
### The two killers (what actually defeats a gate)
|
||||
- **Political pre-commitment.** Some bets management simply *wants*, regardless of evidence.
|
||||
A gate cannot kill what leadership has already decided. Name it when you see it — the gate
|
||||
is theatre on that bet, and pretending otherwise corrodes every other gate.
|
||||
- **Sunk-cost attachment.** You advance the wrong concept, then get too vested to kill it.
|
||||
The antidote is a **scientific mindset with no emotional attachment to the solution**. The
|
||||
disease is **solutions looking for problems to solve** — fall in love with the problem, stay
|
||||
ruthless about the solution. A gate's deepest job is to enforce exactly this detachment.
|
||||
|
||||
> Validated under fire — these belong in the brain as a standalone principle too, so they
|
||||
> outlive this one skill. See [[solution-looking-for-problem]], [[stage-gate-sunk-cost]].
|
||||
|
||||
---
|
||||
|
||||
## Client instances
|
||||
|
||||
When this pattern is instantiated for a named client, the instance is **confidential and
|
||||
stays in the client boundary**:
|
||||
- Council/forum names, internal stage labels, internal tooling, named contacts, strategy
|
||||
specifics, deal terms → client dir/org only, local models only, never the public brain.
|
||||
- This skill carries the **pattern**; the client carries the **wrapper**. Never merge them.
|
||||
Reference in New Issue
Block a user