---
name: platform-init
description: "Product-agnostic Phase-0 orchestrator. Takes a 1-line product hypothesis + named competitors and chains: capability-map (parallel per competitor) → asset-survey → wedge-synthesis → user gate 1 → PRD generation → user gate 2 → product scaffold. Produces a ready-to-build product directory with WEDGE-AND-CAPABILITIES.md, capabilities.yaml, PRD.md, CLAUDE.md (scope-fenced), and ARCHITECTURE.md skeleton. Two human approval gates only; everything else autonomous. Works for ANY product. Activates on /platform-init, platform-init <name>, scaffold a new product, start a new AutoPilot product."
---

# /platform-init — generic Phase-0 orchestrator

You orchestrate the full Phase-0 sequence for a new product: research →
synthesis → human gate → PRD → human gate → scaffold. After this skill
completes, the product is ready for Phase-0.5 (architecture-design, another
skill) and then the autonomous build loop.

**Doctrine:**
- [`AGENTS.md`](../../../../AGENTS.md) — Kohlex doctrine
- [`PLATFORM/AutoPilot/.planning/design/2026-05-15-autopilot-design.md`](../../.planning/design/2026-05-15-autopilot-design.md) §1 + §2
- [`PLATFORM/AutoPilot/skills/capability-map/SKILL.md`](../capability-map/SKILL.md) — per-competitor research subagent
- [`PLATFORM/AutoPilot/skills/wedge-synthesis/SKILL.md`](../wedge-synthesis/SKILL.md) — wedge + dependency graph builder
- [`PLATFORM/AutoPilot/templates/product-CLAUDE.md.template`](../../templates/product-CLAUDE.md.template) — scope-fenced agent contract scaffold
- [`PLATFORM/AutoPilot/templates/PRD.md.template`](../../templates/PRD.md.template) — PRD scaffold

## Invocation

```
/platform-init <product-name> \
  --hypothesis "<one-line>" \
  --competitors <name1>,<name2>,...    # 1+ competitor names
  [--target-users "<persona>"]
  [--success-metrics "<metric1>; <metric2>"]
  [--dry-run]                          # produce everything in a sandbox; no commits, no scaffold
```

`<product-name>` is the canonical name — used as the directory under `PLATFORM/`,
as the slug, and as the product reference in all generated docs.

## Inputs (REQUIRED — STOP if missing)

| Input | Purpose |
|---|---|
| `product_name` | The product (becomes `PLATFORM/<product_name>/`) |
| `hypothesis` | One sentence: what is this product going to do? |
| `competitors` | 1+ named competitors (becomes per-competitor capability-map inputs) |

Optional:

| Input | Purpose |
|---|---|
| `target_users` | Persona (refined by `wedge-synthesis` §3) |
| `success_metrics` | What "good" looks like (informs `value` scoring in capabilities.yaml) |

## Output (a complete Phase-0 product directory)

After this skill completes and both human gates pass:

```
PLATFORM/<product-name>/
├── CLAUDE.md                              # scope-fenced agent contract (from template)
├── README.md                              # 1-paragraph what-is + 5-step quickstart
└── .planning/
    ├── manifest.yaml                       # GSD manifest pointing at PRD, ARCHITECTURE
    ├── INTENT.md                           # 1-paragraph intent (user-authored at gate 1)
    ├── DOCTRINE.md                         # from PLATFORM/AutoPilot/.planning/DOCTRINE.md
    ├── PRD.md                              # generated, locked at gate 2
    ├── ARCHITECTURE.md                     # SKELETON only (Phase 0.5 fills it)
    ├── WEDGE-AND-CAPABILITIES.md          # generated, locked at gate 1
    ├── capabilities.yaml                  # generated, locked at gate 1
    ├── <YYYY-MM-DD>-<product>-<competitor1>-outline.md
    ├── <YYYY-MM-DD>-<product>-<competitor2>-outline.md
    ├── ... (one per competitor)
    └── ASSET-SURVEY.md                    # generated, what internal capabilities can be reused
```

## Phase flow (the actual sequence this skill runs)

