All six Phases,
in depth

Copy this prompt → paste into Claude

I've drafted the following notes for my project. Please formalize
them into a complete Project Charter in markdown format.

[Paste your draft notes here — bullet points, rough answers,
VOC quotes you've collected, scope ideas, anything you have]

Structure the charter with these exact sections:
1. Project Purpose — why this needs to exist (2-3 sentences)
2. Target Customer — named avatars with role, experience level,
   and specific pain points
3. Problem Statement — what's broken today (be specific)
4. Goal Statement — one sentence defining success
5. Key Metrics — 1 primary metric, 2 secondary metrics
6. Voice of Customer — each quote on its own line, followed by
   the underlying need it reveals
7. Scope — explicit In/Out table for MVP
8. Timeline — milestone → target date format
9. Assumptions & Constraints

Keep my original language wherever possible. If anything is
missing or unclear, ask before filling it in yourself.
Save this as PROJECT_CHARTER.md and add it to the project.

Copy this prompt → paste into Claude

I am sharing my Project Charter [attached as PROJECT_CHARTER.md].

Please create a Business Requirements Document (BRD) using the
charter as your primary source. Build it section by section:

1. Executive Summary — what the system does in 2 paragraphs
2. Business Context — pull the problem, users, and success
   metrics directly from the charter
3. User Personas — one paragraph per avatar from the charter's
   Target Customer section. Use the exact names and details.
4. Functional Requirements — numbered FR-001, FR-002, etc.,
   organized by feature area. Rules:
   - Pattern: "The system shall [do what] [for whom]
     [under what conditions]."
   - Every requirement must trace to a specific VOC quote or
     user story from the charter. Note which one.
   - Priority: Must Have / Should Have / Nice to Have
   - If a requirement cannot be traced to a VOC quote or user
     need in the charter, do not include it.
5. Non-Functional Requirements — performance, security,
   access control by role
6. System Architecture — specific technologies (not categories),
   database models, API surface
7. Out of Scope — what is explicitly NOT in MVP

Save this as BRD.md and add it to the project.

Copy this prompt → paste into Claude

I am sharing my Project Charter and BRD [both attached].
Read both documents before proceeding.

Please create a Feature/Function List (FFD) that breaks every
functional requirement from the BRD into developer-ready
specifications. Output as a markdown table:

| FF-ID | Feature | Function | BRD Ref | User Role | Priority | Notes |

Rules:
- FF-ID: sequential (FF-001, FF-002...)
- Feature: short name (2-3 words)
- Function: one precise sentence — specific enough that a
  developer can implement it without asking questions
- BRD Ref: the exact FR number from the BRD (required)
- User Role: the avatar name from the charter who uses this
- Priority: inherit from BRD requirement
- Notes: API endpoint with HTTP method, validation rules,
  error states, edge cases

One BRD requirement may produce multiple FF entries.
Flag any FR that has no corresponding FF entry.
Save this as FFD.md and add it to the project.

Copy this prompt → paste into Claude

I am sharing my BRD and FFD [both attached].
Read both documents before proceeding.

Please create Process Maps for every major user workflow.
Number them sequentially (Map 1, Map 2...).

For each map:
1. Name: "Map N — [Workflow Name]"
2. Actors: which user role(s) are involved
3. FR/FF References: which requirement numbers this implements
4. Flow: indented step-by-step sequence:
   - User action (click, type, select)
   - Client request (HTTP method + endpoint + payload)
   - Server logic (validation, business rules, DB writes)
   - State transition (if status changes, name old → new)
   - User sees (screen, message, redirect)
5. Decision branches: every if/then path with else conditions
6. Error handling: every failure mode and what the user sees

End with a complete State Machine section listing every valid
status, what triggers it, and what triggers the next.

Save this as PROCESS_MAPS.md and add it to the project.

Kickoff prompt → paste into Claude Code

PROJECT: [Your project name]
STACK: [Your stack — e.g., Next.js 14, Prisma, PostgreSQL]

CONTEXT: I have attached four planning documents. Read all of
them before writing a single line of code:
  - PROJECT_CHARTER.md
  - BRD.md
  - FFD.md
  - PROCESS_MAPS.md

BEFORE YOU WRITE ANYTHING, confirm you've read all four
documents and tell me:
1. The 3 most critical user workflows you identified
2. Every database entity and its key relationships
3. The role model — who can access what
4. Which file you will create first, and why

THEN BUILD SPRINT 1 ONLY:
Authentication + database schema + base routing.
No feature UI yet. Foundation only.

BUILD RULES — apply for the entire project:
- Every function you write must reference its FR or FF number
  in a comment
- Build one file at a time. Stop and confirm before moving on.
- Never modify a file we've already confirmed as working
- If a requirement is ambiguous, ask — do not guess
- State what you're about to build before you build it

Start by confirming you've read all documents.
State your Sprint 1 build plan. Then begin.

Copy this prompt → paste into Claude

I am sharing my BRD and FFD [both attached].
Read both documents before proceeding.

Please generate a complete UAT test script. For each test:

TEST ID: T-001, T-002...
ROLE: which user role executes this test
PRECONDITIONS: what data must exist, what state the system is in
STEPS: numbered actions (click X, enter Y, verify Z)
EXPECTED RESULT: specific, observable outcome at each step
PASS CRITERIA: exactly what constitutes a pass
FAIL CRITERIA: exactly what constitutes a fail

Cover:
- Every major workflow in the FFD (reference FF numbers)
- Happy path for each user role
- Role-based access: verify each role CANNOT see what they
  should not — not just that they CAN see what they should
- Invalid input and error handling
- Empty states and edge cases
- Session persistence: navigate away, return, verify state

Flag any FF entry that has no corresponding test case.