gsd-opencode 1.5.2 → 1.6.0

package/get-shit-done/workflows/map-codebase.md

@@ -1,21 +1,23 @@
 <purpose>
-Orchestrate parallel explore agents to analyze codebase and produce structured documents in .planning/codebase/
+Orchestrate parallel codebase mapper agents to analyze codebase and produce structured documents in .planning/codebase/
 
-Each agent has fresh context and focuses on specific aspects. Output is concise and actionable for planning.
+Each agent has fresh context, explores a specific focus area, and **writes documents directly**. The orchestrator only receives confirmation + line counts, then writes a summary.
+
+Output: .planning/codebase/ folder with 7 structured documents about the codebase state.
 </purpose>
 
 <philosophy>
-**Why parallel agents:**
+**Why dedicated mapper agents:**
 - Fresh context per domain (no token contamination)
-- Thorough analysis without context exhaustion
-- Each agent optimized for its domain (tech vs organization vs quality vs issues)
+- Agents write documents directly (no context transfer back to orchestrator)
+- Orchestrator only summarizes what was created (minimal context usage)
 - Faster execution (agents run simultaneously)
 
 **Document quality over length:**
-Include enough detail to be useful as reference. Prioritize practical examples (especially code patterns) over arbitrary brevity. A 200-line TESTING.md with real patterns is more valuable than a 74-line summary.
+Include enough detail to be useful as reference. Prioritize practical examples (especially code patterns) over arbitrary brevity.
 
 **Always include file paths:**
-Documents are reference material for OpenCode when planning/executing. Vague descriptions like "UserService handles users" are not actionable. Always include actual file paths formatted with backticks: `src/services/user.ts`. This allows OpenCode to navigate directly to relevant code without re-searching. Do NOT include line numbers (they go stale), just file paths.
+Documents are reference material for OpenCode when planning/executing. Always include actual file paths formatted with backticks: `src/services/user.ts`.
 </philosophy>
 
 <process>
@@ -57,286 +59,136 @@ mkdir -p .planning/codebase
 ```
 
 **Expected output files:**
-- STACK.md (from stack.md template)
-- ARCHITECTURE.md (from architecture.md template)
-- STRUCTURE.md (from structure.md template)
-- CONVENTIONS.md (from conventions.md template)
-- TESTING.md (from testing.md template)
-- INTEGRATIONS.md (from integrations.md template)
-- CONCERNS.md (from concerns.md template)
+- STACK.md (from tech mapper)
+- INTEGRATIONS.md (from tech mapper)
+- ARCHITECTURE.md (from arch mapper)
+- STRUCTURE.md (from arch mapper)
+- CONVENTIONS.md (from quality mapper)
+- TESTING.md (from quality mapper)
+- CONCERNS.md (from concerns mapper)
 
 Continue to spawn_agents.
 </step>
 
 <step name="spawn_agents">
-Spawn 4 parallel explore agents to analyze codebase.
+Spawn 4 parallel gsd-codebase-mapper agents.
+
+Use Task tool with `subagent_type="gsd-codebase-mapper"` and `run_in_background=true` for parallel execution.
 
-Use Task tool with `subagent_type="explore"` and `run_in_background=true` for parallel execution.
+**CRITICAL:** Use the dedicated `gsd-codebase-mapper` agent, NOT `Explore`. The mapper agent writes documents directly.
 
-**Agent 1: Stack + Integrations (Technology Focus)**
+**Agent 1: Tech Focus**
 
 Task tool parameters:
 ```
-subagent_type: "explore"
+subagent_type: "gsd-codebase-mapper"
 run_in_background: true
-task_description: "Analyze codebase technology stack and external integrations"
+description: "Map codebase tech stack"
 ```
 
 Prompt:
 ```
+Focus: tech
+
 Analyze this codebase for technology stack and external integrations.
 
