gsd-vscode-copilot 1.0.0 → 1.1.0
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 +151 -26
- package/bin/init.js +43 -14
- package/package.json +1 -1
- package/templates/agents/gsd-codebase-mapper.agent.md +55 -0
- package/templates/agents/gsd-planner.agent.md +114 -0
- package/templates/agents/gsd-researcher.agent.md +76 -0
- package/templates/agents/gsd-verifier.agent.md +86 -0
- package/templates/gsd-workflow.instructions.md +160 -31
- package/templates/prompts/gsd-discuss-phase.prompt.md +178 -0
- package/templates/prompts/gsd-execute-phase.prompt.md +253 -0
- package/templates/prompts/gsd-map-codebase.prompt.md +150 -0
- package/templates/prompts/gsd-plan-phase.prompt.md +179 -0
- package/templates/prompts/gsd-progress.prompt.md +49 -11
- package/templates/prompts/gsd-quick.prompt.md +69 -0
- package/templates/prompts/gsd-research-phase.prompt.md +184 -0
- package/templates/prompts/gsd-execute-plan.prompt.md +0 -96
- package/templates/prompts/gsd-plan-slice.prompt.md +0 -105
|
@@ -0,0 +1,150 @@
|
|
|
1
|
+
````prompt
|
|
2
|
+
---
|
|
3
|
+
description: "GSD: Map existing codebase for brownfield projects"
|
|
4
|
+
argument-hint: "Optional: focus area (e.g., 'api', 'auth', 'frontend')"
|
|
5
|
+
agent: gsd-codebase-mapper
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
Analyze the existing codebase and create structured documentation in `.planning/codebase/`.
|
|
9
|
+
|
|
10
|
+
## When to Use
|
|
11
|
+
|
|
12
|
+
- **Before starting work** on an existing codebase you're unfamiliar with
|
|
13
|
+
- **Before `/gsd-bootstrap-planning`** to inform project planning with codebase context
|
|
14
|
+
- **After major changes** to refresh understanding of current state
|
|
15
|
+
- **When onboarding** to understand how things work
|
|
16
|
+
|
|
17
|
+
## Process
|
|
18
|
+
|
|
19
|
+
### Step 1: Check Existing Map
|
|
20
|
+
|
|
21
|
+
```bash
|
|
22
|
+
ls -la .planning/codebase/ 2>/dev/null
|
|
23
|
+
```
|
|
24
|
+
|
|
25
|
+
If `.planning/codebase/` exists with recent files, ask:
|
|
26
|
+
- "Codebase map exists from [date]. Refresh it, or work with existing?"
|
|
27
|
+
|
|
28
|
+
### Step 2: Create Directory Structure
|
|
29
|
+
|
|
30
|
+
```bash
|
|
31
|
+
mkdir -p .planning/codebase
|
|
32
|
+
```
|
|
33
|
+
|
|
34
|
+
### Step 3: Analyze Codebase
|
|
35
|
+
|
|
36
|
+
Use subagents to analyze different aspects of the codebase. For each area, spawn a focused analysis:
|
|
37
|
+
|
|
38
|
+
**Stack Analysis:**
|
|
39
|
+
```
|
|
40
|
+
Use a subagent to analyze the technology stack:
|
|
41
|
+
- Languages and versions
|
|
42
|
+
- Frameworks and libraries
|
|
43
|
+
- Package managers and dependencies
|
|
44
|
+
- Build tools and scripts
|
|
45
|
+
|
|
46
|
+
Write findings to .planning/codebase/STACK.md
|
|
47
|
+
```
|
|
48
|
+
|
|
49
|
+
**Architecture Analysis:**
|
|
50
|
+
```
|
|
51
|
+
Use a subagent to analyze the architecture:
|
|
52
|
+
- Directory structure and organization
|
|
53
|
+
- Design patterns in use
|
|
54
|
+
- Data flow between components
|
|
55
|
+
- Entry points and boundaries
|
|
56
|
+
|
|
57
|
+
Write findings to .planning/codebase/ARCHITECTURE.md
|
|
58
|
+
```
|
|
59
|
+
|
|
60
|
+
**Conventions Analysis:**
|
|
61
|
+
```
|
|
62
|
+
Use a subagent to analyze coding conventions:
|
|
63
|
+
- Naming patterns (files, functions, variables)
|
|
64
|
+
- Code style and formatting
|
|
65
|
+
- Error handling patterns
|
|
66
|
+
- Documentation style
|
|
67
|
+
|
|
68
|
+
Write findings to .planning/codebase/CONVENTIONS.md
|
|
69
|
+
```
|
|
70
|
+
|
|
71
|
+
**Concerns Analysis:**
|
|
72
|
+
```
|
|
73
|
+
Use a subagent to identify concerns:
|
|
74
|
+
- Technical debt
|
|
75
|
+
- Known issues or TODOs
|
|
76
|
+
- Areas needing refactoring
|
|
77
|
+
- Missing tests or documentation
|
|
78
|
+
|
|
79
|
+
Write findings to .planning/codebase/CONCERNS.md
|
|
80
|
+
```
|
|
81
|
+
|
|
82
|
+
### Step 4: Create Summary
|
|
83
|
+
|
|
84
|
+
After all analyses complete, create `.planning/codebase/SUMMARY.md`:
|
|
85
|
+
|
|
86
|
+
```markdown
|
|
87
|
+
# Codebase Summary
|
|
88
|
+
|
|
89
|
+
**Mapped:** [date]
|
|
90
|
+
**Focus:** [all | specific area]
|
|
91
|
+
|
|
92
|
+
## Quick Reference
|
|
93
|
+
|
|
94
|
+
| Aspect | Key Points |
|
|
95
|
+
|--------|------------|
|
|
96
|
+
| Stack | [primary language, framework] |
|
|
97
|
+
| Architecture | [pattern, e.g., "MVC", "microservices"] |
|
|
98
|
+
| Entry Points | [main files/endpoints] |
|
|
99
|
+
| Test Coverage | [exists/missing, approach] |
|
|
100
|
+
|
|
101
|
+
## Key Files
|
|
102
|
+
|
|
103
|
+
- `[path]` - [purpose]
|
|
104
|
+
- `[path]` - [purpose]
|
|
105
|
+
|
|
106
|
+
## Development Notes
|
|
107
|
+
|
|
108
|
+
[Critical things to know before making changes]
|
|
109
|
+
|
|
110
|
+
## Concerns
|
|
111
|
+
|
|
112
|
+
[Top 3 issues to be aware of]
|
|
113
|
+
```
|
|
114
|
+
|
|
115
|
+
### Step 5: Next Steps
|
|
116
|
+
|
|
117
|
+
Report what was created and suggest:
|
|
118
|
+
|
|
119
|
+
```
|
|
120
|
+
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
|
121
|
+
GSD ► CODEBASE MAPPED ✓
|
|
122
|
+
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
|
123
|
+
|
|
124
|
+
Created:
|
|
125
|
+
- .planning/codebase/STACK.md
|
|
126
|
+
- .planning/codebase/ARCHITECTURE.md
|
|
127
|
+
- .planning/codebase/CONVENTIONS.md
|
|
128
|
+
- .planning/codebase/CONCERNS.md
|
|
129
|
+
- .planning/codebase/SUMMARY.md
|
|
130
|
+
|
|
131
|
+
▶ Next: Run gsd-bootstrap-planning to initialize project planning
|
|
132
|
+
```
|
|
133
|
+
|
|
134
|
+
## Output
|
|
135
|
+
|
|
136
|
+
Creates `.planning/codebase/` with:
|
|
137
|
+
- `STACK.md` - Languages, frameworks, dependencies
|
|
138
|
+
- `ARCHITECTURE.md` - Patterns, layers, data flow
|
|
139
|
+
- `CONVENTIONS.md` - Coding standards, naming patterns
|
|
140
|
+
- `CONCERNS.md` - Technical debt, issues
|
|
141
|
+
- `SUMMARY.md` - Quick reference overview
|
|
142
|
+
|
|
143
|
+
## Notes
|
|
144
|
+
|
|
145
|
+
- This prompt uses the `gsd-codebase-mapper` agent for specialized analysis
|
|
146
|
+
- Subagents get fresh context for each analysis area
|
|
147
|
+
- If analyzing a specific area (e.g., "api"), focus documents on that subsystem
|
|
148
|
+
- The codebase map informs subsequent planning prompts
|
|
149
|
+
|
|
150
|
+
````
|
|
@@ -0,0 +1,179 @@
|
|
|
1
|
+
````prompt
|
|
2
|
+
---
|
|
3
|
+
description: "GSD: Plan a phase with research and verification (enhanced)"
|
|
4
|
+
argument-hint: "Phase number (e.g., '2') [--skip-research] [--skip-verify]"
|
|
5
|
+
agent: gsd-planner
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
Create detailed execution plans for a roadmap phase with integrated research and verification.
|
|
9
|
+
|
|
10
|
+
## Process Overview
|
|
11
|
+
|
|
12
|
+
**Default flow:** Research (if needed) → Plan → Verify → Done
|
|
13
|
+
**With flags:** Can skip research or verification steps
|
|
14
|
+
|
|
15
|
+
## Step 1: Parse Arguments and Load Context
|
|
16
|
+
|
|
17
|
+
```bash
|
|
18
|
+
cat .planning/ROADMAP.md
|
|
19
|
+
cat .planning/STATE.md
|
|
20
|
+
cat .planning/config.json 2>/dev/null || echo "{}"
|
|
21
|
+
```
|
|
22
|
+
|
|
23
|
+
Parse the phase number from arguments. Extract phase details from ROADMAP.md.
|
|
24
|
+
|
|
25
|
+
## Step 2: Check for Existing Context
|
|
26
|
+
|
|
27
|
+
Look for existing artifacts:
|
|
28
|
+
|
|
29
|
+
```bash
|
|
30
|
+
# Check for discuss-phase output
|
|
31
|
+
ls .planning/phases/*/[phase]-CONTEXT.md 2>/dev/null
|
|
32
|
+
|
|
33
|
+
# Check for existing research
|
|
34
|
+
ls .planning/phases/*/[phase]-RESEARCH.md 2>/dev/null
|
|
35
|
+
ls .planning/research/*.md 2>/dev/null
|
|
36
|
+
|
|
37
|
+
# Check for codebase map
|
|
38
|
+
ls .planning/codebase/SUMMARY.md 2>/dev/null
|
|
39
|
+
```
|
|
40
|
+
|
|
41
|
+
Load any existing context:
|
|
42
|
+
- **CONTEXT.md** — implementation decisions from `/gsd-discuss-phase`
|
|
43
|
+
- **RESEARCH.md** — domain knowledge from `/gsd-research-phase`
|
|
44
|
+
- **Codebase map** — existing patterns from `/gsd-map-codebase`
|
|
45
|
+
|
|
46
|
+
## Step 3: Research (if needed)
|
|
47
|
+
|
|
48
|
+
**Skip if:** `--skip-research` flag OR research already exists
|
|
49
|
+
|
|
50
|
+
If research is needed, spawn a research subagent:
|
|
51
|
+
|
|
52
|
+
```
|
|
53
|
+
Use a subagent to research how to implement Phase [X]: [Name].
|
|
54
|
+
|
|
55
|
+
Focus on:
|
|
56
|
+
- Best practices for [domain]
|
|
57
|
+
- Integration with existing codebase patterns (see .planning/codebase/)
|
|
58
|
+
- Potential pitfalls
|
|
59
|
+
|
|
60
|
+
Write findings to .planning/phases/[NN-name]/[NN]-RESEARCH.md
|
|
61
|
+
```
|
|
62
|
+
|
|
63
|
+
## Step 4: Create Phase Directory
|
|
64
|
+
|
|
65
|
+
```bash
|
|
66
|
+
# Get phase name from ROADMAP.md
|
|
67
|
+
PHASE_NAME=$(grep "Phase [N]:" .planning/ROADMAP.md | head -1 | sed 's/.*Phase [0-9]*: //' | tr '[:upper:]' '[:lower:]' | tr ' ' '-')
|
|
68
|
+
mkdir -p ".planning/phases/${PADDED_PHASE}-${PHASE_NAME}"
|
|
69
|
+
```
|
|
70
|
+
|
|
71
|
+
## Step 5: Analyze and Plan
|
|
72
|
+
|
|
73
|
+
Based on phase requirements, break into 2-3 task plans per execution unit.
|
|
74
|
+
|
|
75
|
+
**Key decisions:**
|
|
76
|
+
- How many plans are needed? (2-3 tasks each)
|
|
77
|
+
- What dependencies exist between plans?
|
|
78
|
+
- Which plans can run in parallel (same wave)?
|
|
79
|
+
|
|
80
|
+
For each plan, create `.planning/phases/[NN-name]/[NN-PP-PLAN.md]`:
|
|
81
|
+
|
|
82
|
+
Use the format from `.github/vendor/get-shit-done/templates/phase-prompt.md`
|
|
83
|
+
|
|
84
|
+
**Frontmatter:**
|
|
85
|
+
```yaml
|
|
86
|
+
---
|
|
87
|
+
phase: NN-name
|
|
88
|
+
plan: PP
|
|
89
|
+
type: execute
|
|
90
|
+
wave: N # Plans in same wave can run in parallel
|
|
91
|
+
depends_on: [] # Plan IDs this depends on
|
|
92
|
+
files_modified: [] # Files this plan will touch
|
|
93
|
+
autonomous: true # false if has checkpoints
|
|
94
|
+
---
|
|
95
|
+
```
|
|
96
|
+
|
|
97
|
+
**Incorporate context:**
|
|
98
|
+
- Reference CONTEXT.md decisions (don't re-ask decided questions)
|
|
99
|
+
- Apply research findings to action descriptions
|
|
100
|
+
- Follow existing codebase conventions
|
|
101
|
+
|
|
102
|
+
## Step 6: Verify Plans (if not skipped)
|
|
103
|
+
|
|
104
|
+
**Skip if:** `--skip-verify` flag
|
|
105
|
+
|
|
106
|
+
After creating plans, verify coverage:
|
|
107
|
+
|
|
108
|
+
```
|
|
109
|
+
Use a subagent to verify the plans for Phase [X]:
|
|
110
|
+
|
|
111
|
+
Check:
|
|
112
|
+
1. All phase success criteria from ROADMAP.md are covered
|
|
113
|
+
2. All relevant requirements are addressed
|
|
114
|
+
3. Plans are properly sequenced (dependencies correct)
|
|
115
|
+
4. Verification commands are executable
|
|
116
|
+
5. No gaps or overlaps between plans
|
|
117
|
+
|
|
118
|
+
Report: PASS with notes, or FAIL with issues to fix
|
|
119
|
+
```
|
|
120
|
+
|
|
121
|
+
If verification fails, iterate:
|
|
122
|
+
1. Review issues
|
|
123
|
+
2. Update plans
|
|
124
|
+
3. Re-verify
|
|
125
|
+
|
|
126
|
+
Max 3 iterations, then present for human review.
|
|
127
|
+
|
|
128
|
+
## Step 7: Present Results
|
|
129
|
+
|
|
130
|
+
```
|
|
131
|
+
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
|
132
|
+
GSD ► PHASE [X] PLANNED ✓
|
|
133
|
+
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
|
134
|
+
|
|
135
|
+
**Phase [X]: [Name]** — [N] plan(s) in [M] wave(s)
|
|
136
|
+
|
|
137
|
+
| Wave | Plans | What it builds |
|
|
138
|
+
|------|-------|----------------|
|
|
139
|
+
| 1 | 01, 02 | [objectives] |
|
|
140
|
+
| 2 | 03 | [objective] |
|
|
141
|
+
|
|
142
|
+
Research: [Completed | Used existing | Skipped]
|
|
143
|
+
Verification: [Passed | Passed with notes | Skipped]
|
|
144
|
+
|
|
145
|
+
───────────────────────────────────────────────────────────────
|
|
146
|
+
|
|
147
|
+
## ▶ Next Up
|
|
148
|
+
|
|
149
|
+
**Execute Phase [X]**
|
|
150
|
+
|
|
151
|
+
Run gsd-execute-phase [X]
|
|
152
|
+
|
|
153
|
+
───────────────────────────────────────────────────────────────
|
|
154
|
+
```
|
|
155
|
+
|
|
156
|
+
## Output
|
|
157
|
+
|
|
158
|
+
Creates in `.planning/phases/[NN-name]/`:
|
|
159
|
+
- `[NN]-RESEARCH.md` — domain research (if conducted)
|
|
160
|
+
- `[NN]-01-PLAN.md` — first execution plan
|
|
161
|
+
- `[NN]-02-PLAN.md` — second execution plan (if needed)
|
|
162
|
+
- etc.
|
|
163
|
+
|
|
164
|
+
## Wave Planning
|
|
165
|
+
|
|
166
|
+
**Wave 1:** Independent plans that can start immediately
|
|
167
|
+
**Wave 2:** Plans that depend on Wave 1 completion
|
|
168
|
+
**Wave N:** Plans that depend on earlier waves
|
|
169
|
+
|
|
170
|
+
Within a wave, plans could theoretically run in parallel (if using background agents).
|
|
171
|
+
|
|
172
|
+
## Tips
|
|
173
|
+
|
|
174
|
+
- Keep plans small (2-3 tasks, ~50% context usage max)
|
|
175
|
+
- Prefer vertical slices over horizontal layers
|
|
176
|
+
- Include specific verification commands for your stack
|
|
177
|
+
- Reference existing code patterns when modifying existing files
|
|
178
|
+
|
|
179
|
+
````
|
|
@@ -10,23 +10,23 @@ Read `.planning/STATE.md` and `.planning/ROADMAP.md` and give me a quick status
|
|
|
10
10
|
|
|
11
11
|
Tell me (concisely):
|
|
12
12
|
|
|
13
|
-
1. **Where we are now** (1
|
|
14
|
-
- Current phase and
|
|
13
|
+
1. **Where we are now** (1-2 sentences)
|
|
14
|
+
- Current phase and wave
|
|
15
15
|
- What was last completed
|
|
16
|
+
- Any context files that exist (CONTEXT.md, RESEARCH.md)
|
|
16
17
|
|
|
17
18
|
2. **What's blocked** (if anything)
|
|
18
|
-
- Pending decisions
|
|
19
|
+
- Pending decisions or questions
|
|
19
20
|
- External dependencies
|
|
20
|
-
- Technical blockers
|
|
21
|
+
- Technical blockers or concerns
|
|
21
22
|
|
|
22
23
|
3. **The next best action**
|
|
23
|
-
- Which prompt to run next
|
|
24
|
-
-
|
|
24
|
+
- Which prompt or agent to run next
|
|
25
|
+
- Specific phase/wave to work on
|
|
25
26
|
|
|
26
27
|
## If `.planning/` files are missing
|
|
27
28
|
|
|
28
|
-
|
|
29
|
-
|
|
29
|
+
### For New Projects
|
|
30
30
|
```
|
|
31
31
|
.planning/ not initialized.
|
|
32
32
|
|
|
@@ -39,12 +39,50 @@ This will create:
|
|
|
39
39
|
- STATE.md
|
|
40
40
|
```
|
|
41
41
|
|
|
42
|
+
### For Existing Codebases (Brownfield)
|
|
43
|
+
```
|
|
44
|
+
.planning/ not initialized but codebase exists.
|
|
45
|
+
|
|
46
|
+
Run: gsd-map-codebase.prompt.md first
|
|
47
|
+
|
|
48
|
+
This will analyze the codebase and create:
|
|
49
|
+
- .planning/codebase/STACK.md
|
|
50
|
+
- .planning/codebase/ARCHITECTURE.md
|
|
51
|
+
- .planning/codebase/CONVENTIONS.md
|
|
52
|
+
- .planning/codebase/CONCERNS.md
|
|
53
|
+
|
|
54
|
+
Then run: gsd-bootstrap-planning.prompt.md
|
|
55
|
+
```
|
|
56
|
+
|
|
57
|
+
## Workflow Navigation
|
|
58
|
+
|
|
59
|
+
Based on phase state, suggest the appropriate next step:
|
|
60
|
+
|
|
61
|
+
| State | Next Action |
|
|
62
|
+
|-------|-------------|
|
|
63
|
+
| Phase not started | `gsd-discuss-phase.prompt.md` to capture context |
|
|
64
|
+
| Context captured | `gsd-research-phase.prompt.md` if complex domain |
|
|
65
|
+
| Ready to plan | `gsd-plan-phase.prompt.md` to create detailed plans |
|
|
66
|
+
| Plans ready | `gsd-execute-phase.prompt.md` to implement |
|
|
67
|
+
| Implementation done | `gsd-verify-work.prompt.md` to validate |
|
|
68
|
+
| Phase complete | Update STATE.md, move to next phase |
|
|
69
|
+
|
|
42
70
|
## Format
|
|
43
71
|
|
|
44
72
|
Keep it short — this is a quick status check, not a full report.
|
|
45
73
|
|
|
46
74
|
```
|
|
47
|
-
📍 Status: Phase 2 /
|
|
48
|
-
📋 Last: User auth endpoints implemented
|
|
49
|
-
|
|
75
|
+
📍 Status: Phase 2 / Wave 1 in progress
|
|
76
|
+
📋 Last: User auth endpoints implemented
|
|
77
|
+
📁 Context: CONTEXT.md ✓ | RESEARCH.md ✗
|
|
78
|
+
⚠️ Blocked: None
|
|
79
|
+
⏭️ Next: Run gsd-execute-phase for "Phase 2 Wave 2: Protected routes"
|
|
50
80
|
```
|
|
81
|
+
|
|
82
|
+
## Agent Hints
|
|
83
|
+
|
|
84
|
+
If the user seems stuck, suggest using specialized agents:
|
|
85
|
+
- **@gsd-codebase-mapper** — Re-analyze codebase after major changes
|
|
86
|
+
- **@gsd-researcher** — Deep dive into unfamiliar technology
|
|
87
|
+
- **@gsd-planner** — Rework a problematic plan
|
|
88
|
+
- **@gsd-verifier** — Validate completed work before proceeding
|
|
@@ -0,0 +1,69 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: "GSD: Quick task (skip full workflow for small changes)"
|
|
3
|
+
argument-hint: "Describe the quick task or fix"
|
|
4
|
+
agent: ask
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Quick Task Mode
|
|
8
|
+
|
|
9
|
+
This is for **small, self-contained tasks** that don't warrant the full GSD workflow.
|
|
10
|
+
|
|
11
|
+
## Examples of appropriate quick tasks:
|
|
12
|
+
- Fix a specific bug
|
|
13
|
+
- Add a small utility function
|
|
14
|
+
- Update configuration
|
|
15
|
+
- Refactor a single file
|
|
16
|
+
- Add a missing test
|
|
17
|
+
|
|
18
|
+
## NOT appropriate for quick mode:
|
|
19
|
+
- New features spanning multiple files
|
|
20
|
+
- Architectural changes
|
|
21
|
+
- Anything requiring research or discussion
|
|
22
|
+
|
|
23
|
+
---
|
|
24
|
+
|
|
25
|
+
## Your Task:
|
|
26
|
+
|
|
27
|
+
{{input}}
|
|
28
|
+
|
|
29
|
+
## Instructions:
|
|
30
|
+
|
|
31
|
+
1. **Analyze** — Understand what's being asked
|
|
32
|
+
2. **Plan briefly** — Mental model, no need for plan files
|
|
33
|
+
3. **Implement** — Make the changes
|
|
34
|
+
4. **Verify** — Run tests/checks if applicable
|
|
35
|
+
5. **Report** — Brief summary of what was done
|
|
36
|
+
|
|
37
|
+
## Constraints:
|
|
38
|
+
|
|
39
|
+
- **Keep changes minimal** — Don't refactor unrelated code
|
|
40
|
+
- **Follow existing patterns** — Match the codebase conventions
|
|
41
|
+
- **Test if possible** — Run existing tests to verify
|
|
42
|
+
- **Don't create planning files** — This bypasses the full workflow
|
|
43
|
+
|
|
44
|
+
## Output Format:
|
|
45
|
+
|
|
46
|
+
```
|
|
47
|
+
✅ Quick Task Complete
|
|
48
|
+
|
|
49
|
+
Changed:
|
|
50
|
+
- path/to/file.ts: [description]
|
|
51
|
+
- path/to/other.ts: [description]
|
|
52
|
+
|
|
53
|
+
Verified:
|
|
54
|
+
- [x] Tests pass / [x] Linter clean / [ ] N/A
|
|
55
|
+
|
|
56
|
+
Notes:
|
|
57
|
+
[Any important observations]
|
|
58
|
+
```
|
|
59
|
+
|
|
60
|
+
## If the task is too big:
|
|
61
|
+
|
|
62
|
+
Stop and suggest using the full workflow instead:
|
|
63
|
+
|
|
64
|
+
```
|
|
65
|
+
⚠️ This task is too complex for quick mode.
|
|
66
|
+
|
|
67
|
+
Recommended: Run gsd-discuss-phase.prompt.md to capture context,
|
|
68
|
+
then gsd-plan-phase.prompt.md to create a proper plan.
|
|
69
|
+
```
|
|
@@ -0,0 +1,184 @@
|
|
|
1
|
+
````prompt
|
|
2
|
+
---
|
|
3
|
+
description: "GSD: Research domain/implementation before planning"
|
|
4
|
+
argument-hint: "Phase number or specific topic (e.g., '3' or 'OAuth implementation')"
|
|
5
|
+
agent: gsd-researcher
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
Research how to implement a phase or topic before creating plans.
|
|
9
|
+
|
|
10
|
+
## When to Use
|
|
11
|
+
|
|
12
|
+
- **Complex/unfamiliar domains** — 3D, audio, ML, specialized protocols
|
|
13
|
+
- **Architecture decisions** — need to understand patterns before committing
|
|
14
|
+
- **Integration work** — connecting to new APIs or services
|
|
15
|
+
- **Before planning** — when you need to understand the landscape first
|
|
16
|
+
|
|
17
|
+
## Process
|
|
18
|
+
|
|
19
|
+
### Step 1: Load Context
|
|
20
|
+
|
|
21
|
+
```bash
|
|
22
|
+
cat .planning/PROJECT.md
|
|
23
|
+
cat .planning/ROADMAP.md
|
|
24
|
+
cat .planning/STATE.md
|
|
25
|
+
```
|
|
26
|
+
|
|
27
|
+
If a phase number is provided, extract the phase details from ROADMAP.md.
|
|
28
|
+
If a topic is provided, focus research on that topic.
|
|
29
|
+
|
|
30
|
+
### Step 2: Identify Research Questions
|
|
31
|
+
|
|
32
|
+
Based on the phase/topic, identify what needs to be researched:
|
|
33
|
+
|
|
34
|
+
```
|
|
35
|
+
Researching: [Phase X: Name] or [Topic]
|
|
36
|
+
|
|
37
|
+
Key questions to investigate:
|
|
38
|
+
1. [Question about technology/approach]
|
|
39
|
+
2. [Question about patterns/best practices]
|
|
40
|
+
3. [Question about potential pitfalls]
|
|
41
|
+
4. [Question about integration points]
|
|
42
|
+
|
|
43
|
+
Shall I proceed, or add/modify questions?
|
|
44
|
+
```
|
|
45
|
+
|
|
46
|
+
### Step 3: Conduct Research
|
|
47
|
+
|
|
48
|
+
For each question, use available tools:
|
|
49
|
+
|
|
50
|
+
- `#fetch` — retrieve documentation from URLs
|
|
51
|
+
- `#githubRepo` — find implementation examples
|
|
52
|
+
- `#codebase` — understand existing project patterns
|
|
53
|
+
- `#search` — general web search for approaches
|
|
54
|
+
|
|
55
|
+
Use subagents for parallel research when investigating multiple areas:
|
|
56
|
+
|
|
57
|
+
```
|
|
58
|
+
Use a subagent to research [specific question]. Return:
|
|
59
|
+
- Key findings with sources
|
|
60
|
+
- Recommended approach
|
|
61
|
+
- Pitfalls to avoid
|
|
62
|
+
```
|
|
63
|
+
|
|
64
|
+
### Step 4: Create Research Document
|
|
65
|
+
|
|
66
|
+
Write `.planning/research/[TOPIC]-RESEARCH.md` or `.planning/phases/[NN-name]/[NN]-RESEARCH.md`:
|
|
67
|
+
|
|
68
|
+
```markdown
|
|
69
|
+
# [Topic/Phase] Research
|
|
70
|
+
|
|
71
|
+
**Researched:** [date]
|
|
72
|
+
**Status:** Complete
|
|
73
|
+
**Confidence:** high | medium | low
|
|
74
|
+
|
|
75
|
+
## Overview
|
|
76
|
+
|
|
77
|
+
[1-2 paragraph summary of findings]
|
|
78
|
+
|
|
79
|
+
## Key Findings
|
|
80
|
+
|
|
81
|
+
### [Finding 1: Topic]
|
|
82
|
+
|
|
83
|
+
[Details with examples and sources]
|
|
84
|
+
|
|
85
|
+
**Source:** [URL or reference]
|
|
86
|
+
|
|
87
|
+
### [Finding 2: Topic]
|
|
88
|
+
|
|
89
|
+
[Details with examples and sources]
|
|
90
|
+
|
|
91
|
+
**Source:** [URL or reference]
|
|
92
|
+
|
|
93
|
+
## Recommended Approach
|
|
94
|
+
|
|
95
|
+
Based on research, the recommended approach is:
|
|
96
|
+
|
|
97
|
+
1. [Step/decision with rationale]
|
|
98
|
+
2. [Step/decision with rationale]
|
|
99
|
+
3. [Step/decision with rationale]
|
|
100
|
+
|
|
101
|
+
**Why this approach:**
|
|
102
|
+
- [Reason]
|
|
103
|
+
- [Reason]
|
|
104
|
+
|
|
105
|
+
## Alternatives Considered
|
|
106
|
+
|
|
107
|
+
| Approach | Pros | Cons | Why Not |
|
|
108
|
+
|----------|------|------|---------|
|
|
109
|
+
| [Alt 1] | [pros] | [cons] | [reason] |
|
|
110
|
+
| [Alt 2] | [pros] | [cons] | [reason] |
|
|
111
|
+
|
|
112
|
+
## Pitfalls to Avoid
|
|
113
|
+
|
|
114
|
+
- **[Pitfall 1]:** [What to avoid and why]
|
|
115
|
+
- **[Pitfall 2]:** [What to avoid and why]
|
|
116
|
+
|
|
117
|
+
## Integration with Existing Code
|
|
118
|
+
|
|
119
|
+
[How this connects to existing patterns in the codebase]
|
|
120
|
+
|
|
121
|
+
## Open Questions
|
|
122
|
+
|
|
123
|
+
- [Anything that couldn't be resolved through research]
|
|
124
|
+
|
|
125
|
+
## Sources
|
|
126
|
+
|
|
127
|
+
- [URL 1] — [description]
|
|
128
|
+
- [URL 2] — [description]
|
|
129
|
+
```
|
|
130
|
+
|
|
131
|
+
### Step 5: Next Steps
|
|
132
|
+
|
|
133
|
+
```
|
|
134
|
+
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
|
135
|
+
GSD ► RESEARCH COMPLETE ✓
|
|
136
|
+
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
|
137
|
+
|
|
138
|
+
**Topic:** [topic/phase]
|
|
139
|
+
**Confidence:** [high/medium/low]
|
|
140
|
+
**Key Recommendation:** [1-liner]
|
|
141
|
+
|
|
142
|
+
Created: .planning/[path]/[NAME]-RESEARCH.md
|
|
143
|
+
|
|
144
|
+
▶ Next: Run gsd-plan-phase to create execution plans
|
|
145
|
+
|
|
146
|
+
───────────────────────────────────────────────────────────────
|
|
147
|
+
```
|
|
148
|
+
|
|
149
|
+
## Output
|
|
150
|
+
|
|
151
|
+
Creates research document with:
|
|
152
|
+
- Key findings with sources
|
|
153
|
+
- Recommended approach with rationale
|
|
154
|
+
- Alternatives considered
|
|
155
|
+
- Pitfalls to avoid
|
|
156
|
+
- Integration notes
|
|
157
|
+
|
|
158
|
+
## Special Research Prompts
|
|
159
|
+
|
|
160
|
+
### For Project Research (like original GSD)
|
|
161
|
+
|
|
162
|
+
When researching before a new project, investigate:
|
|
163
|
+
|
|
164
|
+
**Stack:** "What's the standard stack for [domain]?"
|
|
165
|
+
**Features:** "What are typical features of [product type]?"
|
|
166
|
+
**Architecture:** "How is [domain] typically structured?"
|
|
167
|
+
**Pitfalls:** "What commonly goes wrong in [domain] projects?"
|
|
168
|
+
|
|
169
|
+
### For Library/API Research
|
|
170
|
+
|
|
171
|
+
Focus on:
|
|
172
|
+
- Official documentation
|
|
173
|
+
- Version compatibility
|
|
174
|
+
- Common usage patterns
|
|
175
|
+
- Known issues/limitations
|
|
176
|
+
|
|
177
|
+
### For Pattern Research
|
|
178
|
+
|
|
179
|
+
Focus on:
|
|
180
|
+
- Established patterns (not novel approaches)
|
|
181
|
+
- Real-world examples
|
|
182
|
+
- Trade-offs between approaches
|
|
183
|
+
|
|
184
|
+
````
|