Skill proposal: `/plan-experiment` + `/review-experiment` for demand-side assumption testing

## Proposing a skill pair that slots between `/office-hours` (idea exploration) and `/plan-ceo-review` (scope): design a falsifiable test of the riskiest demand-side assumption, then render a verdict against pre-registered criteria.

## The Gap

gstack's planning gauntlet is strong at scope (`/plan-ceo-review`), architecture (`/plan-eng-review`), design (`/plan-design-review`), DX (`/plan-devex-review`), and idea exploration (`/office-hours`). But there's no layer that forces:

- Stating the riskiest demand-side assumption as a falsifiable claim
- Pre-registering numeric validated / invalidated / inconclusive thresholds **before** running the test
- Rendering a verdict later that resists goalpost-moving and HARKing
- Routing the verdict **back** into `/office-hours` / `/plan-ceo-review` so the upstream docs don't rot

Without this layer, `/office-hours` conviction flows straight into `/plan-ceo-review` scoping, and untested assumptions compound into the build plan.

## Proposed Skills

**`/plan-experiment`** — YC-partner voice. Surfaces the assumptions underneath a bet, picks one as riskiest with defense, designs a minimum viable test (Mom Test interviews / fake door / concierge / pre-sale / smoke test), pre-registers numeric thresholds, writes `EXPERIMENT.md` with hard timebox + explicit out-of-scope list.

**`/review-experiment`** — reads `EXPERIMENT.md` + user evidence, checks sample validity first, compares observation against pre-registered criteria, renders validated / invalidated / inconclusive, names goalpost-moving when it happens, logs surprises as *new hypotheses* (not evidence for this one), and routes back upstream based on verdict type.

### Handoff

| Verdict | Route |
|---|---|
| Validated | → `/plan-ceo-review` (scope) → optionally next-layer `/plan-experiment` |
| Invalidated | → `/office-hours` → `/plan-ceo-review` → `/plan-experiment` |
| Inconclusive + pivot-signal | → `/office-hours` → `/plan-ceo-review` → `/plan-experiment` |
| Inconclusive, no surprise | → `/plan-experiment` (redesign) |
| Invalid test | → `/plan-experiment` (rerun cleanly) |

The insight: **the experiment result should update the upstream planning docs, not just seed the next test**. Otherwise the `/office-hours` doc rots as the founder learns.

## Questions before any PR

1. **Does this fit the roadmap, or is experimentation intentionally out of scope?** (Fine with "`/office-hours`' desperate-specificity question is enough" if that's the answer.)
2. **Naming.** `/plan-experiment` mirrors `/plan-*` but most of the work is design, not planning. Would `/experiment` + `/verdict` fit better? Open.
3. **Scope boundary.** Demand-side only (my current scope) or also technical experimentation (load / latency / architecture spikes)?
4. **Loop closure.** Do you want `/review-experiment` explicitly routing back through `/office-hours` + `/plan-ceo-review`, or should the founder always decide manually?
5. **`/learn` integration.** Should verdicts auto-log as project learnings?