Initiate — project cold start
Execute in order, no skipped steps. Setup and alignment only — no feature code until the first task is started.
1. PRD
Read PRD.md fully — scope, goals, features, technical requirements, integrations, and the full tech stack (the PRD always specifies it). If missing, stop and ask for it. If the PRD names the stack, that IS the stack — do not substitute or "improve" it.
2. Scaffold
Stand up the project skeleton so the repo is real and runnable before docs/tasks:
- Read the stack from the PRD (framework, language, package manager, backend, hosting, key libs). Echo it back in one line and confirm y/n before scaffolding. Never impose a default stack — the PRD is the source of truth; only ask if the PRD genuinely omits a piece.
- Init the project (framework CLI / template), pin the package manager (bun/npm/pnpm — one, never mixed), install deps.
- Baseline files:
.gitignore (env, build, .docs/*.local if any), .env.example (keys only, NO values), README.md stub, tsconfig/lint/format config, editor config.
- Git:
git init, first commit chore: scaffold <project> on a branch — do NOT push, do NOT create remote (green-light rules from /ship apply).
- Verify it runs: dev server boots / build passes / typecheck green — capture the one command that proves it (feeds
verification.md). A scaffold that doesn't run isn't done.
- Secrets: any real key goes to env/Keychain with a pointer in
integrations.md — never committed, never in .env.example.
3. Repo docs (beyond architecture)
Docs live in .docs/ by default; if the repo's runbook names a different docs folder, the runbook wins. Create the folder and generate the full why-first set (the /full-document skill defines it). At init, seed what the PRD supports; leave a [needs-context] stub for the rest:
architecture.md — layers, data flow, component connections, doc index. (protected after creation)codebase-map.md — what each planned module/dir does.domain-model.md — entities, states, the definition of every money/date/status value the PRD implies.decisions.md — append-only; seed with the stack + scaffold decisions and their trade-offs.gotchas.md — start empty with the header; fills via /document as mistakes surface.conventions.md — the unbreakable laws for this repo (money units, write-paths, i18n/locales, RLS, naming, package manager).integrations.md — every external API from the PRD: auth method, rate limits, known limitations, secret pointer (env/Keychain name), dashboard/docs URL.runbook.md — the operational card (see the /runbook skill): test tenants, known IDs, health checks, deploy commands, git rules, dev port.verification.md — the typecheck/lint/test battery + the runtime check that counts as real proof (from step 2.5).
House style throughout: capture the WHY, log-vs-mindset split, dated, pointers not secrets.
4. Issue-tracker mapping
Skip this step if the project doesn't use one.
Via whichever tracker integration is configured (ClickUp, Linear, Jira, GitHub Issues), enumerate the available workspaces/projects and present them. Wait for the user to confirm the destination — never pick one. Then fetch that destination's real status values from the API, present them, and ask which is the default for new tasks.
Write the resolved mapping (IDs + the full status list + the confirmed default) to a config file in the repo, e.g. .docs/tracker.json. Never assume or hardcode a status name — they are per-workspace. (protected after creation)
5. Task seeding
Derive tasks from the PRD: create parent tasks (milestones/epics) first, capture their real IDs, then subtasks. All at the confirmed default status. Sequential calls with a short pause between them — most tracker APIs rate-limit batched writes. Present created tasks + IDs.
6. Summary & stop
Confirm initiation complete — what was scaffolded, which docs were seeded, the tracker mapping, tasks created with IDs — and stop. No feature code until the user starts the first task.
Protected from here on: the tracker config and architecture.md — never modified by refactors or cleanups without explicit instruction.
1---2name: initiate3description: Full project cold-start — PRD → scaffold → docs → issue-tracker mapping → task seeding. Use on "initiate project", "cold start this project", "set up a new repo from the PRD". Setup and alignment ONLY — never write feature code during initiation.4---56# Initiate — project cold start78Execute in order, no skipped steps. Setup and alignment only — no feature code until the first task is started.910## 1. PRD11Read `PRD.md` fully — scope, goals, features, technical requirements, integrations, and the **full tech stack** (the PRD always specifies it). If missing, stop and ask for it. If the PRD names the stack, that IS the stack — do not substitute or "improve" it.1213## 2. Scaffold14Stand up the project skeleton so the repo is real and runnable before docs/tasks:151. **Read the stack from the PRD** (framework, language, package manager, backend, hosting, key libs). Echo it back in one line and confirm y/n before scaffolding. Never impose a default stack — the PRD is the source of truth; only ask if the PRD genuinely omits a piece.162. **Init** the project (framework CLI / template), pin the **package manager** (bun/npm/pnpm — one, never mixed), install deps.173. **Baseline files**: `.gitignore` (env, build, `.docs/*.local` if any), `.env.example` (keys only, NO values), `README.md` stub, `tsconfig`/lint/format config, editor config.184. **Git**: `git init`, first commit `chore: scaffold <project>` on a branch — do NOT push, do NOT create remote (green-light rules from /ship apply).195. **Verify it runs**: dev server boots / build passes / typecheck green — capture the one command that proves it (feeds `verification.md`). A scaffold that doesn't run isn't done.206. **Secrets**: any real key goes to env/Keychain with a pointer in `integrations.md` — never committed, never in `.env.example`.2122## 3. Repo docs (beyond architecture)23Docs live in `.docs/` by default; if the repo's runbook names a different docs folder, the runbook wins. Create the folder and generate the full why-first set (the /full-document skill defines it). At init, seed what the PRD supports; leave a `[needs-context]` stub for the rest:24- `architecture.md` — layers, data flow, component connections, doc index. *(protected after creation)*25- `codebase-map.md` — what each planned module/dir does.26- `domain-model.md` — entities, states, the definition of every money/date/status value the PRD implies.27- `decisions.md` — append-only; seed with the stack + scaffold decisions and their trade-offs.28- `gotchas.md` — start empty with the header; fills via /document as mistakes surface.29- `conventions.md` — the unbreakable laws for this repo (money units, write-paths, i18n/locales, RLS, naming, package manager).30- `integrations.md` — every external API from the PRD: auth method, rate limits, known limitations, secret *pointer* (env/Keychain name), dashboard/docs URL.31- `runbook.md` — the operational card (see the /runbook skill): test tenants, known IDs, health checks, deploy commands, git rules, dev port.32- `verification.md` — the typecheck/lint/test battery + the runtime check that counts as real proof (from step 2.5).33House style throughout: capture the WHY, log-vs-mindset split, dated, pointers not secrets.3435## 4. Issue-tracker mapping36Skip this step if the project doesn't use one.3738Via whichever tracker integration is configured (ClickUp, Linear, Jira, GitHub Issues), enumerate the available workspaces/projects and present them. **Wait for the user to confirm the destination** — never pick one. Then fetch that destination's real status values from the API, present them, and ask which is the default for new tasks.3940Write the resolved mapping (IDs + the full status list + the confirmed default) to a config file in the repo, e.g. `.docs/tracker.json`. Never assume or hardcode a status name — they are per-workspace. *(protected after creation)*4142## 5. Task seeding43Derive tasks from the PRD: create parent tasks (milestones/epics) first, capture their real IDs, then subtasks. All at the confirmed default status. Sequential calls with a short pause between them — most tracker APIs rate-limit batched writes. Present created tasks + IDs.4445## 6. Summary & stop46Confirm initiation complete — what was scaffolded, which docs were seeded, the tracker mapping, tasks created with IDs — and stop. No feature code until the user starts the first task.4748Protected from here on: the tracker config and `architecture.md` — never modified by refactors or cleanups without explicit instruction.
danielimad