-IMPORTANT: Always include actual file paths in your findings. Use backtick formatting like `src/config/database.ts`. This makes the output actionable for planning.
-
-Focus areas:
-1. Languages (check file extensions, package manifests)
-2. Runtime environment (Node.js, Python, etc. - check .nvmrc, .python-version, engines field)
-3. Package manager and lockfiles
-4. Frameworks (web, testing, build tools)
-5. Key dependencies (critical packages for functionality)
-6. External services (APIs, databases, auth providers)
-7. Third-party integrations (payment, analytics, etc.)
-8. Configuration approach (.env, config files)
-
-Search for:
-- package.json / requirements.txt / Cargo.toml / go.mod
-- .env files, .env.example
-- Config files (vite.config, webpack.config, tsconfig.json)
-- API client code, database connection code
-- Import statements for major libraries
-
-Output findings for populating these sections:
-- STACK.md: Languages, Runtime, Frameworks, Dependencies, Configuration
-- INTEGRATIONS.md: External APIs, Services, Third-party tools
-
-For each finding, include the file path where you found it. Example:
-- "TypeScript 5.3 - `package.json`"
-- "Supabase client - `src/lib/supabase.ts`"
-- "Stripe integration - `src/services/stripe.ts`, `src/webhooks/stripe.ts`"
-
-If something is not found, note "Not detected" for that category.
+write these documents to .planning/codebase/:
+- STACK.md - Languages, runtime, frameworks, dependencies, configuration
+- INTEGRATIONS.md - External APIs, databases, auth providers, webhooks
+
+Explore thoroughly. write documents directly using templates. Return confirmation only.
 ```
 
-**Agent 2: Architecture + Structure (Organization Focus)**
+**Agent 2: Architecture Focus**
 
 Task tool parameters:
 ```
-subagent_type: "explore"
+subagent_type: "gsd-codebase-mapper"
 run_in_background: true
-task_description: "Analyze codebase architecture patterns and directory structure"
+description: "Map codebase architecture"
 ```
 
 Prompt:
 ```
+Focus: arch
+
 Analyze this codebase architecture and directory structure.
 
-IMPORTANT: Always include actual file paths in your findings. Use backtick formatting like `src/index.ts`. This makes the output actionable for planning.
-
-Focus areas:
-1. Overall architectural pattern (monolith, microservices, layered, etc.)
-2. Conceptual layers (API, service, data, utility)
-3. Data flow and request lifecycle
-4. Key abstractions and patterns (services, controllers, repositories)
-5. Entry points (main files, server files, CLI entry)
-6. Directory organization and purposes
-7. Module boundaries
-8. Naming conventions for directories and files
-
-Search for:
-- Entry points: index.ts, main.ts, server.ts, app.ts, cli.ts
-- Directory structure patterns (src/, lib/, components/, services/)
-- Import patterns (what imports what)
-- Recurring code patterns (base classes, interfaces, common abstractions)
-
-Output findings for populating these sections:
-- ARCHITECTURE.md: Pattern, Layers, Data Flow, Abstractions, Entry Points
-- STRUCTURE.md: Directory layout, Organization, Key locations
-
-For each finding, include the file path. Examples:
-- "CLI entry point: `bin/install.js`"
-- "Service layer: `src/services/*.ts` (UserService, ProjectService)"
-- "API routes: `src/routes/api/*.ts`"
-
-If something is not clear, provide best-guess interpretation based on code structure.
+write these documents to .planning/codebase/:
+- ARCHITECTURE.md - Pattern, layers, data flow, abstractions, entry points
+- STRUCTURE.md - Directory layout, key locations, naming conventions
+
+Explore thoroughly. write documents directly using templates. Return confirmation only.
 ```
 
-**Agent 3: Conventions + Testing (Quality Focus)**
+**Agent 3: Quality Focus**
 
 Task tool parameters:
 ```
-subagent_type: "explore"
+subagent_type: "gsd-codebase-mapper"
 run_in_background: true
-task_description: "Analyze coding conventions and test patterns"
+description: "Map codebase conventions"
 ```
 
 Prompt:
 ```
