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.
- package/.editorconfig +12 -0
- package/.gitignore +13 -0
- package/CONTRIBUTING.md +26 -0
- package/cli.js +0 -8
- package/package.json +9 -2
- package/plugin.json +1 -1
- package/scripts/postinstall.js +138 -0
- package/skills/agent-browser/SKILL.md +512 -0
- package/skills/code-search/SKILL.md +32 -0
- package/skills/dev/SKILL.md +48 -0
- package/skills/gm/SKILL.md +377 -0
- package/skills/planning/SKILL.md +335 -0
|
@@ -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.
|