```
┌─────────────────────────────────────────────────────────────────────────┐
│  Step 1: Validate inputs + create scratch dir                           │
├─────────────────────────────────────────────────────────────────────────┤
│  Step 2: Spawn N parallel capability-map subagents (one per competitor) │
│          Each writes <YYYY-MM-DD>-<product>-<competitor>-outline.md     │
├─────────────────────────────────────────────────────────────────────────┤
│  Step 3: Run asset-survey subagent → ASSET-SURVEY.md                    │
│          (existing internal skills, hooks, services, datasets the product│
│           can reuse from rfi-01)                                         │
├─────────────────────────────────────────────────────────────────────────┤
│  Step 4: Run wedge-synthesis subagent → WEDGE-AND-CAPABILITIES.md +     │
│          capabilities.yaml                                              │
├─────────────────────────────────────────────────────────────────────────┤
│  Step 5: ▶ USER APPROVAL GATE 1 ◀  AskUserQuestion                      │
│          Show wedge + capability matrix; user approves, rejects, or     │
│          tweaks. If rejected → STOP with reason; user re-invokes with   │
│          adjusted inputs. If tweaked → spawn wedge-synthesis again with │
│          user's amendments and re-gate. If approved → set lock_hash in  │
│          capabilities.yaml.                                             │
├─────────────────────────────────────────────────────────────────────────┤
│  Step 6: PRD-generation subagent → PRD.md                                │
│          Derives PRD from approved wedge + capabilities.yaml + asset    │
│          survey. Format: problem, users, scope (P1 in/out), success     │
│          metrics, constraints, risks, milestones.                       │
├─────────────────────────────────────────────────────────────────────────┤
│  Step 7: ▶ USER APPROVAL GATE 2 ◀  AskUserQuestion                      │
│          Show PRD. User approves, rejects, or tweaks. Same loop as      │
│          gate 1.                                                        │
├─────────────────────────────────────────────────────────────────────────┤
│  Step 8: Scaffold the product directory                                  │
│          - mkdir PLATFORM/<product>/ + .planning/                       │
│          - Move all generated files into final paths                    │
│          - Copy product-CLAUDE.md.template → CLAUDE.md, substitute       │
│            <product> name + scope-fence paths                           │
│          - Copy ARCHITECTURE.md.template (skeleton only — Phase 0.5     │
│            fills it)                                                    │
│          - Write README.md (1-paragraph what-is + 5-step quickstart)    │
│          - Write .planning/manifest.yaml                                 │
├─────────────────────────────────────────────────────────────────────────┤
│  Step 9: Commit on a feature branch                                     │
│          Branch: <product>/phase-0-scaffold                             │
│          Commits (atomic):                                              │
│            spec(<product>): capability-maps for <competitor> x N        │
│            spec(<product>): asset survey                                │
│            plan(<product>): wedge-synthesis output (locked at gate 1)   │
│            plan(<product>): PRD (locked at gate 2)                      │
│            chore(<product>): scaffold directory                         │
│          Push, open draft PR for human review.                          │
├─────────────────────────────────────────────────────────────────────────┤
│  Step 10: Return summary                                                │
│          Report: PR URL, product path, capabilities count + phase split,│
│          next-step pointer to /architecture-design (Phase 0.5)          │
└─────────────────────────────────────────────────────────────────────────┘
```

## Steps — detail

### Step 1 — Validate inputs + create scratch dir

If `<product_name>` already exists at `PLATFORM/<product_name>/` → STOP and
ask user: re-init (destroy existing) / abort / use a different name.

If `<hypothesis>` > 200 chars → STOP, the wedge constraint won't survive.

If competitors list is empty → STOP. Phase 0 requires ≥1 named competitor to
research against.

Create scratch dir at `PLATFORM/<product>/.planning/` (or a tmp path in
`--dry-run` mode).

### Step 1.0 — Identity prompt-once (before validation continues)

**Why this step exists:** Piper needs to know three things before she can
speak in the right voice for the rest of this session and every session after:
her own name, who she's working with, and which product she's building toward.
This is one conversation — not three settings prompts.

Prompt ONCE using a single sequential exchange (not three separate
`AskUserQuestion` calls). The operator answering these three questions is the
only identity setup they'll ever need to do — re-running `/platform-init`
updates all three idempotently.

```
What should I call myself?
  (Press Enter to keep the default — I'll go by "Piper"): ___

And what should I call you?
  Your name or handle: ___

GSD project slug for this product?
  (Confirm or change — default: <product_name>): ___
```