-Analyze this codebase for coding conventions and testing practices.
-
-IMPORTANT: Always include actual file paths in your findings. Use backtick formatting like `vitest.config.ts`. This makes the output actionable for planning.
-
-Focus areas:
-1. Code style (indentation, quotes, semicolons, formatting)
-2. File naming conventions (kebab-case, PascalCase, etc.)
-3. Function/variable naming patterns
-4. Comment and documentation style
-5. Test framework and structure
-6. Test organization (unit, integration, e2e)
-7. Test coverage approach
-8. Linting and formatting tools
-
-Search for:
-- Config files: .eslintrc, .prettierrc, tsconfig.json
-- Test files: *.test.*, *.spec.*, __tests__/
-- Test setup: vitest.config, jest.config
-- Code patterns across multiple files
-- README or CONTRIBUTING docs
-
-Output findings for populating these sections:
-- CONVENTIONS.md: Code Style, Naming, Patterns, Documentation
-- TESTING.md: Framework, Structure, Coverage, Tools
-
-For each finding, include file paths. Examples:
-- "Prettier config: `.prettierrc`"
-- "Test pattern: `src/**/*.test.ts` (co-located with source)"
-- "Example of naming convention: `src/services/user-service.ts`"
-
-Look at actual code files to infer conventions if config files are missing.
+Focus: quality
+
+Analyze this codebase for coding conventions and testing patterns.
+
+write these documents to .planning/codebase/:
+- CONVENTIONS.md - Code style, naming, patterns, error handling
+- TESTING.md - Framework, structure, mocking, coverage
+
+Explore thoroughly. write documents directly using templates. Return confirmation only.
 ```
 
-**Agent 4: Concerns (Issues Focus)**
+**Agent 4: Concerns Focus**
 
 Task tool parameters:
 ```
-subagent_type: "explore"
+subagent_type: "gsd-codebase-mapper"
 run_in_background: true
-task_description: "Identify technical debt and areas of concern"
+description: "Map codebase concerns"
 ```
 
 Prompt:
 ```
+Focus: concerns
+
 Analyze this codebase for technical debt, known issues, and areas of concern.
 
