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.
@@ -1,13 +1,25 @@
1
1
  ---
2
- description: "GSD-style workflow for VS Code + GitHub Copilot (planning + execution)"
2
+ description: "GSD-style workflow for VS Code + GitHub Copilot (enhanced with agents and subagents)"
3
3
  applyTo: "**"
4
4
  ---
5
5
 
6
- # GSD-Style Workflow (VS Code + Copilot)
6
+ # GSD Workflow (VS Code + GitHub Copilot)
7
7
 
8
- This repo uses a lightweight GSD (Get Shit Done) workflow for planning and execution.
8
+ This repo uses an enhanced GSD (Get Shit Done) workflow for planning and execution.
9
9
  It provides **context hygiene, atomic plans, explicit verification, and disciplined checkpoints**.
10
10
 
11
+ ## Quick Start
12
+
13
+ ```
14
+ 1. gsd-map-codebase — Analyze existing code (brownfield projects)
15
+ 2. gsd-bootstrap-planning — Initialize .planning/ files
16
+ 3. gsd-discuss-phase [N] — Capture implementation decisions
17
+ 4. gsd-plan-phase [N] — Create detailed plans
18
+ 5. gsd-execute-phase [N] — Execute plans
19
+ 6. gsd-verify-work [N] — Manual UAT
20
+ 7. Repeat for each phase
21
+ ```
22
+
11
23
  ## Planning Artifacts (Repository Memory)
12
24
 
13
25
  Maintain these files under `.planning/`:
@@ -18,51 +30,138 @@ Maintain these files under `.planning/`:
18
30
  | `REQUIREMENTS.md` | v1/v2/out-of-scope requirements (checkable) |
19
31
  | `ROADMAP.md` | Phases/slices with links to plan IDs |
20
32
  | `STATE.md` | Current position, decisions, blockers, next action |
33
+ | `config.json` | Workflow preferences (optional) |
21
34
 
22
- ## Execution Rules
35
+ ### Additional Artifacts
23
36
 
24
- - Prefer automation: if it can be done via CLI/tooling, do it.
25
- - Plans must be small: **2–3 tasks max** per plan file.
26
- - Every task must include:
27
- - **Action**: what to do and what to avoid (and why)
28
- - **Verify**: exact command(s) / checks to prove it worked
29
- - **Done**: measurable acceptance criteria
30
- - Stop for checkpoints only when unavoidable:
31
- - human verification (UI/UX),
32
- - human decision (architecture/product choice),
33
- - auth gates (login/consent needed).
37
+ | Directory | Purpose |
38
+ |-----------|---------|
39
+ | `codebase/` | Codebase analysis (from gsd-map-codebase) |
40
+ | `research/` | Domain research documents |
41
+ | `phases/` | Phase directories with plans, context, summaries |
34
42
 
35
- ## Plan Format
43
+ ## Custom Agents
36
44
 
37
- - Location: `.planning/phases/<NN-name>/<NN-NN-PLAN.md>`
38
- - Structure: YAML frontmatter + XML tasks (see vendor templates)
39
- - Reference: `.github/vendor/get-shit-done/templates/phase-prompt.md`
45
+ GSD includes specialized agents for different tasks. Install to `.github/agents/`:
40
46
 
41
- ## Workflow Prompts
47
+ | Agent | Purpose |
48
+ |-------|---------|
49
+ | `gsd-codebase-mapper` | Analyze existing codebase structure |
50
+ | `gsd-researcher` | Research domain knowledge and best practices |
51
+ | `gsd-planner` | Create detailed execution plans |
52
+ | `gsd-verifier` | Verify completed work meets goals |
53
+
54
+ ### Using Agents
55
+
56
+ Switch to an agent in the Chat view agent picker, or reference via prompts.
57
+
58
+ ## Subagents for Fresh Context
42
59
 
43
- Use the prompt files in `.github/prompts/`:
60
+ GSD prompts use subagents for operations that need fresh context:
61
+
62
+ ```
63
+ Use a subagent to [task description].
64
+ Return: [what to report back]
65
+ ```
66
+
67
+ Enable `runSubagent` in your tools. Subagents:
68
+ - Get their own context window (no pollution)
69
+ - Run to completion autonomously
70
+ - Return only final results to main session
71
+
72
+ ## Workflow Prompts
44
73
 