**Default-accept rules (owning the bug workaround — see ADR-002 #39455/#46477):**

- `PIPER_NAME`: empty or whitespace input → store `"Piper"`. Never ask again.
  The Claude Code platform does NOT prompt userConfig on enable and does NOT
  support a `default` field — AutoPilot owns this default-accept.
- `OPERATOR_NAME`: empty input → store `""` (address generically; no crash).
- `GSD_PROJECT`: empty input → store the `<product_name>` slug from the
  invocation argument.

**Write resolved values to `.autopilot-userconfig.json`** (idempotent):

```sh
# Path: ${AUTOPILOT_ROOT}/.autopilot-userconfig.json
# (AUTOPILOT_ROOT defaults to PLATFORM/AutoPilot/ from cwd)
# Re-running /platform-init overwrites — this is the intended behavior.
# At M4 (plugin extraction), these values route into plugin.json userConfig.
{
  "PIPER_NAME": "<resolved name or 'Piper'>",
  "OPERATOR_NAME": "<resolved name or ''>",
  "GSD_PROJECT": "<resolved slug>"
}
```

**Schema source-of-truth:** `PLATFORM/AutoPilot/skills/_shared/userconfig-schema.json`
(frozen by ADR-002). Field names copied verbatim — no rename at M4.

**Consumer:** `PLATFORM/AutoPilot/skills/_shared/identity.js` — `loadUserConfig()`
reads `.autopilot-userconfig.json` at call time; `resolveName()` returns the
stored name (defaulting to "Piper" on missing/whitespace).

**Step 5.5 note:** The GSD bootstrap in Step 5.5 passes `GSD_PROJECT` to
`/gsd:new-project --product`. It now SEEDS this value from the identity capture
above rather than prompting for it again. If `GSD_PROJECT` was already captured
here, Step 5.5 uses it directly (no duplicate prompt).

**Voice (Piper speaking to the operator for the first time):**

> Hi — I'm about to help you build [product_name]. A couple of quick things
> before I get to work.
>
> What should I call myself? Press Enter to keep "Piper", or type a different
> name if you'd like.
>
> And what should I call you?
>
> I've got [product_name] as the project slug — press Enter to confirm or
> change it.

**Profile picker — attached to the SAME identity exchange (Step 1.0 only, one conversation):**

After the three identity values are confirmed but before writing the file, ask one additional question:

```
What type of project is this?

  A — Solo, no-backend      (indie game, CLI tool, library)
  B — Solo SaaS with deploy (one dev + a live product)
  C — Small team SaaS       (2–5 devs shipping together)
  D — Polyglot monorepo     (multiple services/languages — DEFAULT)
  E — Enterprise/regulated  (HIPAA, SOC2, FedRAMP, or multi-team)
  F — Open-source library   (community-maintained, no deploy)

  Press Enter to pick D, or type A–F: ___
```

**Default-accept rule:** empty or unrecognised input → store `"D"`.
Lower-case input is accepted (a–f normalised to A–F).

This answer determines which discipline gates BLOCK vs WARN vs SKIP for this
operator's product. It is consumed by `gate-loudness.js`:

```js
import { gateLoudness } from "../_shared/gate-loudness.js";
// called at gate time, e.g.:
const loudness = gateLoudness(profile, "voice"); // → "BLOCK"|"WARN"|"SKIP"
```

Full gate-loudness table: `PLATFORM/AutoPilot/docs/doctrine/PROJECT-PROFILES.md`.

**Write `PROJECT_PROFILE` into the SAME `.autopilot-userconfig.json` write as the other identity values (one idempotent write, not a second settings prompt):**

```sh
# Complete identity write — all four values, one atomic write:
{
  "PIPER_NAME": "<resolved name or 'Piper'>",
  "OPERATOR_NAME": "<resolved name or ''>",
  "GSD_PROJECT": "<resolved slug>",
  "PROJECT_PROFILE": "<A|B|C|D|E|F — default 'D'>"
}
```

After writing `.autopilot-userconfig.json`, confirm in Piper's voice:

> Got it — I'm [PIPER_NAME], you're [OPERATOR_NAME or "you"],
> we're building [GSD_PROJECT], and I'll tune my discipline gates
> for a [full profile label, e.g. "polyglot monorepo"] project.
> Let's go.

(If this is a `--dry-run`, skip the file write and note what would be stored.)

### Step 1.1 — Write autoUpdate:true into extraKnownMarketplaces (DIST-3)

**Why this step exists:** Third-party Claude Code marketplaces default `autoUpdate: false`.
Without this write, a cold-install operator who installs AutoPilot once will silently rot
on V1 forever — Claude Code will never refresh the marketplace or advance the installed
plugin version.

**What this step does (ADDITIVE MERGE — never clobbers other settings keys):**

Using the same read → merge → write discipline ADR-002 established for `.autopilot-userconfig.json`:

1. Read `~/.claude/settings.json` (tolerate missing file — treat as `{}`).
2. Call `mergeMarketplaceAutoUpdate(settings, entry)` from `hooks/lib/settings-writer.js`
   to compute the merged object.
3. Write the result back atomically (write to a temp file, then rename — same safe-write
   the userConfig step uses; prevents partial writes from corrupting the settings file).

```js
// Entry descriptor passed to mergeMarketplaceAutoUpdate:
const entry = {
  name: "kohlex-autopilot",
  source: { source: "github", repo: "kohlex/autopilot-marketplace" },
};
// Result: ~/.claude/settings.json gains (or updates):
//   "extraKnownMarketplaces": {
//     "kohlex-autopilot": {
//       "source": { "source": "github", "repo": "kohlex/autopilot-marketplace" },
//       "autoUpdate": true
//     }
//   }
```

**Why `extraKnownMarketplaces`, NOT `installed_plugins.json`:**
The `autoUpdate` flag only controls automatic marketplace refresh when it lives on the
**marketplace registration entry** in `settings.json`. An `autoUpdate` field placed inside
`installed_plugins.json` has no effect on update fetching. (Confirmed by RESEARCH for DIST-3.)

**Caveat #52218 (document to operator in the post-run confirmation):**
After an auto-update fires, the marketplace catalog may refresh (new versions visible) without
advancing `installed_plugins.json installPath` to the new version. If a silent update seems to
have fired but the installed skill behaviour hasn't changed, verify that `installPath` in
`installed_plugins.json` actually advanced. Manual `/plugin update autopilot` will force it.

**This is an ADDITIVE merge.** `mergeMarketplaceAutoUpdate` uses spread (`{...settings, ...}`)
so all other top-level keys (`enabledPlugins`, `autoUpdatesChannel`, etc.) survive unchanged.
Running `/platform-init` again is idempotent — the same value is written; nothing else moves.

**Step ordering:** Run this step AFTER the `.autopilot-userconfig.json` write (Step 1.0)
and BEFORE Step 1.5 (validated thesis). Rationale: both writes are cold-install setup steps
that must complete before any research or scaffolding begins.

**Post-run confirmation (in Piper's voice):**

> I've set `autoUpdate: true` for the kohlex-autopilot marketplace entry in
> `~/.claude/settings.json`. Claude Code will auto-refresh the marketplace when
> updates ship — you won't need to run `/plugin update` manually.
> Reminder: after any auto-update fires, confirm `installed_plugins.json installPath`
> advanced (bug #52218 — marketplace may refresh without advancing the installed path).

### Step 1.5 — Validated thesis (Wave 7.1, Act 1 of the journey)

**Why this step exists:** the WirePerfect User Journey Act 1 says you don't
go from "1-line hypothesis" to "build" without two intervening conversations:
brainstorming the wedge, then YC-grilling for status-quo desperation.

> You invoke `/superpowers:brainstorming`. It refuses to let you skip ahead.
> It forces six questions: *Who's the user? What's the wedge? What's the
> status quo? What would make them switch?* … By lunch you have a paragraph
> that's no longer "Zuken competitor" — it's something specific.
>
> You run `/office-hours` (G-Stack). It plays YC partner: *"Is anyone
> actually desperate for this? Have you watched one do it manually?"*

Skipping these = skipping Act 1 = launching capability-map against an
under-specified wedge. The outputs feed `wedge-synthesis` (Step 4) as the
seed thesis rather than the raw `<hypothesis>` argument — much higher quality.

**Thin delegate to `/ideate-wedge` (B2 extraction).** The brainstorm→office-hours→scale flow
was lifted into the shared `/ideate-wedge` skill so greenfield and brownfield can't drift.
Step 1.5 now simply delegates — same inputs, same `OFFICE-HOURS-DESIGN-v1.md` output, same
skip conditions. The scale question lives in `/ideate-wedge` (its single home), so it is NOT
duplicated here.

```sh
Skill: /ideate-wedge \
  --hypothesis "$HYPOTHESIS" \
  --scratch-dir "$SCRATCH_DIR"
# greenfield: no --codebase-map seed. Produces $SCRATCH_DIR/OFFICE-HOURS-DESIGN-v1.md
# (brainstorming six-question forcing function -> office-hours desperation grilling ->
#  scale anchor: in-house-first, hyperscale-aware). Identical contract to the prior
#  inline flow — this delegation is contract-preserving.
```

The output file `OFFICE-HOURS-DESIGN-v1.md` is consumed by `/wedge-synthesis`
(Step 4) via the `--validated-thesis` flag, in addition to the
capability-map outputs and asset-survey.

**Skip conditions** (unchanged — passed through to `/ideate-wedge`):
- `--skip-validated-thesis` flag → delegate with `/ideate-wedge --skip`; wedge-synthesis seeds on raw `<hypothesis>` (legacy escape hatch).
- A `VALIDATED-THESIS.md` file already exists in the product's `.planning/` (caller pre-validated) → skip the delegate entirely.

### Step 2 — Parallel capability-map subagents

Spawn one `/capability-map` invocation per competitor, all in parallel.
Each writes its outline doc into the scratch dir. Wait for all to complete.

If any fail → log warning, continue with the successful ones (warn user at
Step 5). Don't STOP unless ALL fail.

### Step 3 — Asset survey

Spawn `/asset-survey` subagent. (Not yet implemented — Wave 3+; for now, this
step is a placeholder that writes an empty `ASSET-SURVEY.md` with a note that
asset-survey skill is pending and `wedge-synthesis` will default reuse_score=1
for all capabilities.)

When the real `asset-survey` skill ships (Wave 3 deliverable per design doc),
it will scan `PLATFORM/**`, `skills/`, `hooks/`, `~/.claude/skills/` and
produce a structured list of reusable internal capabilities.

### Step 4 — wedge-synthesis

Spawn `/wedge-synthesis` with the capability-maps + asset-survey + hypothesis.
Get `WEDGE-AND-CAPABILITIES.md` + `capabilities.yaml` written to scratch dir.

### Step 5 — User Approval Gate 1

Use `AskUserQuestion` with the wedge + capability matrix summary:

```
GATE 1 — Wedge + capabilities approval

Wedge: <one-sentence wedge>

Capabilities: <N> total
  FIRST: <list of FIRST capability ids>
  NEXT: <list>
  LATER: <list>

Top-3 value: <list>
Top-3 reuse: <list>

Approve?
  [APPROVE] proceed to PRD generation
  [TWEAK]   adjust wedge or scope; re-run wedge-synthesis
  [REJECT]  start over with different hypothesis or competitors
```

If APPROVE → compute `lock_hash = sha256(WEDGE-AND-CAPABILITIES.md)`, write
into `capabilities.yaml`. Commit:
`plan(<product>): wedge-synthesis output (locked at gate 1, sha256=<hash>)`.

If TWEAK → AskUserQuestion for adjustments, re-spawn wedge-synthesis, re-gate.

If REJECT → STOP. Surface scratch dir for user to review; user can re-invoke
`/platform-init` with different inputs.

### Step 5.5 — GSD project bootstrap (Wave 7.2, Act 2 of the journey)

**Why this step exists:** WirePerfect User Journey Act 2 hands the
post-wedge skeleton authoring to GSD, not AutoPilot:

> You invoke `/gsd:new-project`. It interrogates you about scope, users,
> constraints, success criteria. It spawns four researchers in parallel —
> competitive landscape, tech ecosystem, domain context, similar products.
> They write to `.planning/research/`. A synthesizer rolls it into
> `SUMMARY.md`.
>
> Then `/gsd-roadmapper` turns your thesis into a roadmap: M0, M1, M2, …, M5.

GSD is the milestone-aware project skeleton owner. AutoPilot's
`capabilities.yaml` stays AUTHORITATIVE (the dep graph, the lock_hash, the
phase scoring), but `PROJECT.md` + `.planning/milestones/M0/` become GSD's
view that the milestone-loop (Wave 7.7) walks.

```sh
Skill: /gsd:new-project \
  --product "$PRODUCT" \
  --hypothesis "$HYPOTHESIS" \
  --validated-thesis "$SCRATCH_DIR/OFFICE-HOURS-DESIGN-v1.md" \
  --capabilities "$SCRATCH_DIR/capabilities.yaml" \
  --autonomous-defaults \
  --output-dir "PLATFORM/$PRODUCT/.planning/"
# /gsd:new-project writes:
#   PROJECT.md                         — scope/users/constraints/success-criteria
#   .planning/research/                — 4 parallel researcher outputs
#   .planning/research/SUMMARY.md      — synthesis
#   .planning/milestones/M0/phases/    — phase skeleton from /gsd-roadmapper
# Conflict detection: if any of these already exist (e.g. operator
# pre-populated PRD.md), /gsd:new-project's --merge-mode applies.
```

**Architectural decision (documented in capabilities.yaml act2-gsd-project-bootstrap):**

- `capabilities.yaml` is AUTHORITATIVE — schema-validated, lock_hash-bound,
  feeds the autopilot loop's eligibility filter.
- `PROJECT.md` + `.planning/milestones/M0/` are GSD's VIEW — generated from
  capabilities.yaml + wedge outputs, owned by GSD's regeneration semantics.
- Post-merge-coordinator hook (Wave 5) re-emits PROJECT.md on every merge so
  the view stays in sync with the authoritative graph.

**Skip conditions:**
- `--skip-gsd-bootstrap` flag → AutoPilot owns the milestone view (legacy mode)
- `.planning/milestones/M0/` already exists → merge mode

### Step 6 — PRD generation

Spawn PRD-generation subagent. (Inline logic for now — when a dedicated
`/prd-generation` skill ships in Wave 5, replace.) PRD content derived from:

- Wedge (§1 from WEDGE doc)
- Capabilities (§2 mapping P1 in-scope from `FIRST` phase)
- Asset survey (§3 reusable internals)
- Risks (§4 from WEDGE §9)
- Milestones (§5 derived from phase distribution: Prototype = FIRST shipped;
  MVP = NEXT shipped; Blue-sky = LATER shipped)

### Step 7 — User Approval Gate 2

`AskUserQuestion` with PRD summary. Same APPROVE / TWEAK / REJECT loop.

If APPROVE → lock PRD (sha256 hash in capabilities.yaml `prd_lock_hash`).

### Step 8 — Scaffold

Materialize the directory layout from the "Output" section above:

```sh
mkdir -p PLATFORM/<product>/.planning
mv <scratch>/* PLATFORM/<product>/.planning/

cp PLATFORM/AutoPilot/templates/product-CLAUDE.md.template PLATFORM/<product>/CLAUDE.md
sed -i "s/{{product}}/<product>/g" PLATFORM/<product>/CLAUDE.md
# (scope-fence paths populated from template)

cp PLATFORM/AutoPilot/templates/ARCHITECTURE.md.template PLATFORM/<product>/.planning/ARCHITECTURE.md
# (ARCHITECTURE.md is SKELETON ONLY — filled by Phase 0.5 architecture-design)

# Write README.md, manifest.yaml, INTENT.md inline (small files)
```

If templates missing → log warning, write minimal stubs the user can fill in.

### Step 9 — Commit on feature branch

```sh
git worktree add ../rfi-01-wt-<product>-phase0 -b <product>/phase-0-scaffold main
cd ../rfi-01-wt-<product>-phase0
# Atomic commits per the flow above
git push -u origin <product>/phase-0-scaffold
gh pr create --draft --base main --head <product>/phase-0-scaffold \
  --title "spec(<product>): Phase 0 scaffold (wedge + PRD locked)" \
  --body "Auto-generated by /platform-init. Awaiting human review of generated artifacts before merge to main."
```

### Step 10 — Return summary

```
[platform-init] <product> Phase 0 complete.
  Product path: PLATFORM/<product>/
  Wedge: <one-line>
  Capabilities: <N> (FIRST=<a>, NEXT=<b>, LATER=<c>)
  Both gates passed.
  PR: <url>
  Next: invoke /architecture-design <product> to run Phase 0.5
```

## Stop conditions (summary)

- Inputs missing/malformed → STOP
- `PLATFORM/<product>/` already exists → STOP and ask user
- All N capability-map subagents fail → STOP (≥1 success continues)
- User REJECTs at gate 1 or gate 2 → STOP cleanly
- wedge-synthesis self-check fails → STOP, surface to user
- Scaffold step encounters write failure → STOP, leave scratch dir for inspection

## Smoke-test (dry-run, REQUIRED before this skill is considered usable)

### Smoke-test — fictional product `RecipeForge`

**Why fictional:** the charter says "do NOT actually create the product dir
during smoke-test; dry-run mode." A fictional product proves the orchestration
sequence works without committing real Phase-0 work for a product Christian
hasn't decided to build.

**Invocation:**
```
/platform-init RecipeForge \
  --hypothesis "Local-first recipe app that learns from your cooking history and suggests next-meal options based on pantry + preferences" \
  --competitors "Paprika,Yummly" \
  --target-users "Home cooks who batch-cook on weekends and want to minimize Tuesday-night decision fatigue" \
  --success-metrics "Weekly active users ≥ 4 sessions/week; 50% of suggested meals get cooked; <5s suggestion latency" \
  --dry-run
```

**Expected dry-run output (no files written, no commits, no gates fired):**

```
[platform-init] DRY-RUN for RecipeForge
  Step 1: ✅ inputs validated; hypothesis 113 chars (under 200)
  Step 2: would spawn 2 capability-map subagents (Paprika, Yummly) in parallel
  Step 3: would spawn asset-survey subagent (currently stub)
  Step 4: would spawn wedge-synthesis with 2 capability-maps + hypothesis
  Step 5: would fire GATE 1 via AskUserQuestion (wedge + capability matrix)
  Step 6: would generate PRD
  Step 7: would fire GATE 2 via AskUserQuestion (PRD)
  Step 8: would scaffold PLATFORM/RecipeForge/ + .planning/
  Step 9: would commit on RecipeForge/phase-0-scaffold + draft PR
  Step 10: would report

  Expected output paths (dry-run, none created):
    PLATFORM/RecipeForge/CLAUDE.md
    PLATFORM/RecipeForge/README.md
    PLATFORM/RecipeForge/.planning/PRD.md
    PLATFORM/RecipeForge/.planning/ARCHITECTURE.md (skeleton)
    PLATFORM/RecipeForge/.planning/WEDGE-AND-CAPABILITIES.md
    PLATFORM/RecipeForge/.planning/capabilities.yaml
    PLATFORM/RecipeForge/.planning/2026-05-17-RecipeForge-Paprika-outline.md
    PLATFORM/RecipeForge/.planning/2026-05-17-RecipeForge-Yummly-outline.md
    PLATFORM/RecipeForge/.planning/ASSET-SURVEY.md
    PLATFORM/RecipeForge/.planning/INTENT.md
    PLATFORM/RecipeForge/.planning/DOCTRINE.md
    PLATFORM/RecipeForge/.planning/manifest.yaml

  Expected capability count (rough): 10-15 (recipe-app domain is narrower than PLM)
  Expected FIRST count: 5-7
  Verdict: ✅ DRY-RUN PASS — orchestration sequence is product-agnostic
           Domain: cooking; no PLM jargon expected in real output.
```

**Assertions verified by dry-run:**

- ✅ All inputs validate
- ✅ Capability-maps will be requested in parallel (N=2 for this smoke test)
- ✅ Two human gates wired correctly via AskUserQuestion
- ✅ Scaffold paths use product name, not hardcoded "PLMperfect"
- ✅ Branch + PR title use product slug
- ✅ Output directory layout matches the spec
- ✅ Cooking-domain product (not PLM, not audio) plugs in cleanly — orchestration is generic

## Doctrine fidelity

- Two human gates — and ONLY two — for the full Phase-0. Everything else
  decides autonomously per the 90% rule (AGENTS.md / DOCTRINE).
- Conventional commits enforced (each step's commit uses `spec` / `plan` /
  `chore` types).
- Feature branch + draft PR — never direct to main.
- The scaffold step uses templates from `PLATFORM/AutoPilot/templates/`; never
  hardcodes content for any specific product.

## What this skill explicitly does NOT do

- Does NOT run Phase 0.5 (architecture) — that's `/architecture-design`
- Does NOT start the autonomous build loop — that's `/autopilot` or
  `/autopilot-loop` (Wave 4 deliverable, in this V3 ship)
- Does NOT make wedge decisions on the user's behalf — Gate 1 is the user's
  call
- Does NOT modify any existing product directory — only creates new ones
- Does NOT proceed past either gate without explicit user APPROVE