Initialize project

Initialize Project

Run the phases IN ORDER. Persist after every phase (memory MCP) so a crashed or compacted session resumes cleanly — on resume, progress_status tells you which phase you were in; skip completed ones.

First: state_set {phase: "INITIALIZING"}.

Phase 1 — Ingest

1. Read docs/proposal.md fully. Read every readable file in docs/additional/ (note skipped binaries).
2. memory_save context/proposal-digest: goals, users, constraints, stack hints, explicit unknowns.
3. progress_log {status:"done", note:"init phase 1: ingest"}.

Phase 2 — Interview (mandatory, never skip)

Goal: ~95% confidence about what the user actually wants, not what the proposal literally says.

• Invoke the interview-me skill (vendored in .claude/skills/interview-me/; falls back to agent-skills:interview-me if the plugin form is what your harness lists). Drive it to ~95% confidence.
• Only if neither is available: run your own interview — ONE question at a time via AskUserQuestion, concrete options, stop when new answers stop changing the plan.

Cover whatever the proposal leaves open (skip what it already answers): target users + the core job-to-be-done · v1 scope cut (what is explicitly OUT) · platform + stack constraints · quality bar (throwaway prototype vs production) · security/compliance/PII needs · deploy target + who operates it · the ONE success metric · deadline/budget.

memory_save context/interview-answers (verbatim Q→A) · progress_log phase done.

Phase 3 — Specs

Spawn architect (opus) with the proposal digest + interview answers. Deliverables in docs/specs/:

• 01-product.md — users, jobs, scope in/out, success metrics
• 02-architecture.md — components, data flow, stack choice + rationale, ADRs
• 03-data.md — entities, schema sketch (when the project has data)
• 04-security.md — spawn security-engineer (opus) to threat-model 02 and write this
• 05-operations.md — environments, CI/CD, observability, release (when deployable)

Skip files genuinely irrelevant to the domain; record each skip + reason in the legend later. Review the specs yourself against the interview answers, then present a summary to the user and get approval BEFORE planning. memory_save decisions/spec-approval · progress_log.

Phase 4 — Plans

Spawn planner (opus) with the approved specs. It writes docs/plans/legend.md + docs/plans/epics/EP-*.md per .claude/system/templates/plan-format.md. Then verify the quality bar yourself (every task has role/model/verify/deps; stories have testable criteria; DAG has no cycles). Not met → respawn planner with specific feedback. Present plan stats (epics/stories/tasks, sequence) to the user for approval. progress_log.

Phase 5 — Team & tooling (the whole toolchain is mutable here)

Via skill manage-agents, reshape the system to fit THIS project:

1. Agents — create missing domain roles (ml-engineer, mobile-engineer, firmware-engineer, game-engineer, data-engineer, …); modify shipped agents whose specialty guidance or model tier doesn't fit the domain; remove roles the project will never use (e.g. frontend-engineer for a pure CLI). Registry updated either way.
2. Skills / hooks / MCP servers — add or remove as the plan requires (e.g. a domain-specific procedure skill, a lint hook, an API MCP). Only what a concrete plan task needs — no speculative tooling.
3. Knowledge graph — run /graphify docs/ so proposal, specs, and plans are queryable during execution.
4. memory_save context/team-roster (roster + what was added/modified/removed and why) · progress_log.

Phase 6 — Commit

1. No git repo yet → ask the user once, then git init + initial commit ("agent system + specs + plans").
2. state_set {phase:"PLANNED", detail:"<first epic id>"} · progress_log {status:"done", note:"initialization complete"}.
3. Report: specs written, plan stats, team roster, and: type start to begin execution. Do NOT start executing without the user saying so.