pi-gsd 1.0.3
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/LICENSE +21 -0
- package/README.md +374 -0
- package/dist/gsd-tools.js +380 -0
- package/package.json +72 -0
- package/scripts/postinstall.js +272 -0
- package/skills/gsd-add-backlog/SKILL.md +78 -0
- package/skills/gsd-add-phase/SKILL.md +39 -0
- package/skills/gsd-add-tests/SKILL.md +28 -0
- package/skills/gsd-add-todo/SKILL.md +42 -0
- package/skills/gsd-audit-milestone/SKILL.md +29 -0
- package/skills/gsd-audit-uat/SKILL.md +20 -0
- package/skills/gsd-autonomous/SKILL.md +34 -0
- package/skills/gsd-check-todos/SKILL.md +40 -0
- package/skills/gsd-cleanup/SKILL.md +19 -0
- package/skills/gsd-complete-milestone/SKILL.md +122 -0
- package/skills/gsd-debug/SKILL.md +178 -0
- package/skills/gsd-discuss-phase/SKILL.md +55 -0
- package/skills/gsd-do/SKILL.md +26 -0
- package/skills/gsd-execute-phase/SKILL.md +53 -0
- package/skills/gsd-fast/SKILL.md +22 -0
- package/skills/gsd-forensics/SKILL.md +51 -0
- package/skills/gsd-health/SKILL.md +17 -0
- package/skills/gsd-help/SKILL.md +24 -0
- package/skills/gsd-insert-phase/SKILL.md +28 -0
- package/skills/gsd-join-discord/SKILL.md +19 -0
- package/skills/gsd-list-phase-assumptions/SKILL.md +41 -0
- package/skills/gsd-list-workspaces/SKILL.md +17 -0
- package/skills/gsd-manager/SKILL.md +33 -0
- package/skills/gsd-map-codebase/SKILL.md +64 -0
- package/skills/gsd-milestone-summary/SKILL.md +45 -0
- package/skills/gsd-new-milestone/SKILL.md +39 -0
- package/skills/gsd-new-project/SKILL.md +37 -0
- package/skills/gsd-new-workspace/SKILL.md +41 -0
- package/skills/gsd-next/SKILL.md +19 -0
- package/skills/gsd-note/SKILL.md +30 -0
- package/skills/gsd-pause-work/SKILL.md +35 -0
- package/skills/gsd-plan-milestone-gaps/SKILL.md +28 -0
- package/skills/gsd-plan-phase/SKILL.md +38 -0
- package/skills/gsd-plant-seed/SKILL.md +21 -0
- package/skills/gsd-pr-branch/SKILL.md +20 -0
- package/skills/gsd-profile-user/SKILL.md +38 -0
- package/skills/gsd-progress/SKILL.md +19 -0
- package/skills/gsd-quick/SKILL.md +38 -0
- package/skills/gsd-reapply-patches/SKILL.md +126 -0
- package/skills/gsd-remove-phase/SKILL.md +26 -0
- package/skills/gsd-remove-workspace/SKILL.md +22 -0
- package/skills/gsd-research-phase/SKILL.md +200 -0
- package/skills/gsd-resume-work/SKILL.md +35 -0
- package/skills/gsd-review/SKILL.md +31 -0
- package/skills/gsd-review-backlog/SKILL.md +62 -0
- package/skills/gsd-session-report/SKILL.md +16 -0
- package/skills/gsd-set-profile/SKILL.md +9 -0
- package/skills/gsd-settings/SKILL.md +32 -0
- package/skills/gsd-ship/SKILL.md +16 -0
- package/skills/gsd-stats/SKILL.md +16 -0
- package/skills/gsd-thread/SKILL.md +133 -0
- package/skills/gsd-ui-phase/SKILL.md +24 -0
- package/skills/gsd-ui-review/SKILL.md +24 -0
- package/skills/gsd-update/SKILL.md +35 -0
- package/skills/gsd-validate-phase/SKILL.md +26 -0
- package/skills/gsd-verify-work/SKILL.md +30 -0
- package/skills/gsd-workstreams/SKILL.md +72 -0
|
@@ -0,0 +1,126 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: gsd-reapply-patches
|
|
3
|
+
description: Reapply local modifications after a GSD update
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
<purpose>
|
|
7
|
+
After a GSD update wipes and reinstalls files, this command merges user's previously saved local modifications back into the new version. Uses intelligent comparison to handle cases where the upstream file also changed.
|
|
8
|
+
</purpose>
|
|
9
|
+
|
|
10
|
+
<process>
|
|
11
|
+
|
|
12
|
+
## Step 1: Detect backed-up patches
|
|
13
|
+
|
|
14
|
+
Check for local patches directory:
|
|
15
|
+
|
|
16
|
+
```bash
|
|
17
|
+
# Global install - detect runtime config directory
|
|
18
|
+
if [ -d "$HOME/.config/opencode/gsd-local-patches" ]; then
|
|
19
|
+
PATCHES_DIR="$HOME/.config/opencode/gsd-local-patches"
|
|
20
|
+
elif [ -d "$HOME/.opencode/gsd-local-patches" ]; then
|
|
21
|
+
PATCHES_DIR="$HOME/.opencode/gsd-local-patches"
|
|
22
|
+
elif [ -d "$HOME/.gemini/gsd-local-patches" ]; then
|
|
23
|
+
PATCHES_DIR="$HOME/.gemini/gsd-local-patches"
|
|
24
|
+
else
|
|
25
|
+
PATCHES_DIR=".agent/gsd-local-patches"
|
|
26
|
+
fi
|
|
27
|
+
# Local install fallback - check all runtime directories
|
|
28
|
+
if [ ! -d "$PATCHES_DIR" ]; then
|
|
29
|
+
for dir in .config/opencode .opencode .gemini .claude; do
|
|
30
|
+
if [ -d "./$dir/gsd-local-patches" ]; then
|
|
31
|
+
PATCHES_DIR="./$dir/gsd-local-patches"
|
|
32
|
+
break
|
|
33
|
+
fi
|
|
34
|
+
done
|
|
35
|
+
fi
|
|
36
|
+
```
|
|
37
|
+
|
|
38
|
+
Read `backup-meta.json` from the patches directory.
|
|
39
|
+
|
|
40
|
+
**If no patches found:**
|
|
41
|
+
|
|
42
|
+
```
|
|
43
|
+
No local patches found. Nothing to reapply.
|
|
44
|
+
|
|
45
|
+
Local patches are automatically saved when you run /gsd-update
|
|
46
|
+
after modifying any GSD workflow, command, or agent files.
|
|
47
|
+
```
|
|
48
|
+
|
|
49
|
+
Exit.
|
|
50
|
+
|
|
51
|
+
## Step 2: Show patch summary
|
|
52
|
+
|
|
53
|
+
```
|
|
54
|
+
## Local Patches to Reapply
|
|
55
|
+
|
|
56
|
+
**Backed up from:** v{from_version}
|
|
57
|
+
**Current version:** {read VERSION file}
|
|
58
|
+
**Files modified:** {count}
|
|
59
|
+
|
|
60
|
+
| # | File | Status |
|
|
61
|
+
|---|------|--------|
|
|
62
|
+
| 1 | {file_path} | Pending |
|
|
63
|
+
| 2 | {file_path} | Pending |
|
|
64
|
+
```
|
|
65
|
+
|
|
66
|
+
## Step 3: Merge each file
|
|
67
|
+
|
|
68
|
+
For each file in `backup-meta.json`:
|
|
69
|
+
|
|
70
|
+
1. **Read the backed-up version** (user's modified copy from `gsd-local-patches/`)
|
|
71
|
+
2. **Read the newly installed version** (current file after update)
|
|
72
|
+
3. **Compare and merge:**
|
|
73
|
+
- If the new file is identical to the backed-up file: skip (modification was incorporated upstream)
|
|
74
|
+
- If the new file differs: identify the user's modifications and apply them to the new version
|
|
75
|
+
|
|
76
|
+
**Merge strategy:**
|
|
77
|
+
- Read both versions fully
|
|
78
|
+
- Identify sections the user added or modified (look for additions, not just differences from path replacement)
|
|
79
|
+
- Apply user's additions/modifications to the new version
|
|
80
|
+
- If a section the user modified was also changed upstream: flag as conflict, show both versions, ask user which to keep
|
|
81
|
+
|
|
82
|
+
4. **Write merged result** to the installed location
|
|
83
|
+
5. **Report status:**
|
|
84
|
+
- `Merged` - user modifications applied cleanly
|
|
85
|
+
- `Skipped` - modification already in upstream
|
|
86
|
+
- `Conflict` - user chose resolution
|
|
87
|
+
|
|
88
|
+
## Step 4: Update manifest
|
|
89
|
+
|
|
90
|
+
After reapplying, regenerate the file manifest so future updates correctly detect these as user modifications:
|
|
91
|
+
|
|
92
|
+
```bash
|
|
93
|
+
# The manifest will be regenerated on next /gsd-update
|
|
94
|
+
# For now, just note which files were modified
|
|
95
|
+
```
|
|
96
|
+
|
|
97
|
+
## Step 5: Cleanup option
|
|
98
|
+
|
|
99
|
+
Ask user:
|
|
100
|
+
|
|
101
|
+
- "Keep patch backups for reference?" → preserve `gsd-local-patches/`
|
|
102
|
+
- "Clean up patch backups?" → remove `gsd-local-patches/` directory
|
|
103
|
+
|
|
104
|
+
## Step 6: Report
|
|
105
|
+
|
|
106
|
+
```
|
|
107
|
+
## Patches Reapplied
|
|
108
|
+
|
|
109
|
+
| # | File | Status |
|
|
110
|
+
|---|------|--------|
|
|
111
|
+
| 1 | {file_path} | ✓ Merged |
|
|
112
|
+
| 2 | {file_path} | â—‹ Skipped (already upstream) |
|
|
113
|
+
| 3 | {file_path} | âš Conflict resolved |
|
|
114
|
+
|
|
115
|
+
{count} file(s) updated. Your local modifications are active again.
|
|
116
|
+
```
|
|
117
|
+
|
|
118
|
+
</process>
|
|
119
|
+
|
|
120
|
+
<success_criteria>
|
|
121
|
+
|
|
122
|
+
- [ ] All backed-up patches processed
|
|
123
|
+
- [ ] User modifications merged into new version
|
|
124
|
+
- [ ] Conflicts resolved with user input
|
|
125
|
+
- [ ] Status reported for each file
|
|
126
|
+
</success_criteria>
|
|
@@ -0,0 +1,26 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: gsd-remove-phase
|
|
3
|
+
description: Remove a future phase from roadmap and renumber subsequent phases
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
<objective>
|
|
7
|
+
Remove an unstarted future phase from the roadmap and renumber all subsequent phases to maintain a clean, linear sequence.
|
|
8
|
+
|
|
9
|
+
Purpose: Clean removal of work you've decided not to do, without polluting context with cancelled/deferred markers.
|
|
10
|
+
Output: Phase deleted, all subsequent phases renumbered, git commit as historical record.
|
|
11
|
+
</objective>
|
|
12
|
+
|
|
13
|
+
<execution_context>
|
|
14
|
+
@.agent/get-shit-done/workflows/remove-phase.md
|
|
15
|
+
</execution_context>
|
|
16
|
+
|
|
17
|
+
<context>
|
|
18
|
+
Phase: $ARGUMENTS
|
|
19
|
+
|
|
20
|
+
Roadmap and state are resolved in-workflow via `init phase-op` and targeted reads.
|
|
21
|
+
</context>
|
|
22
|
+
|
|
23
|
+
<process>
|
|
24
|
+
Execute the remove-phase workflow from @.agent/get-shit-done/workflows/remove-phase.md end-to-end.
|
|
25
|
+
Preserve all validation gates (future phase check, work check), renumbering logic, and commit.
|
|
26
|
+
</process>
|
|
@@ -0,0 +1,22 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: gsd-remove-workspace
|
|
3
|
+
description: Remove a GSD workspace and clean up worktrees
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
<context>
|
|
7
|
+
**Arguments:**
|
|
8
|
+
- `<workspace-name>` (required) - Name of the workspace to remove
|
|
9
|
+
</context>
|
|
10
|
+
|
|
11
|
+
<objective>
|
|
12
|
+
Remove a workspace directory after confirmation. For worktree strategy, runs `git worktree remove` for each member repo first. Refuses if any repo has uncommitted changes.
|
|
13
|
+
</objective>
|
|
14
|
+
|
|
15
|
+
<execution_context>
|
|
16
|
+
@.agent/get-shit-done/workflows/remove-workspace.md
|
|
17
|
+
@.agent/get-shit-done/references/ui-brand.md
|
|
18
|
+
</execution_context>
|
|
19
|
+
|
|
20
|
+
<process>
|
|
21
|
+
Execute the remove-workspace workflow from @.agent/get-shit-done/workflows/remove-workspace.md end-to-end.
|
|
22
|
+
</process>
|
|
@@ -0,0 +1,200 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: gsd-research-phase
|
|
3
|
+
description: Research how to implement a phase (standalone - usually use /gsd-plan-phase instead)
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
<objective>
|
|
7
|
+
Research how to implement a phase. Spawns gsd-phase-researcher agent with phase context.
|
|
8
|
+
|
|
9
|
+
**Note:** This is a standalone research command. For most workflows, use `/gsd-plan-phase` which integrates research automatically.
|
|
10
|
+
|
|
11
|
+
**Use this command when:**
|
|
12
|
+
|
|
13
|
+
- You want to research without planning yet
|
|
14
|
+
- You want to re-research after planning is complete
|
|
15
|
+
- You need to investigate before deciding if a phase is feasible
|
|
16
|
+
|
|
17
|
+
**Orchestrator role:** Parse phase, validate against roadmap, check existing research, gather context, spawn researcher agent, present results.
|
|
18
|
+
|
|
19
|
+
**Why subagent:** Research burns context fast (WebSearch, Context7 queries, source verification). Fresh 200k context for investigation. Main context stays lean for user interaction.
|
|
20
|
+
</objective>
|
|
21
|
+
|
|
22
|
+
<available_agent_types>
|
|
23
|
+
Valid GSD subagent types (use exact names - do not fall back to 'general-purpose'):
|
|
24
|
+
|
|
25
|
+
- gsd-phase-researcher - Researches technical approaches for a phase
|
|
26
|
+
</available_agent_types>
|
|
27
|
+
|
|
28
|
+
<context>
|
|
29
|
+
Phase number: $ARGUMENTS (required)
|
|
30
|
+
|
|
31
|
+
Normalize phase input in step 1 before any directory lookups.
|
|
32
|
+
</context>
|
|
33
|
+
|
|
34
|
+
<process>
|
|
35
|
+
|
|
36
|
+
## 0. Initialize Context
|
|
37
|
+
|
|
38
|
+
```bash
|
|
39
|
+
INIT=$(node ".agent/get-shit-done/bin/gsd-tools.cjs" init phase-op "$ARGUMENTS")
|
|
40
|
+
if [[ "$INIT" == @file:* ]]; then INIT=$(cat "${INIT#@file:}"); fi
|
|
41
|
+
```
|
|
42
|
+
|
|
43
|
+
Extract from init JSON: `phase_dir`, `phase_number`, `phase_name`, `phase_found`, `commit_docs`, `has_research`, `state_path`, `requirements_path`, `context_path`, `research_path`.
|
|
44
|
+
|
|
45
|
+
Resolve researcher model:
|
|
46
|
+
|
|
47
|
+
```bash
|
|
48
|
+
RESEARCHER_MODEL=$(node ".agent/get-shit-done/bin/gsd-tools.cjs" resolve-model gsd-phase-researcher --raw)
|
|
49
|
+
```
|
|
50
|
+
|
|
51
|
+
## 1. Validate Phase
|
|
52
|
+
|
|
53
|
+
```bash
|
|
54
|
+
PHASE_INFO=$(node ".agent/get-shit-done/bin/gsd-tools.cjs" roadmap get-phase "${phase_number}")
|
|
55
|
+
```
|
|
56
|
+
|
|
57
|
+
**If `found` is false:** Error and exit. **If `found` is true:** Extract `phase_number`, `phase_name`, `goal` from JSON.
|
|
58
|
+
|
|
59
|
+
## 2. Check Existing Research
|
|
60
|
+
|
|
61
|
+
```bash
|
|
62
|
+
ls .planning/phases/${PHASE}-*/RESEARCH.md 2>/dev/null
|
|
63
|
+
```
|
|
64
|
+
|
|
65
|
+
**If exists:** Offer: 1) Update research, 2) View existing, 3) Skip. Wait for response.
|
|
66
|
+
|
|
67
|
+
**If doesn't exist:** Continue.
|
|
68
|
+
|
|
69
|
+
## 3. Gather Phase Context
|
|
70
|
+
|
|
71
|
+
Use paths from INIT (do not inline file contents in orchestrator context):
|
|
72
|
+
|
|
73
|
+
- `requirements_path`
|
|
74
|
+
- `context_path`
|
|
75
|
+
- `state_path`
|
|
76
|
+
|
|
77
|
+
Present summary with phase description and what files the researcher will load.
|
|
78
|
+
|
|
79
|
+
## 4. Spawn gsd-phase-researcher Agent
|
|
80
|
+
|
|
81
|
+
Research modes: ecosystem (default), feasibility, implementation, comparison.
|
|
82
|
+
|
|
83
|
+
```markdown
|
|
84
|
+
<research_type>
|
|
85
|
+
Phase Research - investigating HOW to implement a specific phase well.
|
|
86
|
+
</research_type>
|
|
87
|
+
|
|
88
|
+
<key_insight>
|
|
89
|
+
The question is NOT "which library should I use?"
|
|
90
|
+
|
|
91
|
+
The question is: "What do I not know that I don't know?"
|
|
92
|
+
|
|
93
|
+
For this phase, discover:
|
|
94
|
+
|
|
95
|
+
- What's the established architecture pattern?
|
|
96
|
+
- What libraries form the standard stack?
|
|
97
|
+
- What problems do people commonly hit?
|
|
98
|
+
- What's SOTA vs what the agent's training thinks is SOTA?
|
|
99
|
+
- What should NOT be hand-rolled?
|
|
100
|
+
</key_insight>
|
|
101
|
+
|
|
102
|
+
<objective>
|
|
103
|
+
Research implementation approach for Phase {phase_number}: {phase_name}
|
|
104
|
+
Mode: ecosystem
|
|
105
|
+
</objective>
|
|
106
|
+
|
|
107
|
+
<files_to_read>
|
|
108
|
+
|
|
109
|
+
- {requirements_path} (Requirements)
|
|
110
|
+
- {context_path} (Phase context from discuss-phase, if exists)
|
|
111
|
+
- {state_path} (Prior project decisions and blockers)
|
|
112
|
+
</files_to_read>
|
|
113
|
+
|
|
114
|
+
<additional_context>
|
|
115
|
+
**Phase description:** {phase_description}
|
|
116
|
+
</additional_context>
|
|
117
|
+
|
|
118
|
+
<downstream_consumer>
|
|
119
|
+
Your RESEARCH.md will be loaded by `/gsd-plan-phase` which uses specific sections:
|
|
120
|
+
|
|
121
|
+
- `## Standard Stack` → Plans use these libraries
|
|
122
|
+
- `## Architecture Patterns` → Task structure follows these
|
|
123
|
+
- `## Don't Hand-Roll` → Tasks NEVER build custom solutions for listed problems
|
|
124
|
+
- `## Common Pitfalls` → Verification steps check for these
|
|
125
|
+
- `## Code Examples` → Task actions reference these patterns
|
|
126
|
+
|
|
127
|
+
Be prescriptive, not exploratory. "Use X" not "Consider X or Y."
|
|
128
|
+
</downstream_consumer>
|
|
129
|
+
|
|
130
|
+
<quality_gate>
|
|
131
|
+
Before declaring complete, verify:
|
|
132
|
+
|
|
133
|
+
- [ ] All domains investigated (not just some)
|
|
134
|
+
- [ ] Negative claims verified with official docs
|
|
135
|
+
- [ ] Multiple sources for critical claims
|
|
136
|
+
- [ ] Confidence levels assigned honestly
|
|
137
|
+
- [ ] Section names match what plan-phase expects
|
|
138
|
+
</quality_gate>
|
|
139
|
+
|
|
140
|
+
<output>
|
|
141
|
+
Write to: .planning/phases/${PHASE}-{slug}/${PHASE}-RESEARCH.md
|
|
142
|
+
</output>
|
|
143
|
+
```
|
|
144
|
+
|
|
145
|
+
```
|
|
146
|
+
Task(
|
|
147
|
+
prompt=filled_prompt,
|
|
148
|
+
subagent_type="gsd-phase-researcher",
|
|
149
|
+
model="{researcher_model}",
|
|
150
|
+
description="Research Phase {phase}"
|
|
151
|
+
)
|
|
152
|
+
```
|
|
153
|
+
|
|
154
|
+
## 5. Handle Agent Return
|
|
155
|
+
|
|
156
|
+
**`## RESEARCH COMPLETE`:** Display summary, offer: Plan phase, Dig deeper, Review full, Done.
|
|
157
|
+
|
|
158
|
+
**`## CHECKPOINT REACHED`:** Present to user, get response, spawn continuation.
|
|
159
|
+
|
|
160
|
+
**`## RESEARCH INCONCLUSIVE`:** Show what was attempted, offer: Add context, Try different mode, Manual.
|
|
161
|
+
|
|
162
|
+
## 6. Spawn Continuation Agent
|
|
163
|
+
|
|
164
|
+
```markdown
|
|
165
|
+
<objective>
|
|
166
|
+
Continue research for Phase {phase_number}: {phase_name}
|
|
167
|
+
</objective>
|
|
168
|
+
|
|
169
|
+
<prior_state>
|
|
170
|
+
<files_to_read>
|
|
171
|
+
|
|
172
|
+
- .planning/phases/${PHASE}-{slug}/${PHASE}-RESEARCH.md (Existing research)
|
|
173
|
+
</files_to_read>
|
|
174
|
+
</prior_state>
|
|
175
|
+
|
|
176
|
+
<checkpoint_response>
|
|
177
|
+
**Type:** {checkpoint_type}
|
|
178
|
+
**Response:** {user_response}
|
|
179
|
+
</checkpoint_response>
|
|
180
|
+
```
|
|
181
|
+
|
|
182
|
+
```
|
|
183
|
+
Task(
|
|
184
|
+
prompt=continuation_prompt,
|
|
185
|
+
subagent_type="gsd-phase-researcher",
|
|
186
|
+
model="{researcher_model}",
|
|
187
|
+
description="Continue research Phase {phase}"
|
|
188
|
+
)
|
|
189
|
+
```
|
|
190
|
+
|
|
191
|
+
</process>
|
|
192
|
+
|
|
193
|
+
<success_criteria>
|
|
194
|
+
|
|
195
|
+
- [ ] Phase validated against roadmap
|
|
196
|
+
- [ ] Existing research checked
|
|
197
|
+
- [ ] gsd-phase-researcher spawned with context
|
|
198
|
+
- [ ] Checkpoints handled correctly
|
|
199
|
+
- [ ] User knows next steps
|
|
200
|
+
</success_criteria>
|
|
@@ -0,0 +1,35 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: gsd-resume-work
|
|
3
|
+
description: Resume work from previous session with full context restoration
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
|
|
7
|
+
<objective>
|
|
8
|
+
Restore complete project context and resume work seamlessly from previous session.
|
|
9
|
+
|
|
10
|
+
Routes to the resume-project workflow which handles:
|
|
11
|
+
|
|
12
|
+
- STATE.md loading (or reconstruction if missing)
|
|
13
|
+
- Checkpoint detection (.continue-here files)
|
|
14
|
+
- Incomplete work detection (PLAN without SUMMARY)
|
|
15
|
+
- Status presentation
|
|
16
|
+
- Context-aware next action routing
|
|
17
|
+
</objective>
|
|
18
|
+
|
|
19
|
+
<execution_context>
|
|
20
|
+
@.agent/get-shit-done/workflows/resume-project.md
|
|
21
|
+
</execution_context>
|
|
22
|
+
|
|
23
|
+
<process>
|
|
24
|
+
**Follow the resume-project workflow** from `@.agent/get-shit-done/workflows/resume-project.md`.
|
|
25
|
+
|
|
26
|
+
The workflow handles all resumption logic including:
|
|
27
|
+
|
|
28
|
+
1. Project existence verification
|
|
29
|
+
2. STATE.md loading or reconstruction
|
|
30
|
+
3. Checkpoint and incomplete work detection
|
|
31
|
+
4. Visual status presentation
|
|
32
|
+
5. Context-aware option offering (checks CONTEXT.md before suggesting plan vs discuss)
|
|
33
|
+
6. Routing to appropriate next command
|
|
34
|
+
7. Session continuity updates
|
|
35
|
+
</process>
|
|
@@ -0,0 +1,31 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: gsd-review
|
|
3
|
+
description: Request cross-AI peer review of phase plans from external AI CLIs
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
<objective>
|
|
7
|
+
Invoke external AI CLIs (Gemini, the agent, Codex) to independently review phase plans.
|
|
8
|
+
Produces a structured REVIEWS.md with per-reviewer feedback that can be fed back into
|
|
9
|
+
planning via /gsd-plan-phase --reviews.
|
|
10
|
+
|
|
11
|
+
**Flow:** Detect CLIs → Build review prompt → Invoke each CLI → Collect responses → Write REVIEWS.md
|
|
12
|
+
</objective>
|
|
13
|
+
|
|
14
|
+
<execution_context>
|
|
15
|
+
@.agent/get-shit-done/workflows/review.md
|
|
16
|
+
</execution_context>
|
|
17
|
+
|
|
18
|
+
<context>
|
|
19
|
+
Phase number: extracted from $ARGUMENTS (required)
|
|
20
|
+
|
|
21
|
+
**Flags:**
|
|
22
|
+
|
|
23
|
+
- `--gemini` - Include Gemini CLI review
|
|
24
|
+
- `--claude` - Include the agent CLI review (uses separate session)
|
|
25
|
+
- `--codex` - Include Codex CLI review
|
|
26
|
+
- `--all` - Include all available CLIs
|
|
27
|
+
</context>
|
|
28
|
+
|
|
29
|
+
<process>
|
|
30
|
+
Execute the review workflow from @.agent/get-shit-done/workflows/review.md end-to-end.
|
|
31
|
+
</process>
|
|
@@ -0,0 +1,62 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: gsd-review-backlog
|
|
3
|
+
description: Review and promote backlog items to active milestone
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
<objective>
|
|
7
|
+
Review all 999.x backlog items and optionally promote them into the active
|
|
8
|
+
milestone sequence or remove stale entries.
|
|
9
|
+
</objective>
|
|
10
|
+
|
|
11
|
+
<process>
|
|
12
|
+
|
|
13
|
+
1. **List backlog items:**
|
|
14
|
+
|
|
15
|
+
```bash
|
|
16
|
+
ls -d .planning/phases/999* 2>/dev/null || echo "No backlog items found"
|
|
17
|
+
```
|
|
18
|
+
|
|
19
|
+
2. **Read ROADMAP.md** and extract all 999.x phase entries:
|
|
20
|
+
|
|
21
|
+
```bash
|
|
22
|
+
cat .planning/ROADMAP.md
|
|
23
|
+
```
|
|
24
|
+
|
|
25
|
+
Show each backlog item with its description, any accumulated context (CONTEXT.md, RESEARCH.md), and creation date.
|
|
26
|
+
|
|
27
|
+
3. **Present the list to the user** via AskUserQuestion:
|
|
28
|
+
- For each backlog item, show: phase number, description, accumulated artifacts
|
|
29
|
+
- Options per item: **Promote** (move to active), **Keep** (leave in backlog), **Remove** (delete)
|
|
30
|
+
|
|
31
|
+
4. **For items to PROMOTE:**
|
|
32
|
+
- Find the next sequential phase number in the active milestone
|
|
33
|
+
- Rename the directory from `999.x-slug` to `{new_num}-slug`:
|
|
34
|
+
```bash
|
|
35
|
+
NEW_NUM=$(node ".agent/get-shit-done/bin/gsd-tools.cjs" phase add "${DESCRIPTION}" --raw)
|
|
36
|
+
```
|
|
37
|
+
- Move accumulated artifacts to the new phase directory
|
|
38
|
+
- Update ROADMAP.md: move the entry from `## Backlog` section to the active phase list
|
|
39
|
+
- Remove `(BACKLOG)` marker
|
|
40
|
+
- Add appropriate `**Depends on:**` field
|
|
41
|
+
|
|
42
|
+
5. **For items to REMOVE:**
|
|
43
|
+
- Delete the phase directory
|
|
44
|
+
- Remove the entry from ROADMAP.md `## Backlog` section
|
|
45
|
+
|
|
46
|
+
6. **Commit changes:**
|
|
47
|
+
|
|
48
|
+
```bash
|
|
49
|
+
node ".agent/get-shit-done/bin/gsd-tools.cjs" commit "docs: review backlog - promoted N, removed M" --files .planning/ROADMAP.md
|
|
50
|
+
```
|
|
51
|
+
|
|
52
|
+
7. **Report summary:**
|
|
53
|
+
|
|
54
|
+
```
|
|
55
|
+
## 📋 Backlog Review Complete
|
|
56
|
+
|
|
57
|
+
Promoted: {list of promoted items with new phase numbers}
|
|
58
|
+
Kept: {list of items remaining in backlog}
|
|
59
|
+
Removed: {list of deleted items}
|
|
60
|
+
```
|
|
61
|
+
|
|
62
|
+
</process>
|
|
@@ -0,0 +1,16 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: gsd-session-report
|
|
3
|
+
description: Generate a session report with token usage estimates, work summary, and outcomes
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
<objective>
|
|
7
|
+
Generate a structured SESSION_REPORT.md document capturing session outcomes, work performed, and estimated resource usage. Provides a shareable artifact for post-session review.
|
|
8
|
+
</objective>
|
|
9
|
+
|
|
10
|
+
<execution_context>
|
|
11
|
+
@.agent/get-shit-done/workflows/session-report.md
|
|
12
|
+
</execution_context>
|
|
13
|
+
|
|
14
|
+
<process>
|
|
15
|
+
Execute the session-report workflow from @.agent/get-shit-done/workflows/session-report.md end-to-end.
|
|
16
|
+
</process>
|
|
@@ -0,0 +1,9 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: gsd-set-profile
|
|
3
|
+
description: Switch model profile for GSD agents (quality/balanced/budget/inherit)
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
|
|
7
|
+
Show the following output to the user verbatim, with no extra commentary:
|
|
8
|
+
|
|
9
|
+
!`node ".agent/get-shit-done/bin/gsd-tools.cjs" config-set-model-profile $ARGUMENTS --raw`
|
|
@@ -0,0 +1,32 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: gsd-settings
|
|
3
|
+
description: Configure GSD workflow toggles and model profile
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
|
|
7
|
+
<objective>
|
|
8
|
+
Interactive configuration of GSD workflow agents and model profile via multi-question prompt.
|
|
9
|
+
|
|
10
|
+
Routes to the settings workflow which handles:
|
|
11
|
+
- Config existence ensuring
|
|
12
|
+
- Current settings reading and parsing
|
|
13
|
+
- Interactive 5-question prompt (model, research, plan_check, verifier, branching)
|
|
14
|
+
- Config merging and writing
|
|
15
|
+
- Confirmation display with quick command references
|
|
16
|
+
</objective>
|
|
17
|
+
|
|
18
|
+
<execution_context>
|
|
19
|
+
@.agent/get-shit-done/workflows/settings.md
|
|
20
|
+
</execution_context>
|
|
21
|
+
|
|
22
|
+
<process>
|
|
23
|
+
**Follow the settings workflow** from `@.agent/get-shit-done/workflows/settings.md`.
|
|
24
|
+
|
|
25
|
+
The workflow handles all logic including:
|
|
26
|
+
1. Config file creation with defaults if missing
|
|
27
|
+
2. Current config reading
|
|
28
|
+
3. Interactive settings presentation with pre-selection
|
|
29
|
+
4. Answer parsing and config merging
|
|
30
|
+
5. File writing
|
|
31
|
+
6. Confirmation display
|
|
32
|
+
</process>
|
|
@@ -0,0 +1,16 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: gsd-ship
|
|
3
|
+
description: Create PR, run review, and prepare for merge after verification passes
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
<objective>
|
|
7
|
+
Bridge local completion → merged PR. After /gsd-verify-work passes, ship the work: push branch, create PR with auto-generated body, optionally trigger review, and track the merge.
|
|
8
|
+
|
|
9
|
+
Closes the plan → execute → verify → ship loop.
|
|
10
|
+
</objective>
|
|
11
|
+
|
|
12
|
+
<execution_context>
|
|
13
|
+
@.agent/get-shit-done/workflows/ship.md
|
|
14
|
+
</execution_context>
|
|
15
|
+
|
|
16
|
+
Execute the ship workflow from @.agent/get-shit-done/workflows/ship.md end-to-end.
|
|
@@ -0,0 +1,16 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: gsd-stats
|
|
3
|
+
description: Display project statistics - phases, plans, requirements, git metrics, and timeline
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
<objective>
|
|
7
|
+
Display comprehensive project statistics including phase progress, plan execution metrics, requirements completion, git history stats, and project timeline.
|
|
8
|
+
</objective>
|
|
9
|
+
|
|
10
|
+
<execution_context>
|
|
11
|
+
@.agent/get-shit-done/workflows/stats.md
|
|
12
|
+
</execution_context>
|
|
13
|
+
|
|
14
|
+
<process>
|
|
15
|
+
Execute the stats workflow from @.agent/get-shit-done/workflows/stats.md end-to-end.
|
|
16
|
+
</process>
|