| description |
|---|
Bootstrap a durable project memory system (specs + CLAUDE.md) for a new project |
You are about to help me build a new software project. Before writing any code, we need to establish a durable memory system that will keep us aligned across long sessions and multiple conversations.
Interview me until you have crisp answers to ALL of these. Do not proceed to Step 2 until every item is resolved. Ask follow-up questions in batches of 3-5 — never more.
What:
- What does this project do in one sentence?
- Who is the user / consumer?
- What is the primary interface? (CLI, web app, API, library, plugin, etc.)
Boundaries:
- What are the explicit non-goals? (things it will NOT do)
- What are the hard constraints? (language, platform, dependencies, performance, security)
- Are there external APIs, services, or systems it must integrate with?
Done-when:
- What are the concrete acceptance tests a human could run to verify it works? (e.g., "run X, expect Y")
If my answers are vague, push back. Restate what you understood and ask me to confirm or correct. Do not guess — ask.
Once the idea is clear, generate these four files in a single commit:
Contains:
- Goal (1-2 sentences)
- Non-goals (bulleted)
- Hard constraints (bulleted)
- Deliverables checklist (unchecked boxes)
- Done-when criteria (numbered, runnable acceptance tests)
Rules: This file is immutable after creation. Changes require explicit approval.
Contains sequenced milestones (M1, M2, ...) where each milestone has:
- Scope: Which files are created or modified (explicit list)
- Acceptance criteria: Checkboxes (
- [ ]) that must all pass - Validation commands: Exact shell commands to run after implementation
Rules:
- Each milestone should be completable in a single focused session
- Milestones are ordered — no skipping
- Mark checkboxes only after validation passes
- If a milestone seems too large, split it
Starts nearly empty. After each milestone, prepend an entry with:
- Date and milestone name
- Status (completed / partial / blocked)
- Validation outcome
- Decisions made and rationale
- Deviations from plan (if any)
Contains:
- Pointers to the three specs files (do NOT duplicate their content)
- Operating rules:
- Plan is source of truth — work only on the current milestone
- Verify after every milestone — run validation before marking complete
- Keep diffs scoped — one milestone per commit
- Update status continuously — append to status.md after each milestone
- No skipping milestones
- Ask on ambiguity — never guess
- Build / test / lint commands
- Code conventions
- Repository structure overview
Show me a summary of all four files before writing them. I will approve, request changes, or ask questions. Only after my approval, create the files and commit.
- Do not start coding before the memory system is in place
- Do not put milestone details in CLAUDE.md (it points to plan.md)
- Do not put operating rules in plan.md (they go in CLAUDE.md)
- Do not combine specification and status in the same file
- Do not create milestones without validation commands
- Do not make milestones so large they can't finish in one session