/create-specs — idea → PRD (+ Initiatives)

You are a thin orchestrator. Invoke each skill below by name, pass it the stated focus, and report a one-line progress summary at every step boundary (e.g. "Step 1/6 — context loaded: …", using the literal step numbers 0–6). Do not add phases, do not skip phases, do not inline work a skill owns.

Two standing rules, because sub-skill output buries the parent sequence and compaction silently drops instructions:

• After EVERY skill returns, restate position: "→ Returning to /create-specs: next is step N (<name>)."
• After any auto-compaction, re-invoke the skill governing the current step before continuing.

Input: $ARGUMENTS — an inline idea/brief, or a path/wikilink to a note in C:\Users\any0ne\vault\openlatch-vault. If empty, ask exactly one question: "What are we building?"

Goal: set a session goal now (SlashCommand /goal if available, otherwise state it and treat it as binding): "PRD '\<name\>' written to the vault per conventions (+ Initiatives if calibrated), Index.md updated, agent-ready bar met, spec-verify passed."

Steps

1. Skill: `calibrate` — focus initiatives. Returns the verdict block: ambition tier, initiative-count hypothesis, and the question budget for step 2. This is also what keeps the spec's weight matched to the problem — a small change should not get four initiatives and sixteen criteria.
2. Skill: `learn-existing` — focus vault+codebase, scoped to the product area of the idea (strategy notes, related PRDs, repo reality). Note the real file/module/endpoint names in the target repos — the docs will reference them concretely, not as vague nouns.
3. Skill: `clarify-intent` — focus: business value, feature requirements, target personas, scope boundaries, success metrics. Question budget from step 0. Make sure the answers also surface the inputs the agent-ready bar needs: explicit non-goals, the data/API contracts involved, and error/edge behavior (what happens on the unhappy path). If those are left implicit now, they get invented later.
4. Skill: `custom-deep-research` — focus product. Always run at full depth (never skip, regardless of calibrate tier): business context, value we want to create, state of the art, market research, competitive analysis.
5. Outline gate — the only human gate. Present via AskUserQuestion: feature list, target personas, the non-goals, the initiative split decision (0 or N, with names and what each covers), the canonical contract location (which doc owns the data/API contract), and target repos. If the user's answers shifted scope, re-run calibrate and say so. Wait for approval before writing.
6. Author the docs (autonomous after the gate):

• PRD → 03-Product/PRDs/<Name>.md
• Initiatives (if any) → 03-Product/PRDs/<Name>/I-<n>-<Kebab-Title>.md
• Follow the vault contract loaded in step 1: frontmatter taxonomy (type, nested tags, created/last-updated, owner: Luc Delsalle, target-repos, brainstorm-folders left empty for /create-plans), section structures mirroring the exemplars (Admin Broadcast Messaging for PRDs, I-5.5 for Initiatives), wikilinks liberally, mandatory ## Related. If that context was compacted away, re-invoke learn-existing with focus vault first.
• Meet the agent-ready bar below. The PRD owns one canonical contract section (data models + endpoints with request/response shape and error codes + frozen enums) and ends with an end-to-end verification recipe; every Initiative ends with a `## Verification` section and references the PRD's contract rather than recopying it.
• Create 03-Product/PRDs/Index.md if missing; add/update this PRD's row (status: Draft).

1. Skill: `verify` — focus spec. Fix every gap it reports. Beyond the vault contract, run each doc through two extra lenses:

• The Kiro defect grid: wrong level of detail (abstract thesis, or an implementation recipe masquerading as a requirement), ambiguity (two engineers would build it differently), inconsistency (two requirements — or two endpoint/event names, across files — that can't both hold), incompleteness (whole regions of the input space left unspecified).
• The agent-ready bar: every Initiative has a ## Verification section, contracts are frozen in one canonical place (no divergent copies), non-goals are stated, acceptance criteria are testable.

Agent-ready bar — what "done" means for every doc

These docs are consumed by a coding agent (Claude Code) in a fresh session, not just read by humans. The evidence on spec-driven development (Anthropic's Claude Code best practices, GitHub Spec Kit, AWS Kiro) is blunt: an under-specified spec drops first-pass correctness by 20–40% and makes most of the code that compiles semantically wrong. So hold every PRD/Initiative to this bar — and explain, don't just assert, so the authoring step understands the intent:

1. Separate the what/why from the how. The PRD states problem, value, personas, scope. Architecture and contracts are explicit but never bury the intent.
2. Name concrete files, interfaces, endpoints. "the auth module" → the real path/symbol from step 1. An agent can't act on vague nouns.
3. Freeze contracts in one place. Data models, API endpoints (method + path + request/response shape + error codes), and enums live in a single canonical section that other docs reference, never recopy. Duplicated contracts drift, and a divergent endpoint name becomes a 404 on the day — this is the most common and most expensive failure. If the product depends on another service's PRD, point to that PRD's contract section as the source of truth.
4. Acceptance criteria are testable checkboxes. Each - [ ] must be something a human or a test can mark pass/fail without arguing. "Filtering persists on refresh" ✓ ; "the UX feels smooth" ✗. For state-machine or error-heavy flows, EARS phrasing (WHEN … SHALL / IF … THEN) sharpens the criteria and maps cleanly to test cases.
5. State Non-Goals explicitly. Without an out-of-scope list, agents add unrequested features (auth, caching, retries). A real "won't do" list is a guardrail, not filler.
6. Specify the unhappy path. Non-functional constraints plus error/edge behavior (network down, permission denied, invalid input, timeout, empty state, partial failure). Silence here means the agent invents it — usually wrong.
7. End every doc with a verification step. Highest-value item: each Initiative ends with a ## Verification section (named tests, a runnable command, or a recipe that yields pass/fail); each PRD ends with an end-to-end recipe proving the feature works. Anthropic, verbatim: the most useful specs "end with an end-to-end verification step that proves the feature works." If it can't be verified, it isn't done.
8. Make ordering and dependencies explicit. Initiatives carry a build order and hard dependencies (X before Y, what can run in parallel). Fine-grained task decomposition is /create-plans' job — don't pre-empt it — but the order between initiatives must never be implicit.
9. Right altitude. Give strong heuristics, not brittle hardcoded recipes. "Minimal" ≠ "short": enough to remove ambiguity, flexible enough to let a capable agent reason.
10. Calibrate weight to the problem. Match the spec's heft to the work (that's what step 0 calibrate decides) — over-specifying a trivial change wastes context and tangles the agent.

Done

Finish with a 5-line summary: docs created (paths), initiative decision and why, research highlights that shaped the PRD, confirmation the agent-ready bar is met (contracts frozen, every doc has its verification step), and the next command: /create-plans "<PRD name>".