45
74
  | Prompt | When to use |
46
75
  |--------|-------------|
76
+ | `gsd-map-codebase.prompt.md` | Analyze existing codebase (brownfield) |
47
77
  | `gsd-bootstrap-planning.prompt.md` | Initialize `.planning/*` for a new project |
48
- | `gsd-plan-slice.prompt.md` | Create a 2–3 task plan for the next slice |
49
- | `gsd-execute-plan.prompt.md` | Execute a plan file |
78
+ | `gsd-discuss-phase.prompt.md` | Capture implementation decisions before planning |
79
+ | `gsd-research-phase.prompt.md` | Research complex domains or approaches |
80
+ | `gsd-plan-phase.prompt.md` | Create detailed execution plans for a phase |
81
+ | `gsd-execute-phase.prompt.md` | Execute all plans in a phase |
50
82
  | `gsd-verify-work.prompt.md` | Conversational UAT after execution |
51
83
  | `gsd-progress.prompt.md` | Check current status and next action |
52
84
 
85
+ ### Legacy Prompts (still available)
86
+
87
+ | Prompt | Notes |
88
+ |--------|-------|
89
+ | `gsd-plan-slice.prompt.md` | Simpler planning (2-3 tasks) |
90
+ | `gsd-execute-plan.prompt.md` | Execute single plan file |
91
+
92
+ ## Execution Rules
93
+
94
+ - **Prefer automation:** if it can be done via CLI/tooling, do it
95
+ - **Plans must be small:** 2–3 tasks max per plan file
96
+ - **Fresh context per major task:** use subagents for complex operations
97
+ - **One commit per task:** atomic, reversible commits
98
+
99
+ ### Task Requirements
100
+
101
+ Every task must include:
102
+ - **Action:** what to do and what to avoid (and why)
103
+ - **Verify:** exact command(s) / checks to prove it worked
104
+ - **Done:** measurable acceptance criteria
105
+
106
+ ### Checkpoint Types
107
+
108
+ Stop for checkpoints only when unavoidable:
109
+ - `checkpoint:human-verify` — UI/UX verification
110
+ - `checkpoint:decision` — architecture/product choice
111
+ - `checkpoint:human-action` — truly unavoidable manual steps
112
+
113
+ ## Wave-Based Execution
114
+
115
+ Plans are organized into waves:
116
+ - **Wave 1:** Independent plans that can start immediately
117
+ - **Wave 2:** Plans that depend on Wave 1
118
+ - **Wave N:** Plans that depend on earlier waves
119
+
120
+ Within a wave, plans can potentially run in parallel using background agents.
121
+
122
+ ## Background Agents
123
+
124
+ For long-running or parallel work, use Copilot CLI background agents:
125
+
126
+ ```
127
+ @cli [task description]
128
+ ```
129
+
130
+ Background agents:
131
+ - Run in isolated Git worktrees
132
+ - Can work while you continue other tasks
133
+ - Merge results when complete
134
+
53
135
  ## STATE.md Discipline
54
136
 
55
- Whenever you:
56
- - make a decision,
57
- - discover a constraint,
58
- - hit a blocker,
59
- - finish a slice,
137
+ Record in `.planning/STATE.md` whenever you:
138
+ - Make a decision
139
+ - Discover a constraint
140
+ - Hit a blocker
141
+ - Finish a slice
142
+
143
+ Always include the **next action**.
144
+
145
+ ## Plan Format
146
+
147
+ - Location: `.planning/phases/<NN-name>/<NN-PP-PLAN.md>`
148
+ - Structure: YAML frontmatter + XML tasks
149
+ - Reference: `.github/vendor/get-shit-done/templates/phase-prompt.md`
150
+
151
+ ## Git Commit Conventions
60
152
 
