gm-codex 2.0.25 → 2.0.26

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.
@@ -0,0 +1,335 @@
1
+ ---
2
+ name: planning
3
+ description: PRD construction for work planning. Use this skill in PLAN phase to build .prd file with complete dependency graph of all items, edge cases, and subtasks before execution begins.
4
+ allowed-tools: Write
5
+ ---
6
+
7
+ # Work Planning with PRD Construction
8
+
9
+ ## Overview
10
+
11
+ This skill constructs `./.prd` (Product Requirements Document) files for structured work tracking. The PRD is a **single source of truth** that captures every possible item to complete, organized as a dependency graph for parallel execution.
12
+
13
+ **CRITICAL**: The PRD must be created in PLAN phase before any work begins. It blocks all other work until complete. It is frozen after creation—only items may be removed as they complete. No additions or reorganizations after plan is created.
14
+
15
+ ## When to Use This Skill
16
+
17
+ Use `planning` skill when:
18
+ - Starting a new task or initiative
19
+ - User requests multiple items/features/fixes that need coordination
20
+ - Work has dependencies, parallellizable items, or complex stages
21
+ - You need to track progress across multiple independent work streams
22
+
23
+ **Do NOT use** if task is trivial (single item under 5 minutes).
24
+
25
+ ## PRD Structure
26
+
27
+ Each PRD contains:
28
+ - **items**: Array of work items with dependencies
29
+ - **completed**: Empty list (populated as items finish)
30
+ - **metadata**: Total estimates, phases, notes
31
+
32
+ ### Item Fields
33
+
34
+ ```json
35
+ {
36
+ "id": "1",
37
+ "subject": "imperative verb describing outcome",
38
+ "status": "pending",
39
+ "description": "detailed requirement",
40
+ "blocking": ["2", "3"],
41
+ "blockedBy": ["4"],
42
+ "effort": "small|medium|large",
43
+ "category": "feature|bug|refactor|docs",
44
+ "notes": "contextual info"
45
+ }
46
+ ```
47
+
48
+ ### Key Rules
49
+
50
+ **Subject**: Use imperative form - "Fix auth bug", "Add webhook support", "Consolidate templates", not "Bug: auth", "New feature", etc.
51
+
52
+ **Blocking/Blocked By**: Map dependency graph
53
+ - If item 2 waits for item 1: `"blockedBy": ["1"]`
54
+ - If item 1 blocks items 2 & 3: `"blocking": ["2", "3"]`
55
+
56
+ **Status**: Only three values
57
+ - `pending` - not started
58
+ - `in_progress` - currently working
59
+ - `completed` - fully done
60
+
61
+ **Effort**: Estimate relative scope
62
+ - `small`: 1-2 items in 15 min
63
+ - `medium`: 3-5 items in 30-45 min
64
+ - `large`: 6+ items or 1+ hours
65
+
66
+ ## Complete Item Template
67
+
68
+ Use this when planning complex work:
69
+
70
+ ```json
71
+ {
72
+ "id": "task-name-1",
73
+ "subject": "Consolidate duplicate template builders",
74
+ "status": "pending",
75
+ "description": "Extract shared generatePackageJson() and buildHooksMap() logic from cli-adapter.js and extension-adapter.js into TemplateBuilder methods. Current duplication causes maintenance burden.",
76
+ "category": "refactor",
77
+ "effort": "medium",
78
+ "blocking": ["task-name-2"],
79
+ "blockedBy": [],
80
+ "acceptance": [
81
+ "Single generatePackageJson() method in TemplateBuilder",
82
+ "Both adapters call TemplateBuilder methods",
83
+ "All 9 platforms generate identical package.json structure",
84
+ "No duplication in adapter code"
85
+ ],
86
+ "edge_cases": [
87
+ "Platforms without package.json (JetBrains IDE)",
88
+ "Custom fields for CLI vs extension platforms"
89
+ ],
90
+ "verification": "All 9 build outputs pass validation, adapters <150 lines each"
91
+ }
92
+ ```
93
+
94
+ ## Comprehensive Planning Checklist
95
+
96
+ When creating PRD, cover:
97
+
98
+ ### Requirements
99
+ - [ ] Main objective clearly stated
100
+ - [ ] Success criteria defined
101
+ - [ ] User-facing changes vs internal
102
+ - [ ] Backwards compatibility implications
103
+ - [ ] Data migration needed?
104
+
105
+ ### Edge Cases
106
+ - [ ] Empty inputs/missing files
107
+ - [ ] Large scale (1000s of items?)
108
+ - [ ] Concurrent access patterns
109
+ - [ ] Timeout/hang scenarios
110
+ - [ ] Recovery from failures
111
+
112
+ ### Dependencies
113
+ - [ ] External services/APIs required?
114
+ - [ ] Third-party library versions
115
+ - [ ] Environment setup (DB, redis, etc)
116
+ - [ ] Breaking changes from upgrades?
117
+
118
+ ### Acceptance Criteria
119
+ - [ ] Code changed meets goal
120
+ - [ ] Tests pass (if applicable)
121
+ - [ ] Performance requirements met
122
+ - [ ] Security concerns addressed
123
+ - [ ] Documentation updated
124
+
125
+ ### Integration Points
126
+ - [ ] Does it touch other systems?
127
+ - [ ] API compatibility impacts?
128
+ - [ ] Database schema changes?
129
+ - [ ] Message queue formats?
130
+ - [ ] Configuration propagation?
131
+
132
+ ### Error Handling
133
+ - [ ] What fails gracefully?
134
+ - [ ] What fails hard?
135
+ - [ ] Recovery mechanisms?
136
+ - [ ] Fallback options?
137
+ - [ ] User notification strategy?
138
+
139
+ ## PRD Lifecycle
140
+
141
+ ### Creation Phase
142
+ 1. Enumerate **every possible unknown** as work item
143
+ 2. Map dependencies (blocking/blockedBy)
144
+ 3. Group parallelizable items into waves
145
+ 4. Verify all edge cases captured
146
+ 5. Write `./.prd` to disk
147
+ 6. **FREEZE** - no modifications except item removal
148
+
149
+ ### Execution Phase
150
+ 1. Read `.prd`
151
+ 2. Find all `pending` items with no `blockedBy`
152
+ 3. Launch ≤3 parallel workers (gm:gm subagents) per wave
153
+ 4. As items complete, update status to `completed`
154
+ 5. Remove completed items from `.prd` file
155
+ 6. Launch next wave when previous completes
156
+ 7. Continue until `.prd` is empty
157
+
158
+ ### Completion Phase
159
+ - `.prd` file is empty (all items removed)
160
+ - All work committed and pushed
161
+ - Tests passing
162
+ - No remaining `pending` or `in_progress` items
163
+
164
+ ## File Location
165
+
166
+ **CRITICAL**: PRD must be at exactly `./.prd` (current working directory root).
167
+
168
+ - ✅ `/home/user/plugforge/.prd`
169
+ - ❌ `/home/user/plugforge/.prd-temp`
170
+ - ❌ `/home/user/plugforge/build/.prd`
171
+ - ❌ `/home/user/plugforge/.prd.json`
172
+
173
+ No variants, no subdirectories, no extensions. Absolute path must resolve to `cwd + .prd`.
174
+
175
+ ## JSON Format
176
+
177
+ PRD files are **valid JSON** for easy parsing and manipulation.
178
+
179
+ ```json
180
+ {
181
+ "project": "plugforge",
182
+ "created": "2026-02-24",
183
+ "objective": "Unify agent tooling and planning infrastructure",
184
+ "items": [
185
+ {
186
+ "id": "1",
187
+ "subject": "Update agent-browser skill documentation",
188
+ "status": "pending",
189
+ "description": "Add complete command reference with all 100+ commands",
190
+ "blocking": ["2"],
191
+ "blockedBy": [],
192
+ "effort": "small",
193
+ "category": "docs"
194
+ },
195
+ {
196
+ "id": "2",
197
+ "subject": "Create planning skill for PRD construction",
198
+ "status": "pending",
199
+ "description": "New skill that creates .prd files with dependency graphs",
200
+ "blocking": ["3"],
201
+ "blockedBy": ["1"],
202
+ "effort": "medium",
203
+ "category": "feature"
204
+ },
205
+ {
206
+ "id": "3",
207
+ "subject": "Update gm.md agent instructions",
208
+ "status": "pending",
209
+ "description": "Reference new skills, emphasize codesearch over cli tools",
210
+ "blocking": [],
211
+ "blockedBy": ["2"],
212
+ "effort": "medium",
213
+ "category": "docs"
214
+ }
215
+ ],
216
+ "completed": []
217
+ }
218
+ ```
219
+
220
+ ## Execution Guidelines
221
+
222
+ **Wave Orchestration**: Maximum 3 subagents per wave (gm:gm agents via Task tool).
223
+
224
+ ```
225
+ Wave 1: Items 1, 2, 3 (all pending, no dependencies)
226
+ └─ 3 subagents launched in parallel
227
+
228
+ Wave 2: Items 4, 5 (depend on Wave 1 completion)
229
+ └─ Items 6, 7 (wait for Wave 2)
230
+
231
+ Wave 3: Items 6, 7
232
+ └─ 2 subagents (since only 2 items)
233
+
234
+ Wave 4: Item 8 (depends on Wave 3)
235
+ └─ Completes work
236
+ ```
237
+
238
+ After each wave completes:
239
+ 1. Remove finished items from `.prd`
240
+ 2. Write `.prd` (now shorter)
241
+ 3. Check for newly unblocked items
242
+ 4. Launch next wave
243
+
244
+ ## Example: Multi-Platform Builder Updates
245
+
246
+ ```json
247
+ {
248
+ "project": "plugforge",
249
+ "objective": "Add hooks support to 5 CLI platforms",
250
+ "items": [
251
+ {
252
+ "id": "hooks-cc",
253
+ "subject": "Add hooks to gm-cc platform",
254
+ "status": "pending",
255
+ "blocking": ["test-hooks"],
256
+ "blockedBy": [],
257
+ "effort": "small"
258
+ },
259
+ {
260
+ "id": "hooks-gc",
261
+ "subject": "Add hooks to gm-gc platform",
262
+ "status": "pending",
263
+ "blocking": ["test-hooks"],
264
+ "blockedBy": [],
265
+ "effort": "small"
266
+ },
267
+ {
268
+ "id": "hooks-oc",
269
+ "subject": "Add hooks to gm-oc platform",
270
+ "status": "pending",
271
+ "blocking": ["test-hooks"],
272
+ "blockedBy": [],
273
+ "effort": "small"
274
+ },
275
+ {
276
+ "id": "test-hooks",
277
+ "subject": "Test all 5 platforms with hooks",
278
+ "status": "pending",
279
+ "blocking": [],
280
+ "blockedBy": ["hooks-cc", "hooks-gc", "hooks-oc"],
281
+ "effort": "large"
282
+ }
283
+ ]
284
+ }
285
+ ```
286
+
287
+ **Execution**:
288
+ - Wave 1: Launch 3 subagents for `hooks-cc`, `hooks-gc`, `hooks-oc` in parallel
289
+ - After all 3 complete, launch `test-hooks`
290
+
291
+ This cuts wall-clock time from 45 min (sequential) to ~15 min (parallel).
292
+
293
+ ## Best Practices
294
+
295
+ ### Cover All Scenarios
296
+ Don't under-estimate work. If you think it's 3 items, list 8. Missing items cause restarts.
297
+
298
+ ### Name Dependencies Clearly
299
+ - `blocking`: What does THIS item prevent?
300
+ - `blockedBy`: What must complete before THIS?
301
+ - Bidirectional: If A blocks B, then B blockedBy A
302
+
303
+ ### Use Consistent Categories
304
+ - `feature`: New capability
305
+ - `bug`: Fix broken behavior
306
+ - `refactor`: Improve structure without changing behavior
307
+ - `docs`: Documentation
308
+ - `infra`: Build, CI, deployment
309
+
310
+ ### Track Edge Cases Separately
311
+ Even if an item seems small, if it has edge cases, call them out. They often take 50% of the time.
312
+
313
+ ### Estimate Effort Realistically
314
+ - `small`: Coding + testing in 1 attempt
315
+ - `medium`: May need 2 rounds of refinement
316
+ - `large`: Multiple rounds, unexpected issues likely
317
+
318
+ ## Stop Hook Enforcement
319
+
320
+ When session ends, a **stop hook** checks if `.prd` exists and has `pending` or `in_progress` items. If yes, session is blocked. You cannot leave work incomplete.
321
+
322
+ This forces disciplined work closure: every PRD must reach empty state or explicitly pause with documented reason.
323
+
324
+ ## Integration with gm Agent
325
+
326
+ The gm agent (immutable state machine) reads `.prd` in PLAN phase:
327
+ 1. Verifies `.prd` exists and has valid JSON
328
+ 2. Extracts items with `status: pending`
329
+ 3. Finds items with no `blockedBy` constraints
330
+ 4. Launches ≤3 gm:gm subagents per wave
331
+ 5. Each subagent completes one item
332
+ 6. On completion, PRD is updated (item removed)
333
+ 7. Process repeats until `.prd` is empty
334
+
335
+ This creates structured, auditable work flow for complex projects.