-CRITICAL: Always include actual file paths in your findings. Use backtick formatting like `src/auth/login.ts`. Concerns without file paths are not actionable. For each issue found, specify exactly where it is.
-
-Focus areas:
-1. TODO and FIXME comments
-2. Complex or hard-to-understand code
-3. Missing error handling (try/catch, error checks)
-4. Security patterns (hardcoded secrets, unsafe operations)
-5. Outdated dependencies (check versions against current)
-6. Missing tests for critical code
-7. Duplicate code patterns
-8. Performance concerns (N+1 queries, inefficient loops)
-9. Documentation gaps (complex code without comments)
-
-Search for:
-- TODO, FIXME, HACK, XXX comments
-- Large functions or files (>200 lines)
-- Repeated code patterns
-- Missing .env.example when .env is used
-- Dependencies with known vulnerabilities (check versions)
-- Error-prone patterns (no validation, no error handling)
-
-Output findings for populating:
-- CONCERNS.md: Technical Debt, Issues, Security, Performance, Documentation
-
-For EVERY concern, include file paths. Examples:
-- "Direct DB queries in components: `src/pages/Dashboard.tsx`, `src/pages/Profile.tsx`"
-- "Missing error handling: `src/api/webhook.ts` (Stripe webhook has no try/catch)"
-- "TODO: 'fix race condition' in `src/services/subscription.ts`"
-
-Be constructive - focus on actionable concerns, not nitpicks.
-If codebase is clean, note that rather than inventing problems.
+write this document to .planning/codebase/:
+- CONCERNS.md - Tech debt, bugs, security, performance, fragile areas
+
+Explore thoroughly. write document directly using template. Return confirmation only.
 ```
 
-Continue to collect_results.
+Continue to collect_confirmations.
 </step>
 
-<step name="collect_results">
+<step name="collect_confirmations">
 Wait for all 4 agents to complete.
 
-Use TaskOutput tool to collect results from each agent. Since agents were run with `run_in_background=true`, retrieve their output.
-
-**Collection pattern:**
-
-For each agent, use TaskOutput tool to get the full exploration findings.
-
-**Aggregate findings by document:**
-
-From Agent 1 output, extract:
-- STACK.md sections: Languages, Runtime, Frameworks, Dependencies, Configuration, Platform
-- INTEGRATIONS.md sections: External APIs, Services, Authentication, Webhooks
-
-From Agent 2 output, extract:
-- ARCHITECTURE.md sections: Pattern Overview, Layers, Data Flow, Key Abstractions, Entry Points
-- STRUCTURE.md sections: Directory Layout, Key Locations, Organization
-
-From Agent 3 output, extract:
-- CONVENTIONS.md sections: Code Style, Naming Conventions, Common Patterns, Documentation Style
-- TESTING.md sections: Framework, Structure, Coverage, Tools
-
-From Agent 4 output, extract:
-- CONCERNS.md sections: Technical Debt, Known Issues, Security, Performance, Missing
+read each agent's output file to collect confirmations.
 
-**Handling missing findings:**
-
-If an agent didn't find information for a section, use placeholder:
-- "Not detected" (for infrastructure/tools that may not exist)
-- "Not applicable" (for patterns that don't apply to this codebase)
-- "No significant concerns" (for CONCERNS.md if codebase is clean)
-
-Continue to write_documents.
-</step>
-
-<step name="write_documents">
-Write all 7 codebase documents using templates and agent findings.
-
-**Template filling process:**
-
-For each document:
-
-1. **Read template file** from `~/.config/opencode/get-shit-done/templates/codebase/{name}.md`
-2. **Extract the "File Template" section** - this is the markdown code block containing the actual document structure
-3. **Fill template placeholders** with agent findings:
-   - Replace `[YYYY-MM-DD]` with current date
-   - Replace `[Placeholder text]` with specific findings from agents
-   - If agent found nothing for a section, use appropriate placeholder:
-     - "Not detected" for optional infrastructure
-     - "Not applicable" for patterns that don't fit this codebase
-     - "No significant concerns" for clean codebase areas
-4. **Write to .planning/codebase/{NAME}.md** (uppercase filename)
-
-**Example filling pattern:**
-
-Template placeholder:
-```
-**Primary:**
-- [Language] [Version] - [Where used: e.g., "all application code"]
+**Expected confirmation format from each agent:**
 ```
+## Mapping Complete
 
-Agent finding:
-```
-Found: TypeScript 5.3 used in all .ts files throughout src/
-```
+**Focus:** {focus}
+**Documents written:**
+- `.planning/codebase/{DOC1}.md` ({N} lines)
+- `.planning/codebase/{DOC2}.md` ({N} lines)
 
-Filled result:
-```
-**Primary:**
-- TypeScript 5.3 - All application code
+Ready for orchestrator summary.
 ```
 
-**Document writing order:**
+**What you receive:** Just file paths and line counts. NOT document contents.
 
-1. **STACK.md** (from stack.md template + Agent 1 findings)
-2. **INTEGRATIONS.md** (from integrations.md template + Agent 1 findings)
-3. **ARCHITECTURE.md** (from architecture.md template + Agent 2 findings)
-4. **STRUCTURE.md** (from structure.md template + Agent 2 findings)
-5. **CONVENTIONS.md** (from conventions.md template + Agent 3 findings)
-6. **TESTING.md** (from testing.md template + Agent 3 findings)
-7. **CONCERNS.md** (from concerns.md template + Agent 4 findings)
+If any agent failed, note the failure and continue with successful documents.
 
-After all documents written, continue to verify_output.
+Continue to verify_output.
 </step>
 
 <step name="verify_output">
@@ -349,10 +201,9 @@ wc -l .planning/codebase/*.md
 
 **Verification checklist:**
 - All 7 documents exist
-- No empty documents
-- Templates populated with findings
+- No empty documents (each should have >20 lines)
 
-If any checks fail, report issues to user.
+If any documents missing or empty, note which agents may have failed.
 
 Continue to commit_codebase_map.
 </step>
@@ -382,6 +233,11 @@ Continue to offer_next.
 <step name="offer_next">
 Present completion summary and next steps.
 
+**Get line counts:**
+```bash
+wc -l .planning/codebase/*.md
+```
+
 **Output format:**
 
 ```
@@ -412,7 +268,7 @@ Created .planning/codebase/:
 **Also available:**
 - Re-run mapping: `/gsd-map-codebase`
 - Review specific file: `cat .planning/codebase/STACK.md`
-- Edit any document before proceeding
+- edit any document before proceeding
 
 ---
 ```
@@ -424,11 +280,10 @@ End workflow.
 
 <success_criteria>
 - .planning/codebase/ directory created
-- 4 parallel explore agents spawned with run_in_background=true
-- Agent prompts are specific and actionable
-- TaskOutput used to collect all agent results
-- All 7 codebase documents written using template filling
-- Documents follow template structure with actual findings
+- 4 parallel gsd-codebase-mapper agents spawned with run_in_background=true
+- Agents write documents directly (orchestrator doesn't receive document contents)
+- read agent output files to collect confirmations
+- All 7 codebase documents exist
 - Clear completion summary with line counts
 - User offered clear next steps in GSD style
 </success_criteria>

package/get-shit-done/workflows/resume-project.md

@@ -31,7 +31,7 @@ ls .planning/PROJECT.md 2>/dev/null && echo "Project file exists"
 
 <step name="load_state">
 
-Read and parse STATE.md, then PROJECT.md:
+read and parse STATE.md, then PROJECT.md:
 
 ```bash
 cat .planning/STATE.md
@@ -44,7 +44,7 @@ cat .planning/PROJECT.md
 - **Current Position**: Phase X of Y, Plan A of B, Status
 - **Progress**: Visual progress bar
 - **Recent Decisions**: Key decisions affecting current work
-- **Deferred Issues**: Open items awaiting attention
+- **Pending Todos**: Ideas captured during sessions
 - **Blockers/Concerns**: Issues carried forward
 - **Session Continuity**: Where we left off, any resume files
 
@@ -80,7 +80,7 @@ fi
 **If .continue-here file exists:**
 
 - This is a mid-plan resumption point
-- Read the file for specific resumption context
+- read the file for specific resumption context
 - Flag: "Found mid-plan checkpoint"
 
 **If PLAN without SUMMARY exists:**
@@ -91,7 +91,7 @@ fi
 **If interrupted agent found:**
 
 - Subagent was spawned but session ended before completion
-- Read agent-history.json for task details
+- read agent-history.json for task details
 - Flag: "Found interrupted agent"
   </step>
 
@@ -121,10 +121,10 @@ Present complete project status to user:
     Task: [task description from agent-history.json]
     Interrupted: [timestamp]
 
-    Resume with: /gsd-resume-task
+    Resume with: Task tool (resume parameter with agent ID)
 
-[If deferred issues exist:]
-📋 [N] deferred issues awaiting attention
+[If pending todos exist:]
+📋 [N] pending todos — /gsd-check-todos to review
 
 [If blockers exist:]
 ⚠️  Carried concerns:
@@ -141,7 +141,7 @@ Present complete project status to user:
 Based on project state, determine the most logical next action:
 
 **If interrupted agent exists:**
-→ Primary: Resume interrupted agent (/gsd-resume-task)
+→ Primary: Resume interrupted agent (Task tool with resume parameter)
 → Option: Start fresh (abandon agent work)
 
 **If .continue-here file exists:**
@@ -178,11 +178,9 @@ Present contextual options based on project state:
 What would you like to do?
 
 [Primary action based on state - e.g.:]
-1. Resume interrupted agent (/gsd-resume-task) [if interrupted agent found]
+1. Resume interrupted agent [if interrupted agent found]
    OR
-1. Resume from checkpoint (/gsd-execute-plan .planning/phases/XX-name/.continue-here-02-01.md)
-   OR
-1. Execute next plan (/gsd-execute-plan .planning/phases/XX-name/02-02-PLAN.md)
+1. Execute phase (/gsd-execute-phase {phase})
    OR
 1. Discuss Phase 3 context (/gsd-discuss-phase 3) [if CONTEXT.md missing]
    OR
@@ -190,7 +188,7 @@ What would you like to do?
 
 [Secondary options:]
 2. Review current phase status
-3. Check deferred issues ([N] open)
+3. Check pending todos ([N] pending)
 4. Review brief alignment
 5. Something else
 ```
@@ -217,7 +215,7 @@ Based on user selection, route to appropriate workflow:
 
   **{phase}-{plan}: [Plan Name]** — [objective from PLAN.md]
 
-  `/gsd-execute-plan [path]`
+  `/gsd-execute-phase {phase}`
 
   *`/new` first → fresh context window*
 
@@ -244,8 +242,8 @@ Based on user selection, route to appropriate workflow:
   ---
   ```
 - **Transition** → ./transition.md
-- **Review issues** → Read ISSUES.md, present summary
-- **Review alignment** → Read PROJECT.md, compare to current state
+- **Check todos** → read .planning/todos/pending/, present summary
+- **Review alignment** → read PROJECT.md, compare to current state
 - **Something else** → Ask what they need
 </step>
 
@@ -272,10 +270,10 @@ If STATE.md is missing but other artifacts exist:
 
 "STATE.md missing. Reconstructing from artifacts..."
 
-1. Read PROJECT.md → Extract "What This Is" and Core Value
-2. Read ROADMAP.md → Determine phases, find current position
-3. Scan \*-SUMMARY.md files → Extract decisions, issues, concerns
-4. Read ISSUES.md → Count deferred issues
+1. read PROJECT.md → Extract "What This Is" and Core Value
+2. read ROADMAP.md → Determine phases, find current position
+3. Scan \*-SUMMARY.md files → Extract decisions, concerns
+4. Count pending todos in .planning/todos/pending/
 5. Check for .continue-here files → Session continuity
 
 Reconstruct and write STATE.md, then proceed normally.

package/get-shit-done/workflows/transition.md

@@ -1,6 +1,6 @@
 <required_reading>
 
-**Read these files NOW:**
+**read these files NOW:**
 
 1. `.planning/STATE.md`
 2. `.planning/PROJECT.md`
@@ -165,7 +165,7 @@ The `completed/` subfolder pattern from create-meta-prompts handles archival.
 
 Evolve PROJECT.md to reflect learnings from completed phase.
 
-**Read phase summaries:**
+**read phase summaries:**
 
 ```bash
 cat .planning/phases/XX-current/*-SUMMARY.md
@@ -342,12 +342,6 @@ Review and update Accumulated Context section in STATE.md.
 - If still relevant for future: Keep with "Phase X" prefix
 - Add any new concerns from completed phase's summaries
 
-**Deferred Issues:**
-
-- Count open issues in ISSUES.md
-- Update count: "[N] open issues — see ISSUES.md"
-- If many accumulated, note: "Consider addressing ISS-XXX, ISS-YYY in next phase"
-
 **Example:**
 
 Before:
@@ -357,10 +351,6 @@ Before:
 
 - ⚠️ [Phase 1] Database schema not indexed for common queries
 - ⚠️ [Phase 2] WebSocket reconnection behavior on flaky networks unknown
-
-### Deferred Issues
-
-- ISS-001: Rate limiting on sync endpoint (Phase 2) — Medium
 ```
 
 After (if database indexing was addressed in Phase 2):
@@ -369,11 +359,6 @@ After (if database indexing was addressed in Phase 2):
 ### Blockers/Concerns
 
 - ⚠️ [Phase 2] WebSocket reconnection behavior on flaky networks unknown
-
-### Deferred Issues
-
-- ISS-001: Rate limiting on sync endpoint (Phase 2) — Medium
-- ISS-002: Better sync error messages (Phase 2) — Quick
 ```
 
 **Step complete when:**
@@ -382,7 +367,6 @@ After (if database indexing was addressed in Phase 2):
 - [ ] Resolved blockers removed from list
 - [ ] Unresolved blockers kept with phase prefix
 - [ ] New concerns from completed phase added
-- [ ] Deferred issues count updated
 
 </step>
 
@@ -410,9 +394,9 @@ Resume file: None
 
 **MANDATORY: Verify milestone status before presenting next steps.**
 
-**Step 1: Read ROADMAP.md and identify phases in current milestone**
+**Step 1: read ROADMAP.md and identify phases in current milestone**
 
-Read the ROADMAP.md file and extract:
+read the ROADMAP.md file and extract:
 1. Current phase number (the phase just transitioned from)
 2. All phase numbers in the current milestone section
 
@@ -435,7 +419,7 @@ State: "Current phase is {X}. Milestone has {N} phases (highest: {Y})."
 
 **Route A: More phases remain in milestone**
 
-Read ROADMAP.md to get the next phase's name and goal.
+read ROADMAP.md to get the next phase's name and goal.
 
 **If next phase exists:**
 
@@ -449,7 +433,7 @@ Next: Phase [X+1] — [Name]
 ⚡ Auto-continuing: Plan Phase [X+1] in detail
 ```
 
-Exit skill and invoke [removed - use /command syntax]("/gsd-plan-phase [X+1]")
+Exit skill and invoke "/gsd-plan-phase [X+1]"
 
 </if>
 
@@ -494,7 +478,7 @@ Phase {X} marked complete.
 ⚡ Auto-continuing: Complete milestone and archive
 ```
 
-Exit skill and invoke [removed - use /command syntax]("/gsd-complete-milestone {version}")
+Exit skill and invoke "/gsd-complete-milestone {version}"
 
 </if>