61
- …record it in `.planning/STATE.md` with the next action.
153
+ ```bash
154
+ # One commit per task
155
+ feat(NN-PP): [task description]
156
+ fix(NN-PP): [fix description]
157
+ test(NN-PP): [test description]
158
+ docs(NN-PP): [docs description]
159
+ refactor(NN-PP): [refactor description]
160
+ ```
62
161
 
63
- ## Verification Conventions
162
+ Commit immediately after verification passes.
64
163
 
65
- Adapt verification commands to your stack:
164
+ ## Verification Commands by Stack
66
165
 
67
166
  | Stack | Example verify commands |
68
167
  |-------|------------------------|
@@ -72,4 +171,34 @@ Adapt verification commands to your stack:
72
171
  | Go | `go build ./...`, `go test ./...` |
73
172
  | Rust | `cargo build`, `cargo test` |
74
173
 
75
- Plans carry the specific verify commands — the workflow is stack-agnostic.
174
+ Plans carry specific verify commands — the workflow is stack-agnostic.
175
+
176
+ ## File Structure
177
+
178
+ ```
179
+ .planning/
180
+ ├── PROJECT.md
181
+ ├── REQUIREMENTS.md
182
+ ├── ROADMAP.md
183
+ ├── STATE.md
184
+ ├── config.json
185
+ ├── codebase/ # From gsd-map-codebase
186
+ │ ├── STACK.md
187
+ │ ├── ARCHITECTURE.md
188
+ │ ├── CONVENTIONS.md
189
+ │ ├── CONCERNS.md
190
+ │ └── SUMMARY.md
191
+ ├── research/ # Domain research
192
+ │ └── [TOPIC]-RESEARCH.md
193
+ └── phases/
194
+ ├── 01-foundation/
195
+ │ ├── 01-CONTEXT.md
196
+ │ ├── 01-RESEARCH.md
197
+ │ ├── 01-01-PLAN.md
198
+ │ ├── 01-01-SUMMARY.md
199
+ │ └── 01-VERIFICATION.md
200
+ └── 02-core-features/
201
+ ├── 02-CONTEXT.md
202
+ ├── 02-01-PLAN.md
203
+ └── 02-01-SUMMARY.md
204
+ ```
@@ -0,0 +1,178 @@
1
+ ````prompt
2
+ ---
3
+ description: "GSD: Discuss phase details before planning (capture implementation decisions)"
4
+ argument-hint: "Phase number or name (e.g., '2' or 'authentication')"
5
+ agent: ask
6
+ ---
7
+
8
+ Gather context and capture implementation decisions for a phase before planning begins.
9
+
10
+ ## Purpose
11
+
12
+ Your roadmap has a sentence or two per phase. That's not enough context to build something the way *you* imagine it. This step captures your preferences before anything gets researched or planned.
13
+
14
+ The output — `CONTEXT.md` — feeds directly into:
15
+ 1. **Researcher** — knows what patterns to investigate
16
+ 2. **Planner** — knows what decisions are locked
17
+
18
+ ## Process
19
+
20
+ ### Step 1: Load Phase Context
21
+
22
+ Read the planning files:
23
+
24
+ ```bash
25
+ cat .planning/ROADMAP.md
26
+ cat .planning/STATE.md
27
+ ```
28
+
29
+ If no phase specified, ask which phase to discuss.
30
+
31
+ ### Step 2: Analyze Phase for Gray Areas
32
+
33
+ Based on what's being built, identify decision points. Different feature types have different gray areas:
34
+
35
+ **Visual/UI Features:**
36
+ - Layout and density (cards vs lists, compact vs spacious)
37
+ - Interactions (hover states, animations, transitions)
38
+ - Empty states and loading states
39
+ - Responsive behavior
40
+ - Accessibility considerations
41
+
42
+ **APIs/Backend:**
43
+ - Response format and structure
44
+ - Error handling approach
45
+ - Authentication/authorization patterns
46
+ - Rate limiting, pagination
47
+ - Logging and observability
48
+
49
+ **Data/Content Systems:**
50
+ - Content structure and organization
51
+ - Naming conventions
52
+ - Validation rules
53
+ - Migration approach for existing data
54
+
55
+ **Infrastructure/DevOps:**
56
+ - Deployment strategy
57
+ - Environment configuration
58
+ - Monitoring and alerting
59
+ - Rollback procedures
60
+
61
+ ### Step 3: Present Gray Areas
62
+
63
+ Present the identified gray areas and ask which to discuss:
64
+
65
+ ```
66
+ I've identified these decision points for Phase [X]: [Name]
67
+
68
+ **Must Decide:**
69
+ 1. [Gray area 1] — affects [what downstream]
70
+ 2. [Gray area 2] — affects [what downstream]
71
+
72
+ **Optional/Nice to Clarify:**
73
+ 3. [Gray area 3]
74
+ 4. [Gray area 4]
75
+
76
+ Which would you like to discuss? (comma-separated numbers, or "all")
77
+ ```
78
+
79
+ ### Step 4: Deep-Dive Each Selected Area
80
+
81
+ For each selected gray area, have a focused conversation:
82
+
83
+ 1. **Ask** about preferences and constraints
84
+ 2. **Probe** for specifics ("What should happen when...?")
85
+ 3. **Confirm** understanding
86
+ 4. **Move on** when satisfied or user says "that's enough"
87
+
88
+ Example dialogue:
89
+ ```
90
+ User: Let's discuss layout
91
+ Assistant: For the [feature], I see a few layout approaches:
92
+ - Cards in a grid (visual, scannable)
93
+ - Table rows (dense, sortable)
94
+ - List with previews (balanced)
95
+
96
+ What feels right for your use case? Any references to point me at?
97
+ ```
98
+
99
+ ### Step 5: Create CONTEXT.md
100
+
101
+ After discussion, create the context file in the phase directory:
102
+
103
+ ```bash
104
+ mkdir -p ".planning/phases/[NN-name]"
105
+ ```
106
+
107
+ Write `.planning/phases/[NN-name]/[NN]-CONTEXT.md`:
108
+
109
+ ```markdown
110
+ # Phase [X]: [Name] - Context
111
+
112
+ **Gathered:** [date]
113
+ **Status:** Ready for planning
114
+
115
+ ## Phase Boundary
116
+
117
+ [Clear statement of what this phase delivers — the scope anchor]
118
+
119
+ ## Implementation Decisions
120
+
121
+ ### [Category 1 that was discussed]
122
+ - [Decision or preference captured]
123
+ - [Another decision if applicable]
124
+
125
+ ### [Category 2 that was discussed]
126
+ - [Decision or preference captured]
127
+
128
+ ### Claude's Discretion
129
+ [Anything explicitly left as "your choice" during discussion]
130
+
131
+ ## Open Questions
132
+ [Anything that still needs clarification, if any]
133
+
134
+ ## References
135
+ [Any examples, links, or inspirations mentioned]
136
+ ```
137
+
138
+ ### Step 6: Update STATE.md
139
+
140
+ Add a note about context gathering:
141
+ ```
142
+ **Context Gathered:** Phase [X] - [summary of key decisions]
143
+ ```
144
+
145
+ ### Step 7: Next Steps
146
+
147
+ ```
148
+ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
149
+ GSD ► PHASE [X] CONTEXT CAPTURED ✓
150
+ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
151
+
152
+ **Decisions captured:** [count]
153
+ **Ready for:** Planning
154
+
155
+ ▶ Next: Run gsd-plan-phase to create execution plans
156
+ Or: Run gsd-research-phase if domain research needed first
157
+
158
+ ───────────────────────────────────────────────────────────────
159
+ ```
160
+
161
+ ## Output
162
+
163
+ Creates `.planning/phases/[NN-name]/[NN]-CONTEXT.md` with:
164
+ - Phase boundary (scope)
165
+ - Implementation decisions by category
166
+ - Areas left to Claude's discretion
167
+ - Open questions
168
+ - References
169
+
170
+ ## Tips
171
+
172
+ - This is conversational — no code is written
173
+ - Be specific: "card layout" not "whatever looks good"
174
+ - Mention anti-patterns: "definitely NOT a modal"
175
+ - Share references: "like how GitHub does it"
176
+ - It's OK to say "your choice" for things you don't care about
177
+
178
+ ````
@@ -0,0 +1,253 @@
1
+ ````prompt
2
+ ---
3
+ description: "GSD: Execute all plans in a phase with wave-based execution"
4
+ argument-hint: "Phase number (e.g., '2')"
5
+ agent: agent
6
+ ---
7
+
8
+ Execute all plans in a phase using wave-based execution.
9
+
10
+ ## Process Overview
11
+
12
+ 1. Discover all plans for the phase
13
+ 2. Group plans by wave (from frontmatter)
14
+ 3. Execute waves sequentially
15
+ 4. Within each wave, execute plans (can use subagents for isolation)
16
+ 5. Verify phase completion
17
+ 6. Update state and create summaries
18
+
19
+ ## Step 1: Load Phase Context
20
+
21
+ ```bash
22
+ # Get phase details
23
+ cat .planning/ROADMAP.md
24
+ cat .planning/STATE.md
25
+
26
+ # Find the phase directory
27
+ ls .planning/phases/ | grep "^0*[PHASE]-"
28
+ ```
29
+
30
+ ## Step 2: Discover Plans
31
+
32
+ ```bash
33
+ # List all plans for this phase
34
+ ls .planning/phases/[NN-name]/*-PLAN.md
35
+ ```
36
+
37
+ Parse frontmatter from each plan to extract:
38
+ - `wave` — execution order
39
+ - `depends_on` — dependencies
40
+ - `autonomous` — whether checkpoints exist
41
+
42
+ Group plans by wave number.
43
+
44
+ ## Step 3: Execute Wave by Wave
45
+
46
+ For each wave (starting with wave 1):
47
+
48
+ ### Present Wave
49
+ ```
50
+ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
51
+ WAVE [N] — [count] plan(s)
52
+ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
53
+
54
+ Plans in this wave:
55
+ - [NN-01]: [objective]
56
+ - [NN-02]: [objective]
57
+ ```
58
+
59
+ ### Execute Plans in Wave
60
+
61
+ **Option A: Sequential (default)**
62
+ Execute each plan in order, providing fresh context for complex plans:
63
+
64
+ ```
65
+ For plan [NN-PP]:
66
+ Use a subagent to execute this plan. The subagent should:
67
+ 1. Read the full plan file
68
+ 2. Execute each task sequentially
69
+ 3. Run verification after each task
70
+ 4. Stop on checkpoint tasks and report back
71
+ 5. Create SUMMARY.md when complete
72
+ ```
73
+
74
+ **Option B: Parallel with Background Agents**
75
+ For truly independent plans, suggest using background agents:
76
+
77
+ ```
78
+ These plans are independent. You can:
79
+ 1. Execute sequentially here (default)
80
+ 2. Run in parallel using @cli for isolated execution
81
+
82
+ Choose approach:
83
+ ```
84
+
85
+ ### Per-Task Execution
86
+
87
+ For each task in a plan:
88
+
89
+ **`type="auto"` tasks:**
90
+ 1. Implement the changes described in `<action>`
91
+ 2. Run the `<verify>` command(s)
92
+ 3. If verification fails: stop and report with proposed fixes
93
+ 4. If verification passes: confirm `<done>` criteria met
94
+ 5. Commit changes:
95
+ ```bash
96
+ git add [files]
97
+ git commit -m "[type]([phase]-[plan]): [task-name]"
98
+ ```
99
+
100
+ **`type="checkpoint:*"` tasks:**
101
+ 1. STOP immediately
102
+ 2. Display checkpoint message with what's needed
103
+ 3. Wait for user response before continuing
104
+
105
+ ### After Each Plan
106
+
107
+ Create summary file `.planning/phases/[NN-name]/[NN-PP-SUMMARY.md]`:
108
+
109
+ ```markdown
110
+ # Phase [X] Plan [Y]: [Name] Summary
111
+
112
+ **Completed:** [timestamp]
113
+ **Duration:** [time]
114
+
115
+ ## Accomplishments
116
+ - [What was built]
117
+
118
+ ## Files Created/Modified
119
+ - `path/to/file` - What it does
120
+
121
+ ## Decisions Made
122
+ [Key decisions, or "None - followed plan as specified"]
123
+
124
+ ## Issues Encountered
125
+ [Problems and resolutions, or "None"]
126
+
127
+ ## Verification Results
128
+ - [x] [Verification check 1]
129
+ - [x] [Verification check 2]
130
+ ```
131
+
132
+ ## Step 4: Wave Transition
133
+
134
+ After completing a wave:
135
+
136
+ ```
137
+ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
138
+ WAVE [N] COMPLETE ✓
139
+ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
140
+
141
+ Completed: [list plans completed]
142
+ Commits: [count]
143
+
144
+ Next: Wave [N+1] with [count] plans
145
+ ```
146
+
147
+ Continue to next wave.
148
+
149
+ ## Step 5: Phase Verification
150
+
151
+ After all waves complete, verify phase goals:
152
+
153
+ ```
154
+ Use a subagent with the gsd-verifier agent to verify Phase [X]:
155
+
156
+ Check all success criteria from ROADMAP.md.
157
+ Report PASS/FAIL with details.
158
+ ```
159
+
160
+ Create `.planning/phases/[NN-name]/[NN]-VERIFICATION.md` with results.
161
+
162
+ ## Step 6: Update State
163
+
164
+ Update `.planning/STATE.md`:
165
+ ```markdown
166
+ ## Current Position
167
+ - Phase: [X] - COMPLETE
168
+ - Plans executed: [list]
169
+ - Next: Phase [X+1]
170
+
171
+ ## Recent Decisions
172
+ [Any decisions made during execution]
173
+ ```
174
+
175
+ Update `.planning/ROADMAP.md`:
176
+ - Mark phase as complete
177
+ - Update progress indicators
178
+
179
+ ## Step 7: Present Completion
180
+
181
+ ```
182
+ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
183
+ GSD ► PHASE [X] COMPLETE ✓
184
+ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
185
+
186
+ **Phase [X]: [Name]**
187
+
188
+ | Metric | Value |
189
+ |--------|-------|
190
+ | Plans | [N] executed |
191
+ | Waves | [M] completed |
192
+ | Commits | [K] created |
193
+ | Verification | PASS / PARTIAL / FAIL |
194
+
195
+ ───────────────────────────────────────────────────────────────
196
+
197
+ ## ▶ Next Up
198
+
199
+ **Phase [X+1]: [Name]** — [goal]
200
+
201
+ Options:
202
+ - Run gsd-discuss-phase [X+1] — gather context first
203
+ - Run gsd-plan-phase [X+1] — plan directly
204
+ - Run gsd-verify-work [X] — manual UAT for this phase
205
+
206
+ ───────────────────────────────────────────────────────────────
207
+ ```
208
+
209
+ ## Git Commit Strategy
210
+
211
+ **One commit per task:**
212
+ ```bash
213
+ # Type based on what changed
214
+ feat([phase]-[plan]): [task description]
215
+ fix([phase]-[plan]): [fix description]
216
+ test([phase]-[plan]): [test description]
217
+ docs([phase]-[plan]): [docs description]
218
+ refactor([phase]-[plan]): [refactor description]
219
+ ```
220
+
221
+ **Commit immediately after verification passes** — don't batch.
222
+
223
+ ## Error Handling
224
+
225
+ **If a task fails verification:**
226
+ 1. Report the failure with error details
227
+ 2. Propose fixes
228
+ 3. Ask: "Retry with fix, or stop for manual intervention?"
229
+
230
+ **If a plan fails completely:**
231
+ 1. Mark plan as failed
232
+ 2. Save partial progress
233
+ 3. Report what succeeded and what failed
234
+ 4. Ask whether to continue with next plan or stop
235
+
236
+ ## Background Agent Integration
237
+
238
+ For long-running or parallelizable phases, suggest:
239
+
240
+ ```
241
+ This phase has [N] independent plans in wave 1.
242
+
243
+ You can use @cli to run them as background agents:
244
+ - Each gets isolated worktree
245
+ - All run in parallel
246
+ - Merge results when complete
247
+
248
+ Use background agents? (yes/no)
249
+ ```
250
+
251
+ If yes, hand off to background agent sessions.
252
+
253
+ ````