@tekyzinc/gsd-t 2.28.14 → 2.29.10

package/README.md

@@ -18,7 +18,7 @@ A methodology for reliable, parallelizable development using Claude Code with op
 npx @tekyzinc/gsd-t install
 ```
 
-This installs 41 GSD-T commands + 4 utility commands (45 total) to `~/.claude/commands/` and the global CLAUDE.md to `~/.claude/CLAUDE.md`. Works on Windows, Mac, and Linux.
+This installs 42 GSD-T commands + 4 utility commands (46 total) to `~/.claude/commands/` and the global CLAUDE.md to `~/.claude/CLAUDE.md`. Works on Windows, Mac, and Linux.
 
 ### Start Using It
 
@@ -103,6 +103,7 @@ This will replace changed command files, back up your CLAUDE.md if customized, a
 | `/user:gsd-t-help {cmd}` | Detailed help for specific command | Manual |
 | `/user:gsd-t-prompt` | Help formulate your idea before committing | Manual |
 | `/user:gsd-t-brainstorm` | Creative exploration and idea generation | Manual |
+| `/user:gsd-t-prd` | Generate a GSD-T-optimized Product Requirements Document | Manual |
 
 ### Project Initialization
 
@@ -296,8 +297,8 @@ get-stuff-done-teams/
 ├── LICENSE
 ├── bin/
 │   └── gsd-t.js                       # CLI installer
-├── commands/                          # 45 slash commands
-│   ├── gsd-t-*.md                     # 41 GSD-T workflow commands
+├── commands/                          # 46 slash commands
+│   ├── gsd-t-*.md                     # 42 GSD-T workflow commands
 │   ├── gsd.md                         # GSD-T smart router
 │   ├── branch.md                      # Git branch helper
 │   ├── checkin.md                     # Auto-version + commit/push helper

package/commands/gsd-t-help.md

@@ -19,6 +19,7 @@ GETTING STARTED                                                        Manual
 ───────────────────────────────────────────────────────────────────────────────
   prompt              Help formulate your idea before committing to a command
   brainstorm          Creative exploration, rethinking, and idea generation
+  prd                 Generate a GSD-T-optimized Product Requirements Document
   setup               Generate or restructure project CLAUDE.md
   init                Initialize GSD-T structure in current project
   init-scan-setup     Full onboarding: git + init + scan + setup in one
@@ -153,6 +154,14 @@ Use these when user asks for help on a specific command:
 - **Use when**: You want to explore ideas, challenge assumptions, or break out of tunnel vision
 - **Modes**: Ideation, Enhancement, Rethink, Unstuck, Blue Sky
 
+### prd
+- **Summary**: Generate a GSD-T-optimized Product Requirements Document
+- **Auto-invoked**: No
+- **Reads**: `CLAUDE.md`, `.gsd-t/progress.md`, `docs/requirements.md`, `docs/architecture.md`, `.gsd-t/backlog.md`, `.gsd-t/contracts/`
+- **Creates/Updates**: `docs/prd.md`, `.gsd-t/progress.md` (Decision Log)
+- **Use when**: Starting a new project or feature and you need a structured PRD with REQ-IDs, data model, milestones, and exclusions — all optimized for downstream GSD-T commands
+- **Features**: GSD-T context-aware (reads existing docs), adaptive intake (skips questions answered by CLAUDE.md), produces REQ-IDs, field-level data model, file-path-level component list, suggested milestone sequence
+
 ### setup
 - **Summary**: Generate or restructure the project-level CLAUDE.md
 - **Auto-invoked**: No

package/commands/gsd-t-prd.md

@@ -0,0 +1,322 @@
+# 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

package/docs/GSD-T-README.md

@@ -72,6 +72,7 @@ GSD-T reads all state files and tells you exactly where you left off.
 | `/user:gsd-t-help {cmd}` | Detailed help for specific command | Manual |
 | `/user:gsd-t-prompt` | Help formulate your idea before committing | Manual |
 | `/user:gsd-t-brainstorm` | Creative exploration and idea generation | Manual |
+| `/user:gsd-t-prd` | Generate a GSD-T-optimized Product Requirements Document | Manual |
 
 ### Project Initialization
 

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@tekyzinc/gsd-t",
-  "version": "2.28.14",
-  "description": "GSD-T: Contract-Driven Development for Claude Code — 45 slash commands with backlog management, impact analysis, test sync, and milestone archival",
+  "version": "2.29.10",
+  "description": "GSD-T: Contract-Driven Development for Claude Code — 46 slash commands with backlog management, impact analysis, test sync, milestone archival, and PRD generation",
   "author": "Tekyz, Inc.",
   "license": "MIT",
   "repository": {

package/templates/CLAUDE-global.md

@@ -32,6 +32,7 @@ PROJECT or FEATURE or SCAN
 | `/user:gsd-t-help` | List all commands or get detailed help |
 | `/user:gsd-t-prompt` | Help formulate your idea before committing |
 | `/user:gsd-t-brainstorm` | Creative exploration and idea generation |
+| `/user:gsd-t-prd` | Generate a GSD-T-optimized Product Requirements Document |
 | `/user:gsd-t-project` | Full project → milestone roadmap |
 | `/user:gsd-t-feature` | Major feature → impact analysis + milestones |
 | `/user:gsd-t-scan` | Deep codebase analysis → techdebt.md |