@tekyzinc/gsd-t 2.28.14 → 2.29.11

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md CHANGED
@@ -18,7 +18,7 @@ A methodology for reliable, parallelizable development using Claude Code with op
18
18
  npx @tekyzinc/gsd-t install
19
19
  ```
20
20
 
21
- 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.
21
+ 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.
22
22
 
23
23
  ### Start Using It
24
24
 
@@ -103,6 +103,7 @@ This will replace changed command files, back up your CLAUDE.md if customized, a
103
103
  | `/user:gsd-t-help {cmd}` | Detailed help for specific command | Manual |
104
104
  | `/user:gsd-t-prompt` | Help formulate your idea before committing | Manual |
105
105
  | `/user:gsd-t-brainstorm` | Creative exploration and idea generation | Manual |
106
+ | `/user:gsd-t-prd` | Generate a GSD-T-optimized Product Requirements Document | Manual |
106
107
 
107
108
  ### Project Initialization
108
109
 
@@ -296,8 +297,8 @@ get-stuff-done-teams/
296
297
  ├── LICENSE
297
298
  ├── bin/
298
299
  │ └── gsd-t.js # CLI installer
299
- ├── commands/ # 45 slash commands
300
- │ ├── gsd-t-*.md # 41 GSD-T workflow commands
300
+ ├── commands/ # 46 slash commands
301
+ │ ├── gsd-t-*.md # 42 GSD-T workflow commands
301
302
  │ ├── gsd.md # GSD-T smart router
302
303
  │ ├── branch.md # Git branch helper
303
304
  │ ├── checkin.md # Auto-version + commit/push helper
package/bin/gsd-t.js CHANGED
@@ -245,7 +245,7 @@ function getRegisteredProjects() {
245
245
  try {
246
246
  const content = fs.readFileSync(PROJECTS_FILE, "utf8").trim();
247
247
  if (!content) return [];
248
- const lines = content.split("\n").map((l) => l.trim()).filter((l) => l && !l.startsWith("#"));
248
+ const lines = content.split("\n").map((l) => l.trim().split("|")[0].trim()).filter((l) => l && !l.startsWith("#"));
249
249
  return lines.filter((p) => {
250
250
  if (!validateProjectPath(p)) {
251
251
  warn(`Skipping invalid project path: ${p}`);
@@ -19,6 +19,7 @@ GETTING STARTED Manual
19
19
  ───────────────────────────────────────────────────────────────────────────────
20
20
  prompt Help formulate your idea before committing to a command
21
21
  brainstorm Creative exploration, rethinking, and idea generation
22
+ prd Generate a GSD-T-optimized Product Requirements Document
22
23
  setup Generate or restructure project CLAUDE.md
23
24
  init Initialize GSD-T structure in current project
24
25
  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:
153
154
  - **Use when**: You want to explore ideas, challenge assumptions, or break out of tunnel vision
154
155
  - **Modes**: Ideation, Enhancement, Rethink, Unstuck, Blue Sky
155
156
 
157
+ ### prd
158
+ - **Summary**: Generate a GSD-T-optimized Product Requirements Document
159
+ - **Auto-invoked**: No
160
+ - **Reads**: `CLAUDE.md`, `.gsd-t/progress.md`, `docs/requirements.md`, `docs/architecture.md`, `.gsd-t/backlog.md`, `.gsd-t/contracts/`
161
+ - **Creates/Updates**: `docs/prd.md`, `.gsd-t/progress.md` (Decision Log)
162
+ - **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
163
+ - **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
164
+
156
165
  ### setup
157
166
  - **Summary**: Generate or restructure the project-level CLAUDE.md
158
167
  - **Auto-invoked**: No
@@ -0,0 +1,322 @@
1
+ # GSD-T: PRD — Generate a Product Requirements Document
2
+
3
+ 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`.
4
+
5
+ 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.
6
+
7
+ ## Step 0: Launch via Subagent
8
+
9
+ To give PRD generation a fresh context window:
10
+
11
+ **If you are the orchestrating agent** (you received the slash command directly):
12
+
13
+ **OBSERVABILITY LOGGING (MANDATORY):**
14
+ Before spawning — run via Bash:
15
+ `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}`
16
+
17
+ Spawn a fresh subagent using the Task tool:
18
+ ```
19
+ subagent_type: general-purpose
20
+ prompt: "You are running gsd-t-prd for this request: {$ARGUMENTS}
21
+ Working directory: {current project root}
22
+ Read CLAUDE.md and .gsd-t/progress.md for project context, then execute gsd-t-prd starting at Step 1."
23
+ ```
24
+
25
+ After subagent returns — run via Bash:
26
+ `T_END=$(date +%s) && DT_END=$(date +"%Y-%m-%d %H:%M") && TOK_END=${CLAUDE_CONTEXT_TOKENS_USED:-0} && DURATION=$((T_END-T_START))`
27
+ Compute tokens and compaction:
28
+ - No compaction (TOK_END >= TOK_START): `TOKENS=$((TOK_END-TOK_START))`, COMPACTED=null
29
+ - Compaction detected (TOK_END < TOK_START): `TOKENS=$(((TOK_MAX-TOK_START)+TOK_END))`, COMPACTED=$DT_END
30
+ Append to `.gsd-t/token-log.md` (create with header `| Datetime-start | Datetime-end | Command | Step | Model | Duration(s) | Notes | Tokens | Compacted |` if missing):
31
+ `| {DT_START} | {DT_END} | gsd-t-prd | Step 0 | sonnet | {DURATION}s | prd: {topic summary} | {TOKENS} | {COMPACTED} |`
32
+
33
+ Relay the subagent's summary to the user. **Do not execute Steps 1–6 yourself.**
34
+
35
+ **If you are the spawned subagent** (your prompt says "starting at Step 1"):
36
+ Continue to Step 1 below.
37
+
38
+ ## Step 1: Load Project Context
39
+
40
+ Read all available GSD-T state to understand the project before asking the user anything:
41
+
42
+ 1. `CLAUDE.md` — tech stack, conventions, autonomy level
43
+ 2. `.gsd-t/progress.md` — current milestone, version, decision log
44
+ 3. `.gsd-t/backlog.md` (if exists) — queued items that may inform scope
45
+ 4. `docs/requirements.md` (if exists) — existing requirements to build on
46
+ 5. `docs/architecture.md` (if exists) — system design already established
47
+ 6. `docs/workflows.md` (if exists) — user flows already defined
48
+ 7. `.gsd-t/contracts/` (if exists) — domain interfaces already contracted
49
+
50
+ From $ARGUMENTS, identify:
51
+ - The product/feature topic (what the PRD is about)
52
+ - Any scope hints (greenfield, feature addition, rebuild)
53
+ - Any explicit constraints the user mentioned
54
+
55
+ ## Step 2: Classify the Build Type
56
+
57
+ Based on the loaded context and $ARGUMENTS, determine:
58
+
59
+ | Type | Signal | GSD-T Target |
60
+ |------|--------|-------------|
61
+ | **Project** | New app/system, no existing codebase or pre-init state | `gsd-t-project` |
62
+ | **Feature** | Addition to existing system (progress.md exists with milestones) | `gsd-t-feature` |
63
+ | **Multiple Features** | Several related additions to existing system | Multiple `gsd-t-feature` calls |
64
+
65
+ State the classification in your opening response. If ambiguous, present the two most likely options with brief reasoning and ask the user to confirm.
66
+
67
+ ## Step 3: Adaptive Intake
68
+
69
+ 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").
70
+
71
+ ### Always Required (fill from docs or ask):
72
+
73
+ 1. **Problem** — What problem does this solve? Who experiences it?
74
+ 2. **Users** — Who are the primary users? Any secondary types (admin, API consumer)?
75
+ 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)
76
+ 4. **Exclusions** — What is explicitly NOT in scope? (GSD-T requires exclusion lists at milestone, domain, and partition level)
77
+ 5. **Success Criteria** — How will you know it's working? Give measurable outcomes.
78
+
79
+ ### Tech Stack (fill from CLAUDE.md or ask):
80
+
81
+ 6. **Language & Runtime** — If not in CLAUDE.md
82
+ 7. **Database** — If not in CLAUDE.md
83
+ 8. **Auth Strategy** — If not in CLAUDE.md
84
+ 9. **Deployment Target** — If not in CLAUDE.md
85
+
86
+ ### Architecture (needed for partition):
87
+
88
+ 10. **Key Components** — What are the major pieces? (API server, worker, SPA, CLI, etc.)
89
+ 11. **Core Data Model** — What are the 3-5 most important entities? What are their relationships?
90
+ 12. **External Integrations** — Any third-party services? (payments, email, storage, AI APIs)
91
+
92
+ ### Feature-Specific (only when Type = Feature):
93
+
94
+ 13. **Integration Points** — Which existing screens, APIs, or flows does this touch?
95
+ 14. **DB Impact** — New tables, or extending existing ones? Which ones?
96
+ 15. **Auth/Permission Changes** — New roles, permissions, or access changes?
97
+ 16. **Breaking Changes** — API response shape changes? URL changes? UI flow changes?
98
+
99
+ ### Stop Asking When You Have:
100
+ - Clear problem statement with target user
101
+ - MVP boundary defined
102
+ - Full tech stack (fill from CLAUDE.md where available)
103
+ - Core data model entities and relationships (field-level)
104
+ - Key components identifiable at file-path level
105
+ - External integrations listed
106
+ - Explicit exclusions stated
107
+ - Measurable success criteria
108
+ - (For features) Integration points and DB impact clear
109
+
110
+ **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.
111
+
112
+ ## Step 4: Generate the PRD
113
+
114
+ Once intake is complete, generate the PRD in this exact format. Every section exists because a specific GSD-T command reads it.
115
+
116
+ ```markdown
117
+ # PRD: {Product/Feature Name}
118
+
119
+ Generated: {YYYY-MM-DD}
120
+ GSD-T Project: {project name from CLAUDE.md or progress.md}
121
+ Build Type: {Project | Feature | Multiple Features}
122
+
123
+ ## Problem Statement
124
+
125
+ {Who has this problem, what the problem is, why it matters. 2-4 sentences.}
126
+
127
+ ## Target Users
128
+
129
+ | User Type | Description | Key Needs |
130
+ |-----------|-------------|-----------|
131
+ | {type} | {who they are} | {what they need from this system} |
132
+
133
+ ## MVP Definition
134
+
135
+ {The minimum viable product — what must be true for the first usable version.}
136
+
137
+ ### MVP Includes
138
+ - {capability 1}
139
+ - {capability 2}
140
+
141
+ ### MVP Explicitly Excludes
142
+ - {exclusion 1} — {brief reason}
143
+ - {exclusion 2}
144
+
145
+ ## Tech Stack
146
+
147
+ | Layer | Choice | Rationale |
148
+ |-------|--------|-----------|
149
+ | Language/Runtime | {e.g., TypeScript / Node.js 20} | {why} |
150
+ | Framework | {e.g., Next.js 14 App Router} | {why} |
151
+ | Database | {e.g., PostgreSQL 16} | {why} |
152
+ | ORM/Query | {e.g., Drizzle ORM} | {why} |
153
+ | Frontend | {e.g., React 18 + Tailwind CSS} | {why} |
154
+ | Auth | {e.g., NextAuth.js with email + Google OAuth} | {why} |
155
+ | Testing | {e.g., Vitest + Playwright} | {why} |
156
+ | Deployment | {e.g., Vercel + Supabase} | {why} |
157
+
158
+ ## Functional Requirements
159
+
160
+ | ID | Requirement | Priority | User Type |
161
+ |----|-------------|----------|-----------|
162
+ | REQ-001 | {User can register with email and password} | P1 | {end-user} |
163
+ | REQ-002 | {User can log in and receive a session token} | P1 | {end-user} |
164
+ | REQ-003 | {description} | P1/P2/P3 | {user type} |
165
+
166
+ Priority guide:
167
+ - P1: Must have for MVP
168
+ - P2: Must have for v1 (post-MVP)
169
+ - P3: Nice to have / future
170
+
171
+ ## Technical Requirements
172
+
173
+ | ID | Requirement | Priority |
174
+ |----|-------------|----------|
175
+ | TECH-001 | {API response times under 200ms for core endpoints} | P1 |
176
+ | TECH-002 | {description} | P1/P2/P3 |
177
+
178
+ ## Non-Functional Requirements
179
+
180
+ | ID | Requirement | Metric |
181
+ |----|-------------|--------|
182
+ | NFR-001 | {Page load time} | {< 2 seconds on 3G} |
183
+ | NFR-002 | {description} | {measurable target} |
184
+
185
+ ## Architecture
186
+
187
+ ### System Overview
188
+
189
+ {2-3 paragraphs describing the high-level architecture — how components connect, data flows, deployment topology.}
190
+
191
+ ### Components
192
+
193
+ | Component | Purpose | Suggested Path | Dependencies |
194
+ |-----------|---------|---------------|--------------|
195
+ | {API Server} | {Handles all backend logic} | `src/server/` | {Database, Auth} |
196
+ | {Frontend App} | {User-facing SPA/SSR} | `src/app/` | {API Server} |
197
+ | {Background Worker} | {Async job processing} | `src/workers/` | {Database, Queue} |
198
+
199
+ ### Data Model
200
+
201
+ #### {Entity Name} (e.g., User)
202
+ | Field | Type | Constraints | Notes |
203
+ |-------|------|-------------|-------|
204
+ | id | uuid | PK | auto-generated |
205
+ | email | string | unique, not null | login identifier |
206
+ | {field} | {type} | {constraints} | {notes} |
207
+
208
+ ### API Structure
209
+
210
+ #### {Endpoint Group — e.g., Authentication}
211
+ | Method | Path | Auth | Description |
212
+ |--------|------|------|-------------|
213
+ | POST | /api/auth/register | none | Create new account |
214
+ | POST | /api/auth/login | none | Get session token |
215
+ | GET | /api/auth/me | required | Get current user |
216
+
217
+ ### External Integrations
218
+
219
+ | Service | Purpose | Auth Method | Notes |
220
+ |---------|---------|-------------|-------|
221
+ | {Stripe} | {Payment processing} | {API key} | {webhook for events} |
222
+
223
+ ### Key Design Decisions
224
+
225
+ | Decision | Rationale | Alternatives Considered |
226
+ |----------|-----------|------------------------|
227
+ | {Use JWTs for auth} | {Stateless, works with serverless} | {Sessions — rejected due to serverless} |
228
+
229
+ ## Suggested Milestone Sequence
230
+
231
+ Based on GSD-T's sequencing rules (Foundation → Schema → Core → Features → Polish):
232
+
233
+ ### Milestone 1: Foundation
234
+ **Goal**: {e.g., Project scaffolding, CI/CD, dev environment}
235
+ **Scope**: {list}
236
+ **NOT included**: {list}
237
+ **Success Criteria**:
238
+ - [ ] {criterion}
239
+
240
+ ### Milestone 2: {Core / MVP}
241
+ **Goal**: {outcome}
242
+ **Scope**: {list}
243
+ **NOT included**: {list}
244
+ **Success Criteria**:
245
+ - [ ] {criterion}
246
+
247
+ ### Milestone 3+: {as needed}
248
+
249
+ ## Open Questions
250
+
251
+ Items that couldn't be resolved during PRD intake — these become inputs to `gsd-t-discuss` during the relevant milestone:
252
+
253
+ - {question 1} — affects Milestone {N}
254
+ - {question 2}
255
+
256
+ ## Out of Scope (Full Project)
257
+
258
+ Everything explicitly excluded from the entire project, not just MVP:
259
+
260
+ - {exclusion 1}
261
+ - {exclusion 2}
262
+ ```
263
+
264
+ ## Step 5: Review and Finalize
265
+
266
+ After generating the PRD, ask the user to review:
267
+
268
+ "Here's your GSD-T-optimized PRD. Before I save it, a quick check:
269
+
270
+ 1. **Requirements** — I've identified {N} functional requirements (REQ-IDs). Anything missing or wrong?
271
+ 2. **Data model** — I've outlined {N} entities. Do the fields and relationships look right?
272
+ 3. **Exclusions** — Review the 'NOT included' and 'Out of Scope' lists. Anything misclassified?
273
+ 4. **Tech stack** — Any changes?
274
+ 5. **Milestone sequence** — Does the sequencing make sense for your delivery goals?"
275
+
276
+ Iterate until the user approves or says "looks good / save it."
277
+
278
+ ## Step 6: Save and Hand Off
279
+
280
+ Once approved, save to `docs/prd.md` (create `docs/` directory if it doesn't exist).
281
+
282
+ Then update `.gsd-t/progress.md` Decision Log:
283
+ ```
284
+ - {YYYY-MM-DD}: PRD generated for {product/feature name} — {N} functional requirements, {N} milestones, {N} entities. docs/prd.md created.
285
+ ```
286
+
287
+ Output the handoff:
288
+
289
+ ```
290
+ PRD saved to docs/prd.md.
291
+
292
+ Next steps:
293
+ ```
294
+
295
+ For a new project:
296
+ ```
297
+ /user:gsd-t-project {one-line summary}
298
+ ```
299
+ 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.
300
+
301
+ For a feature on an existing project:
302
+ ```
303
+ /user:gsd-t-feature {one-line summary}
304
+ ```
305
+ Then paste the PRD when prompted.
306
+
307
+ 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.
308
+
309
+ ## Agent Behavior Rules
310
+
311
+ 1. **Infer when you can** — if CLAUDE.md says TypeScript/Node + Postgres, state those as assumed in the PRD and skip asking about them
312
+ 2. **One question at a time** unless user requests batch mode
313
+ 3. **REQ-IDs are non-negotiable** — GSD-T plan validation fails without them
314
+ 4. **Exclusions at every level** — MVP level, milestone level, project level. GSD-T partitioning depends on knowing what's OUT
315
+ 5. **Data model must be field-level** — "a users table" is not enough. GSD-T schema-contract.md needs field names, types, and constraints
316
+ 6. **Components need suggested file paths** — "the API" is not enough. GSD-T partition draws domain boundaries by file ownership
317
+ 7. **Keep momentum** — if you have enough for a solid PRD with reasonable assumptions, produce it and let the user refine in Step 5
318
+ 8. **Flag risks early** — if choices have known pitfalls, mention as a consideration (e.g., SQLite for multi-user web app), not a blocker
319
+ 9. **Never ask what you can read** — check CLAUDE.md, progress.md, and docs/ before asking about tech stack, existing patterns, or current state
320
+ 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
321
+
322
+ $ARGUMENTS
@@ -72,6 +72,7 @@ GSD-T reads all state files and tells you exactly where you left off.
72
72
  | `/user:gsd-t-help {cmd}` | Detailed help for specific command | Manual |
73
73
  | `/user:gsd-t-prompt` | Help formulate your idea before committing | Manual |
74
74
  | `/user:gsd-t-brainstorm` | Creative exploration and idea generation | Manual |
75
+ | `/user:gsd-t-prd` | Generate a GSD-T-optimized Product Requirements Document | Manual |
75
76
 
76
77
  ### Project Initialization
77
78
 
package/package.json CHANGED
@@ -1,7 +1,7 @@
1
1
  {
2
2
  "name": "@tekyzinc/gsd-t",
3
- "version": "2.28.14",
4
- "description": "GSD-T: Contract-Driven Development for Claude Code — 45 slash commands with backlog management, impact analysis, test sync, and milestone archival",
3
+ "version": "2.29.11",
4
+ "description": "GSD-T: Contract-Driven Development for Claude Code — 46 slash commands with backlog management, impact analysis, test sync, milestone archival, and PRD generation",
5
5
  "author": "Tekyz, Inc.",
6
6
  "license": "MIT",
7
7
  "repository": {
@@ -32,6 +32,7 @@ PROJECT or FEATURE or SCAN
32
32
  | `/user:gsd-t-help` | List all commands or get detailed help |
33
33
  | `/user:gsd-t-prompt` | Help formulate your idea before committing |
34
34
  | `/user:gsd-t-brainstorm` | Creative exploration and idea generation |
35
+ | `/user:gsd-t-prd` | Generate a GSD-T-optimized Product Requirements Document |
35
36
  | `/user:gsd-t-project` | Full project → milestone roadmap |
36
37
  | `/user:gsd-t-feature` | Major feature → impact analysis + milestones |
37
38
  | `/user:gsd-t-scan` | Deep codebase analysis → techdebt.md |