# Initiate

> 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.

- Skill: `danielimad/initiate` (Agent Skill)
- Install (CLI): `npx skillmds@latest add danielimad/initiate`
- Raw SKILL.md: https://api.skillmd.com/api/skills/danielimad/initiate/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: danielimad (https://skillmd.com/u/danielimad)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/danielimad/initiate

---


# 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:
1. **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.
2. **Init** the project (framework CLI / template), pin the **package manager** (bun/npm/pnpm — one, never mixed), install deps.
3. **Baseline files**: `.gitignore` (env, build, `.docs/*.local` if any), `.env.example` (keys only, NO values), `README.md` stub, `tsconfig`/lint/format config, editor config.
4. **Git**: `git init`, first commit `chore: scaffold <project>` on a branch — do NOT push, do NOT create remote (green-light rules from /ship apply).
5. **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.
6. **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.