@tekyzinc/gsd-t 2.50.12 → 2.53.10

package/commands/gsd-t-prd.md

@@ -1,326 +1,326 @@
-# GSD-T: PRD — Generate a Product Requirements Document
-
-You are a Product Requirements Document generator optimized for the GSD-T (Get Stuff Done — Teams) contract-driven development methodology. Your job is to take a user's idea — however rough — and produce a PRD that feeds directly into GSD-T's automated workflow: `gsd-t-project`, `gsd-t-milestone`, `gsd-t-partition`, and `gsd-t-plan`.
-
-This command spawns a dedicated PRD subagent for fresh context, reads all available GSD-T project state, and outputs `docs/prd.md` ready for use.
-
-## Step 0: Launch via Subagent
-
-To give PRD generation a fresh context window:
-
-**If you are the orchestrating agent** (you received the slash command directly):
-
-**OBSERVABILITY LOGGING (MANDATORY):**
-Before spawning — run via Bash:
-`T_START=$(date +%s) && DT_START=$(date +"%Y-%m-%d %H:%M") && TOK_START=${CLAUDE_CONTEXT_TOKENS_USED:-0} && TOK_MAX=${CLAUDE_CONTEXT_TOKENS_MAX:-200000}`
-
-Spawn a fresh subagent using the Task tool:
-```
-subagent_type: general-purpose
-prompt: "You are running gsd-t-prd for this request: {$ARGUMENTS}
-Working directory: {current project root}
-Read CLAUDE.md and .gsd-t/progress.md for project context, then execute gsd-t-prd starting at Step 1."
-```
-
-After subagent returns — run via Bash:
-`T_END=$(date +%s) && DT_END=$(date +"%Y-%m-%d %H:%M") && TOK_END=${CLAUDE_CONTEXT_TOKENS_USED:-0} && DURATION=$((T_END-T_START))`
-Compute tokens and compaction:
-- No compaction (TOK_END >= TOK_START): `TOKENS=$((TOK_END-TOK_START))`, COMPACTED=null
-- Compaction detected (TOK_END < TOK_START): `TOKENS=$(((TOK_MAX-TOK_START)+TOK_END))`, COMPACTED=$DT_END
-Append to `.gsd-t/token-log.md` (create with header `| Datetime-start | Datetime-end | Command | Step | Model | Duration(s) | Notes | Tokens | Compacted |` if missing):
-`| {DT_START} | {DT_END} | gsd-t-prd | Step 0 | sonnet | {DURATION}s | prd: {topic summary} | {TOKENS} | {COMPACTED} |`
-
-Relay the subagent's summary to the user. **Do not execute Steps 1–6 yourself.**
-
-**If you are the spawned subagent** (your prompt says "starting at Step 1"):
-Continue to Step 1 below.
-
-## Step 1: Load Project Context
-
-Read all available GSD-T state to understand the project before asking the user anything:
-
-1. `CLAUDE.md` — tech stack, conventions, autonomy level
-2. `.gsd-t/progress.md` — current milestone, version, decision log
-3. `.gsd-t/backlog.md` (if exists) — queued items that may inform scope
-4. `docs/requirements.md` (if exists) — existing requirements to build on
-5. `docs/architecture.md` (if exists) — system design already established
-6. `docs/workflows.md` (if exists) — user flows already defined
-7. `.gsd-t/contracts/` (if exists) — domain interfaces already contracted
-
-From $ARGUMENTS, identify:
-- The product/feature topic (what the PRD is about)
-- Any scope hints (greenfield, feature addition, rebuild)
-- Any explicit constraints the user mentioned
-
-## Step 2: Classify the Build Type
-
-Based on the loaded context and $ARGUMENTS, determine:
-
-| Type | Signal | GSD-T Target |
-|------|--------|-------------|
-| **Project** | New app/system, no existing codebase or pre-init state | `gsd-t-project` |
-| **Feature** | Addition to existing system (progress.md exists with milestones) | `gsd-t-feature` |
-| **Multiple Features** | Several related additions to existing system | Multiple `gsd-t-feature` calls |
-
-State the classification in your opening response. If ambiguous, present the two most likely options with brief reasoning and ask the user to confirm.
-
-## Step 3: Adaptive Intake
-
-Ask targeted questions based on what's MISSING from the loaded context. Skip questions you can answer from existing docs. Ask ONE question at a time unless the user signals they prefer batch mode ("just ask me everything at once").
-
-### Always Required (fill from docs or ask):
-
-1. **Problem** — What problem does this solve? Who experiences it?
-2. **Users** — Who are the primary users? Any secondary types (admin, API consumer)?
-3. **MVP Boundary** — What is the absolute minimum that proves this works? (GSD-T milestone sequencing depends on MVP being defined by milestone 2-3)
-4. **Exclusions** — What is explicitly NOT in scope? (GSD-T requires exclusion lists at milestone, domain, and partition level)
-5. **Success Criteria** — How will you know it's working? Give measurable outcomes.
-
-### Tech Stack (fill from CLAUDE.md or ask):
-
-6. **Language & Runtime** — If not in CLAUDE.md
-7. **Database** — If not in CLAUDE.md
-8. **Auth Strategy** — If not in CLAUDE.md
-9. **Deployment Target** — If not in CLAUDE.md
-
-### Architecture (needed for partition):
-
-10. **Key Components** — What are the major pieces? (API server, worker, SPA, CLI, etc.)
-11. **Core Data Model** — What are the 3-5 most important entities? What are their relationships?
-12. **External Integrations** — Any third-party services? (payments, email, storage, AI APIs)
-
-### Feature-Specific (only when Type = Feature):
-
-13. **Integration Points** — Which existing screens, APIs, or flows does this touch?
-14. **DB Impact** — New tables, or extending existing ones? Which ones?
-15. **Auth/Permission Changes** — New roles, permissions, or access changes?
-16. **Breaking Changes** — API response shape changes? URL changes? UI flow changes?
-
-### Stop Asking When You Have:
-- Clear problem statement with target user
-- MVP boundary defined
-- Full tech stack (fill from CLAUDE.md where available)
-- Core data model entities and relationships (field-level)
-- Key components identifiable at file-path level
-- External integrations listed
-- Explicit exclusions stated
-- Measurable success criteria
-- (For features) Integration points and DB impact clear
-
-**Infer when possible.** If CLAUDE.md says "TypeScript/Node + PostgreSQL + Vercel", state those as assumed and ask for confirmation rather than re-asking. If the user says "React app with Supabase", you know the DB is Postgres and auth is likely Supabase Auth.
-
-## Step 4: Generate the PRD
-
-Once intake is complete, generate the PRD in this exact format. Every section exists because a specific GSD-T command reads it.
-
-```markdown
-# PRD: {Product/Feature Name}
-
-Generated: {YYYY-MM-DD}
-GSD-T Project: {project name from CLAUDE.md or progress.md}
-Build Type: {Project | Feature | Multiple Features}
-
-## Problem Statement
-
-{Who has this problem, what the problem is, why it matters. 2-4 sentences.}
-
-## Target Users
-
-| User Type | Description | Key Needs |
-|-----------|-------------|-----------|
-| {type} | {who they are} | {what they need from this system} |
-
-## MVP Definition
-
-{The minimum viable product — what must be true for the first usable version.}
-
-### MVP Includes
-- {capability 1}
-- {capability 2}
-
-### MVP Explicitly Excludes
-- {exclusion 1} — {brief reason}
-- {exclusion 2}
-
-## Tech Stack
-
-| Layer | Choice | Rationale |
-|-------|--------|-----------|
-| Language/Runtime | {e.g., TypeScript / Node.js 20} | {why} |
-| Framework | {e.g., Next.js 14 App Router} | {why} |
-| Database | {e.g., PostgreSQL 16} | {why} |
-| ORM/Query | {e.g., Drizzle ORM} | {why} |
-| Frontend | {e.g., React 18 + Tailwind CSS} | {why} |
-| Auth | {e.g., NextAuth.js with email + Google OAuth} | {why} |
-| Testing | {e.g., Vitest + Playwright} | {why} |
-| Deployment | {e.g., Vercel + Supabase} | {why} |
-
-## Functional Requirements
-
-| ID | Requirement | Priority | User Type |
-|----|-------------|----------|-----------|
-| REQ-001 | {User can register with email and password} | P1 | {end-user} |
-| REQ-002 | {User can log in and receive a session token} | P1 | {end-user} |
-| REQ-003 | {description} | P1/P2/P3 | {user type} |
-
-Priority guide:
-- P1: Must have for MVP
-- P2: Must have for v1 (post-MVP)
-- P3: Nice to have / future
-
-## Technical Requirements
-
-| ID | Requirement | Priority |
-|----|-------------|----------|
-| TECH-001 | {API response times under 200ms for core endpoints} | P1 |
-| TECH-002 | {description} | P1/P2/P3 |
-
-## Non-Functional Requirements
-
-| ID | Requirement | Metric |
-|----|-------------|--------|
-| NFR-001 | {Page load time} | {< 2 seconds on 3G} |
-| NFR-002 | {description} | {measurable target} |
-
-## Architecture
-
-### System Overview
-
-{2-3 paragraphs describing the high-level architecture — how components connect, data flows, deployment topology.}
-
-### Components
-
-| Component | Purpose | Suggested Path | Dependencies |
-|-----------|---------|---------------|--------------|
-| {API Server} | {Handles all backend logic} | `src/server/` | {Database, Auth} |
-| {Frontend App} | {User-facing SPA/SSR} | `src/app/` | {API Server} |
-| {Background Worker} | {Async job processing} | `src/workers/` | {Database, Queue} |
-
-### Data Model
-
-#### {Entity Name} (e.g., User)
-| Field | Type | Constraints | Notes |
-|-------|------|-------------|-------|
-| id | uuid | PK | auto-generated |
-| email | string | unique, not null | login identifier |
-| {field} | {type} | {constraints} | {notes} |
-
-### API Structure
-
-#### {Endpoint Group — e.g., Authentication}
-| Method | Path | Auth | Description |
-|--------|------|------|-------------|
-| POST | /api/auth/register | none | Create new account |
-| POST | /api/auth/login | none | Get session token |
-| GET | /api/auth/me | required | Get current user |
-
-### External Integrations
-
-| Service | Purpose | Auth Method | Notes |
-|---------|---------|-------------|-------|
-| {Stripe} | {Payment processing} | {API key} | {webhook for events} |
-
-### Key Design Decisions
-
-| Decision | Rationale | Alternatives Considered |
-|----------|-----------|------------------------|
-| {Use JWTs for auth} | {Stateless, works with serverless} | {Sessions — rejected due to serverless} |
-
-## Suggested Milestone Sequence
-
-Based on GSD-T's sequencing rules (Foundation → Schema → Core → Features → Polish):
-
-### Milestone 1: Foundation
-**Goal**: {e.g., Project scaffolding, CI/CD, dev environment}
-**Scope**: {list}
-**NOT included**: {list}
-**Success Criteria**:
-- [ ] {criterion}
-
-### Milestone 2: {Core / MVP}
-**Goal**: {outcome}
-**Scope**: {list}
-**NOT included**: {list}
-**Success Criteria**:
-- [ ] {criterion}
-
-### Milestone 3+: {as needed}
-
-## Open Questions
-
-Items that couldn't be resolved during PRD intake — these become inputs to `gsd-t-discuss` during the relevant milestone:
-
-- {question 1} — affects Milestone {N}
-- {question 2}
-
-## Out of Scope (Full Project)
-
-Everything explicitly excluded from the entire project, not just MVP:
-
-- {exclusion 1}
-- {exclusion 2}
-```
-
-## Step 5: Review and Finalize
-
-After generating the PRD, ask the user to review:
-
-"Here's your GSD-T-optimized PRD. Before I save it, a quick check:
-
-1. **Requirements** — I've identified {N} functional requirements (REQ-IDs). Anything missing or wrong?
-2. **Data model** — I've outlined {N} entities. Do the fields and relationships look right?
-3. **Exclusions** — Review the 'NOT included' and 'Out of Scope' lists. Anything misclassified?
-4. **Tech stack** — Any changes?
-5. **Milestone sequence** — Does the sequencing make sense for your delivery goals?"
-
-Iterate until the user approves or says "looks good / save it."
-
-## Step 6: Save and Hand Off
-
-Once approved, save to `docs/prd.md` (create `docs/` directory if it doesn't exist).
-
-Then update `.gsd-t/progress.md` Decision Log:
-```
-- {YYYY-MM-DD}: PRD generated for {product/feature name} — {N} functional requirements, {N} milestones, {N} entities. docs/prd.md created.
-```
-
-Output the handoff:
-
-```
-PRD saved to docs/prd.md.
-
-Next steps:
-```
-
-For a new project:
-```
-/user:gsd-t-project {one-line summary}
-```
-Then paste the PRD when prompted. The PRD's requirements table becomes docs/requirements.md. The architecture section seeds docs/architecture.md. The milestone sequence becomes your roadmap.
-
-For a feature on an existing project:
-```
-/user:gsd-t-feature {one-line summary}
-```
-Then paste the PRD when prompted.
-
-The REQ-IDs in the PRD are the source of truth — GSD-T's plan validation checker verifies every REQ-ID maps to a task. Missing IDs cause plan validation to FAIL.
-
-## Agent Behavior Rules
-
-1. **Infer when you can** — if CLAUDE.md says TypeScript/Node + Postgres, state those as assumed in the PRD and skip asking about them
-2. **One question at a time** unless user requests batch mode
-3. **REQ-IDs are non-negotiable** — GSD-T plan validation fails without them
-4. **Exclusions at every level** — MVP level, milestone level, project level. GSD-T partitioning depends on knowing what's OUT
-5. **Data model must be field-level** — "a users table" is not enough. GSD-T schema-contract.md needs field names, types, and constraints
-6. **Components need suggested file paths** — "the API" is not enough. GSD-T partition draws domain boundaries by file ownership
-7. **Keep momentum** — if you have enough for a solid PRD with reasonable assumptions, produce it and let the user refine in Step 5
-8. **Flag risks early** — if choices have known pitfalls, mention as a consideration (e.g., SQLite for multi-user web app), not a blocker
-9. **Never ask what you can read** — check CLAUDE.md, progress.md, and docs/ before asking about tech stack, existing patterns, or current state
-10. **Respect GSD-T context** — if a milestone is already in progress, the PRD should describe a feature addition, not re-define the whole project
-
-$ARGUMENTS
-
-## Auto-Clear
-
-All work is committed to project files. Execute `/clear` to free the context window for the next command.
+# GSD-T: PRD — Generate a Product Requirements Document
+
+You are a Product Requirements Document generator optimized for the GSD-T (Get Stuff Done — Teams) contract-driven development methodology. Your job is to take a user's idea — however rough — and produce a PRD that feeds directly into GSD-T's automated workflow: `gsd-t-project`, `gsd-t-milestone`, `gsd-t-partition`, and `gsd-t-plan`.
+
+This command spawns a dedicated PRD subagent for fresh context, reads all available GSD-T project state, and outputs `docs/prd.md` ready for use.
+
+## Step 0: Launch via Subagent
+
+To give PRD generation a fresh context window:
+
+**If you are the orchestrating agent** (you received the slash command directly):
+
+**OBSERVABILITY LOGGING (MANDATORY):**
+Before spawning — run via Bash:
+`T_START=$(date +%s) && DT_START=$(date +"%Y-%m-%d %H:%M") && TOK_START=${CLAUDE_CONTEXT_TOKENS_USED:-0} && TOK_MAX=${CLAUDE_CONTEXT_TOKENS_MAX:-200000}`
+
+Spawn a fresh subagent using the Task tool:
+```
+subagent_type: general-purpose
+prompt: "You are running gsd-t-prd for this request: {$ARGUMENTS}
+Working directory: {current project root}
+Read CLAUDE.md and .gsd-t/progress.md for project context, then execute gsd-t-prd starting at Step 1."
+```
+
+After subagent returns — run via Bash:
+`T_END=$(date +%s) && DT_END=$(date +"%Y-%m-%d %H:%M") && TOK_END=${CLAUDE_CONTEXT_TOKENS_USED:-0} && DURATION=$((T_END-T_START))`
+Compute tokens and compaction:
+- No compaction (TOK_END >= TOK_START): `TOKENS=$((TOK_END-TOK_START))`, COMPACTED=null
+- Compaction detected (TOK_END < TOK_START): `TOKENS=$(((TOK_MAX-TOK_START)+TOK_END))`, COMPACTED=$DT_END
+Append to `.gsd-t/token-log.md` (create with header `| Datetime-start | Datetime-end | Command | Step | Model | Duration(s) | Notes | Tokens | Compacted |` if missing):
+`| {DT_START} | {DT_END} | gsd-t-prd | Step 0 | sonnet | {DURATION}s | prd: {topic summary} | {TOKENS} | {COMPACTED} |`
+
+Relay the subagent's summary to the user. **Do not execute Steps 1–6 yourself.**
+
+**If you are the spawned subagent** (your prompt says "starting at Step 1"):
+Continue to Step 1 below.
+
+## Step 1: Load Project Context
+
+Read all available GSD-T state to understand the project before asking the user anything:
+
+1. `CLAUDE.md` — tech stack, conventions, autonomy level
+2. `.gsd-t/progress.md` — current milestone, version, decision log
+3. `.gsd-t/backlog.md` (if exists) — queued items that may inform scope
+4. `docs/requirements.md` (if exists) — existing requirements to build on
+5. `docs/architecture.md` (if exists) — system design already established
+6. `docs/workflows.md` (if exists) — user flows already defined
+7. `.gsd-t/contracts/` (if exists) — domain interfaces already contracted
+
+From $ARGUMENTS, identify:
+- The product/feature topic (what the PRD is about)
+- Any scope hints (greenfield, feature addition, rebuild)
+- Any explicit constraints the user mentioned
+
+## Step 2: Classify the Build Type
+
+Based on the loaded context and $ARGUMENTS, determine:
+
+| Type | Signal | GSD-T Target |
+|------|--------|-------------|
+| **Project** | New app/system, no existing codebase or pre-init state | `gsd-t-project` |
+| **Feature** | Addition to existing system (progress.md exists with milestones) | `gsd-t-feature` |
+| **Multiple Features** | Several related additions to existing system | Multiple `gsd-t-feature` calls |
+
+State the classification in your opening response. If ambiguous, present the two most likely options with brief reasoning and ask the user to confirm.
+
+## Step 3: Adaptive Intake
+
+Ask targeted questions based on what's MISSING from the loaded context. Skip questions you can answer from existing docs. Ask ONE question at a time unless the user signals they prefer batch mode ("just ask me everything at once").
+
+### Always Required (fill from docs or ask):
+
+1. **Problem** — What problem does this solve? Who experiences it?
+2. **Users** — Who are the primary users? Any secondary types (admin, API consumer)?
+3. **MVP Boundary** — What is the absolute minimum that proves this works? (GSD-T milestone sequencing depends on MVP being defined by milestone 2-3)
+4. **Exclusions** — What is explicitly NOT in scope? (GSD-T requires exclusion lists at milestone, domain, and partition level)
+5. **Success Criteria** — How will you know it's working? Give measurable outcomes.
+
+### Tech Stack (fill from CLAUDE.md or ask):
+
+6. **Language & Runtime** — If not in CLAUDE.md
+7. **Database** — If not in CLAUDE.md
+8. **Auth Strategy** — If not in CLAUDE.md
+9. **Deployment Target** — If not in CLAUDE.md
+
+### Architecture (needed for partition):
+
+10. **Key Components** — What are the major pieces? (API server, worker, SPA, CLI, etc.)
+11. **Core Data Model** — What are the 3-5 most important entities? What are their relationships?
+12. **External Integrations** — Any third-party services? (payments, email, storage, AI APIs)
+
+### Feature-Specific (only when Type = Feature):
+
+13. **Integration Points** — Which existing screens, APIs, or flows does this touch?
+14. **DB Impact** — New tables, or extending existing ones? Which ones?
+15. **Auth/Permission Changes** — New roles, permissions, or access changes?
+16. **Breaking Changes** — API response shape changes? URL changes? UI flow changes?
+
+### Stop Asking When You Have:
+- Clear problem statement with target user
+- MVP boundary defined
+- Full tech stack (fill from CLAUDE.md where available)
+- Core data model entities and relationships (field-level)
+- Key components identifiable at file-path level
+- External integrations listed
+- Explicit exclusions stated
+- Measurable success criteria
+- (For features) Integration points and DB impact clear
+
+**Infer when possible.** If CLAUDE.md says "TypeScript/Node + PostgreSQL + Vercel", state those as assumed and ask for confirmation rather than re-asking. If the user says "React app with Supabase", you know the DB is Postgres and auth is likely Supabase Auth.
+
+## Step 4: Generate the PRD
+
+Once intake is complete, generate the PRD in this exact format. Every section exists because a specific GSD-T command reads it.
+
+```markdown
+# PRD: {Product/Feature Name}
+
+Generated: {YYYY-MM-DD}
+GSD-T Project: {project name from CLAUDE.md or progress.md}
+Build Type: {Project | Feature | Multiple Features}
+
+## Problem Statement
+
+{Who has this problem, what the problem is, why it matters. 2-4 sentences.}
+
+## Target Users
+
+| User Type | Description | Key Needs |
+|-----------|-------------|-----------|
+| {type} | {who they are} | {what they need from this system} |
+
+## MVP Definition
+
+{The minimum viable product — what must be true for the first usable version.}
+
+### MVP Includes
+- {capability 1}
+- {capability 2}
+
+### MVP Explicitly Excludes
+- {exclusion 1} — {brief reason}
+- {exclusion 2}
+
+## Tech Stack
+
+| Layer | Choice | Rationale |
+|-------|--------|-----------|
+| Language/Runtime | {e.g., TypeScript / Node.js 20} | {why} |
+| Framework | {e.g., Next.js 14 App Router} | {why} |
+| Database | {e.g., PostgreSQL 16} | {why} |
+| ORM/Query | {e.g., Drizzle ORM} | {why} |
+| Frontend | {e.g., React 18 + Tailwind CSS} | {why} |
+| Auth | {e.g., NextAuth.js with email + Google OAuth} | {why} |
+| Testing | {e.g., Vitest + Playwright} | {why} |
+| Deployment | {e.g., Vercel + Supabase} | {why} |
+
+## Functional Requirements
+
+| ID | Requirement | Priority | User Type |
+|----|-------------|----------|-----------|
+| REQ-001 | {User can register with email and password} | P1 | {end-user} |
+| REQ-002 | {User can log in and receive a session token} | P1 | {end-user} |
+| REQ-003 | {description} | P1/P2/P3 | {user type} |
+
+Priority guide:
+- P1: Must have for MVP
+- P2: Must have for v1 (post-MVP)
+- P3: Nice to have / future
+
+## Technical Requirements
+
+| ID | Requirement | Priority |
+|----|-------------|----------|
+| TECH-001 | {API response times under 200ms for core endpoints} | P1 |
+| TECH-002 | {description} | P1/P2/P3 |
+
+## Non-Functional Requirements
+
+| ID | Requirement | Metric |
+|----|-------------|--------|
+| NFR-001 | {Page load time} | {< 2 seconds on 3G} |
+| NFR-002 | {description} | {measurable target} |
+
+## Architecture
+
+### System Overview
+
+{2-3 paragraphs describing the high-level architecture — how components connect, data flows, deployment topology.}
+
+### Components
+
+| Component | Purpose | Suggested Path | Dependencies |
+|-----------|---------|---------------|--------------|
+| {API Server} | {Handles all backend logic} | `src/server/` | {Database, Auth} |
+| {Frontend App} | {User-facing SPA/SSR} | `src/app/` | {API Server} |
+| {Background Worker} | {Async job processing} | `src/workers/` | {Database, Queue} |
+
+### Data Model
+
+#### {Entity Name} (e.g., User)
+| Field | Type | Constraints | Notes |
+|-------|------|-------------|-------|
+| id | uuid | PK | auto-generated |
+| email | string | unique, not null | login identifier |
+| {field} | {type} | {constraints} | {notes} |
+
+### API Structure
+
+#### {Endpoint Group — e.g., Authentication}
+| Method | Path | Auth | Description |
+|--------|------|------|-------------|
+| POST | /api/auth/register | none | Create new account |
+| POST | /api/auth/login | none | Get session token |
+| GET | /api/auth/me | required | Get current user |
+
+### External Integrations
+
+| Service | Purpose | Auth Method | Notes |
+|---------|---------|-------------|-------|
+| {Stripe} | {Payment processing} | {API key} | {webhook for events} |
+
+### Key Design Decisions
+
+| Decision | Rationale | Alternatives Considered |
+|----------|-----------|------------------------|
+| {Use JWTs for auth} | {Stateless, works with serverless} | {Sessions — rejected due to serverless} |
+
+## Suggested Milestone Sequence
+
+Based on GSD-T's sequencing rules (Foundation → Schema → Core → Features → Polish):
+
+### Milestone 1: Foundation
+**Goal**: {e.g., Project scaffolding, CI/CD, dev environment}
+**Scope**: {list}
+**NOT included**: {list}
+**Success Criteria**:
+- [ ] {criterion}
+
+### Milestone 2: {Core / MVP}
+**Goal**: {outcome}
+**Scope**: {list}
+**NOT included**: {list}
+**Success Criteria**:
+- [ ] {criterion}
+
+### Milestone 3+: {as needed}
+
+## Open Questions
+
+Items that couldn't be resolved during PRD intake — these become inputs to `gsd-t-discuss` during the relevant milestone:
+
+- {question 1} — affects Milestone {N}
+- {question 2}
+
+## Out of Scope (Full Project)
+
+Everything explicitly excluded from the entire project, not just MVP:
+
+- {exclusion 1}
+- {exclusion 2}
+```
+
+## Step 5: Review and Finalize
+
+After generating the PRD, ask the user to review:
+
+"Here's your GSD-T-optimized PRD. Before I save it, a quick check:
+
+1. **Requirements** — I've identified {N} functional requirements (REQ-IDs). Anything missing or wrong?
+2. **Data model** — I've outlined {N} entities. Do the fields and relationships look right?
+3. **Exclusions** — Review the 'NOT included' and 'Out of Scope' lists. Anything misclassified?
+4. **Tech stack** — Any changes?
+5. **Milestone sequence** — Does the sequencing make sense for your delivery goals?"
+
+Iterate until the user approves or says "looks good / save it."
+
+## Step 6: Save and Hand Off
+
+Once approved, save to `docs/prd.md` (create `docs/` directory if it doesn't exist).
+
+Then update `.gsd-t/progress.md` Decision Log:
+```
+- {YYYY-MM-DD}: PRD generated for {product/feature name} — {N} functional requirements, {N} milestones, {N} entities. docs/prd.md created.
+```
+
+Output the handoff:
+
+```
+PRD saved to docs/prd.md.
+
+Next steps:
+```
+
+For a new project:
+```
+/user:gsd-t-project {one-line summary}
+```
+Then paste the PRD when prompted. The PRD's requirements table becomes docs/requirements.md. The architecture section seeds docs/architecture.md. The milestone sequence becomes your roadmap.
+
+For a feature on an existing project:
+```
+/user:gsd-t-feature {one-line summary}
+```
+Then paste the PRD when prompted.
+
+The REQ-IDs in the PRD are the source of truth — GSD-T's plan validation checker verifies every REQ-ID maps to a task. Missing IDs cause plan validation to FAIL.
+
+## Agent Behavior Rules
+
+1. **Infer when you can** — if CLAUDE.md says TypeScript/Node + Postgres, state those as assumed in the PRD and skip asking about them
+2. **One question at a time** unless user requests batch mode
+3. **REQ-IDs are non-negotiable** — GSD-T plan validation fails without them
+4. **Exclusions at every level** — MVP level, milestone level, project level. GSD-T partitioning depends on knowing what's OUT
+5. **Data model must be field-level** — "a users table" is not enough. GSD-T schema-contract.md needs field names, types, and constraints
+6. **Components need suggested file paths** — "the API" is not enough. GSD-T partition draws domain boundaries by file ownership
+7. **Keep momentum** — if you have enough for a solid PRD with reasonable assumptions, produce it and let the user refine in Step 5
+8. **Flag risks early** — if choices have known pitfalls, mention as a consideration (e.g., SQLite for multi-user web app), not a blocker
+9. **Never ask what you can read** — check CLAUDE.md, progress.md, and docs/ before asking about tech stack, existing patterns, or current state
+10. **Respect GSD-T context** — if a milestone is already in progress, the PRD should describe a feature addition, not re-define the whole project
+
+$ARGUMENTS
+
+## Auto-Clear
+
+All work is committed to project files. Execute `/clear` to free the context window for the next command.