ragarciaruben 1.20.19 → 1.20.21

package/{.github/copilot-context/prompts/map-codebase.prompt.md → get-shit-done/templates/opencode/commands/map-codebase.md}

@@ -1,17 +1,11 @@
 ---
-name: map-codebase
 description: Analyze the codebase and generate structured context documents in .planning/codebase/
-mode: agent
-tools:
-  - editFiles
-  - runInTerminal
-  - search
-  - fetch
+agent: executor
 ---
 
 # Map Codebase
 
-Analyze this codebase thoroughly and generate 7 structured context documents in `.planning/codebase/`. These documents will be used by Copilot on every future request to understand the project's architecture, conventions, and constraints.
+Analyze this codebase thoroughly and generate 7 structured context documents in `.planning/codebase/`. These documents will be used on every future request to understand the project's architecture, conventions, and constraints.
 
 ## Process
 
@@ -23,22 +17,17 @@ Work through 4 focus areas in sequence. For each area, explore the codebase usin
 
 **Explore:**
 ```bash
-# Package manifests
 cat package.json 2>/dev/null | head -100
 cat requirements.txt 2>/dev/null || cat pyproject.toml 2>/dev/null | head -50
 cat go.mod 2>/dev/null | head -30
-
-# Config files (list only — NEVER read .env contents)
 ls -la *.config.* tsconfig.json .nvmrc .python-version 2>/dev/null
-ls .env* 2>/dev/null   # Note existence only
-
-# Find external integrations
+ls .env* 2>/dev/null   # Note existence only — NEVER read .env contents
 grep -r "import.*stripe\|import.*supabase\|import.*aws\|import.*prisma\|import.*redis\|import.*sendgrid\|import.*twilio\|import.*openai" src/ --include="*.ts" --include="*.py" 2>/dev/null | head -40
 ```
 
 **Write `.planning/codebase/STACK.md`** with: runtime, frameworks, key dependencies table, dev toolchain, infrastructure, environment variables.
 
-**Write `.planning/codebase/INTEGRATIONS.md`** with: a section per external service including SDK used, config file location, required env vars, key operations.
+**Write `.planning/codebase/INTEGRATIONS.md`** with: a section per external service.
 
 ---
 
@@ -46,19 +35,14 @@ grep -r "import.*stripe\|import.*supabase\|import.*aws\|import.*prisma\|import.*
 
 **Explore:**
 ```bash
-# Directory structure
-find . -type d -not -path '*/node_modules/*' -not -path '*/.git/*' -not -path '*/.planning/*' -not -path '*/.github/*' | sort | head -60
-
-# Entry points
+find . -type d -not -path '*/node_modules/*' -not -path '*/.git/*' -not -path '*/.planning/*' -not -path '*/.github/*' -not -path '*/.opencode/*' | sort | head -60
 ls src/index.* src/main.* src/app.* src/server.* app/page.* 2>/dev/null
-
-# Understanding layer imports
 grep -r "^import\|^from" src/ --include="*.ts" --include="*.py" 2>/dev/null | head -80
 ```
 
-**Write `.planning/codebase/ARCHITECTURE.md`** with: architectural style + rationale, layer diagram with file paths, data flow example (trace a typical request end-to-end), key abstractions table, entry points table, cross-cutting concerns (error handling, logging, auth, validation).
+**Write `.planning/codebase/ARCHITECTURE.md`** with: architectural style, layer diagram, data flow example, key abstractions, entry points, cross-cutting concerns.
 
-**Write `.planning/codebase/STRUCTURE.md`** with: root layout, source tree, and most importantly a **"Where to Put New Code"** table that tells exactly which directory and naming convention to use for each type of file (routes, services, repositories, models, utils, tests, components, etc.).
+**Write `.planning/codebase/STRUCTURE.md`** with: root layout, source tree, and a **"Where to Put New Code"** table.
 
 ---
 
@@ -66,22 +50,17 @@ grep -r "^import\|^from" src/ --include="*.ts" --include="*.py" 2>/dev/null | he
 
 **Explore:**
 ```bash
-# Formatting/linting config
 cat .prettierrc .eslintrc.js .eslintrc.json biome.json 2>/dev/null | head -60
 cat pyproject.toml 2>/dev/null | grep -A 20 "\[tool\."
-
-# Test framework
 ls jest.config.* vitest.config.* pytest.ini setup.cfg 2>/dev/null
 find . -name "*.test.*" -o -name "*.spec.*" | grep -v node_modules | head -20
-
-# Look at real code for patterns
 find src/ -name "*.ts" -not -name "*.test.*" 2>/dev/null | head -5 | xargs head -40 2>/dev/null
 find tests/ -name "*.test.*" 2>/dev/null | head -3 | xargs head -60 2>/dev/null
 ```
 
-**Write `.planning/codebase/CONVENTIONS.md`** — be prescriptive ("Use X" not "X is used"). Include: language/formatting rules, naming conventions table, import ordering, error handling patterns, function patterns, TypeScript specifics, comment style. Include real code examples from the codebase.
+**Write `.planning/codebase/CONVENTIONS.md`** — be prescriptive. Include: naming conventions, import ordering, error handling, function patterns, comment style. Include real code examples.
 
-**Write `.planning/codebase/TESTING.md`** with: test framework and run commands, file organization, test structure pattern with real example, mocking strategy, test data approach (factories), integration test setup, what to test and what NOT to test.
+**Write `.planning/codebase/TESTING.md`** with: test framework, run commands, file organization, mocking strategy, what to test and what NOT to test.
 
 ---
 
@@ -89,27 +68,19 @@ find tests/ -name "*.test.*" 2>/dev/null | head -3 | xargs head -60 2>/dev/null
 
 **Explore:**
 ```bash
-# TODO/FIXME/HACK comments
 grep -rn "TODO\|FIXME\|HACK\|XXX\|TEMP\|@deprecated" src/ --include="*.ts" --include="*.py" 2>/dev/null | head -40
-
-# Potential issues
 grep -rn "any\b\|@ts-ignore\|@ts-nocheck\|eslint-disable\|# type: ignore\|# noqa" src/ --include="*.ts" --include="*.py" 2>/dev/null | head -30
-
-# Security patterns
 grep -rn "eval\|innerHTML\|dangerouslySetInnerHTML\|exec\|shell=True" src/ --include="*.ts" --include="*.py" 2>/dev/null | head -20
-
-# Large/complex files
 find src/ -name "*.ts" -o -name "*.py" 2>/dev/null | xargs wc -l 2>/dev/null | sort -rn | head -15
 ```
 
-**Write `.planning/codebase/CONCERNS.md`** with: health summary table (critical/high/medium counts), critical issues section (with file paths, impact, root cause, fix approach), high-priority debt, fragile areas table with safe-approach guidance, security notes, performance bottlenecks, scaling limits.
+**Write `.planning/codebase/CONCERNS.md`** with: health summary, critical issues, fragile areas, security notes, performance bottlenecks.
 
 ---
 
 ## Completion
 
-After all 7 files are written, update `.github/copilot-instructions.md`:
+After all 7 files are written, update `AGENTS.md`:
 - Fill in the "What This Project Is" section from what you learned
-- Keep it to 2-3 sentences describing what the product does
 
-Then confirm: "Codebase mapping complete. Generated 7 documents in `.planning/codebase/`. Use `/sync-instructions` to update the Copilot instructions digest."
+Then confirm: "Codebase mapping complete. Generated 7 documents in `.planning/codebase/`. Use `/sync-instructions` to update the instructions digest."

package/{.github/copilot-context/prompts/new-project.prompt.md → get-shit-done/templates/opencode/commands/new-project.md}

@@ -1,16 +1,11 @@
 ---
-name: new-project
 description: Initialize .planning/ documentation for a new or existing project — creates PROJECT.md, REQUIREMENTS.md, ROADMAP.md, and STATE.md
-mode: agent
-tools:
-  - editFiles
-  - search
-  - jira/*
+agent: executor
 ---
 
 # New Project Initialization
 
-Initialize the `.planning/` documentation structure for this project. This generates the source-of-truth documents that power all other Copilot context.
+Initialize the `.planning/` documentation structure for this project. This generates the source-of-truth documents that power all other context.
 
 ## Step 1: Gather Project Context
 
@@ -31,12 +26,8 @@ If the user can't answer some questions, use reasonable defaults and note them a
 
 If the user chose Jira as the requirements source:
 
-1. **Discover the board/sprint:** Use `jira_get_agile_boards` to find the board, then `jira_get_sprints_from_board` to find active/future sprints
-2. **Fetch tickets:** Use the appropriate tool based on what the user provided:
-   - Project key → `jira_get_project_issues` or `jira_search` with JQL `project = PROJ AND status != Done`
-   - Sprint → `jira_get_sprint_issues`
-   - JQL query → `jira_search` with the user's query
-   - Specific tickets → `jira_get_issue` for each
+1. **Discover the board/sprint:** Find the board, then find active/future sprints
+2. **Fetch tickets:** Use the appropriate method based on what the user provided
 3. **Extract from each ticket:**
    - Title and description → becomes a requirement
    - Acceptance criteria → becomes success criteria
@@ -47,59 +38,53 @@ If the user chose Jira as the requirements source:
 
 If Jira is not used, skip to Step 3 using manual requirements from the conversation.
 
-## Step 2: Create PROJECT.md
+## Step 3: Create PROJECT.md
 
 Write `.planning/PROJECT.md` with:
 - **What This Is:** User's description of the project
 - **Core Value:** Single sentence of what must always work
 - **Requirements > Active:** List of v1 requirements as checkboxes
-- **Requirements > Out of Scope:** Anything explicitly excluded (infer 2-3 common exclusions from the project type)
+- **Requirements > Out of Scope:** Anything explicitly excluded
 - **Context:** Background from the conversation
 - **Constraints:** What the user listed + inferred constraints
 
-## Step 3: Create REQUIREMENTS.md
+## Step 4: Create REQUIREMENTS.md
 
 Extract requirements into `.planning/REQUIREMENTS.md`:
 - Assign IDs: `[CATEGORY]-[NN]` (e.g., AUTH-01, CORE-01, UI-01)
 - **If from Jira:** include the Jira ticket ID alongside the requirement ID (e.g., `AUTH-01 (PROJ-42)`)
 - Group by logical category (Authentication, Core Features, UI, etc.)
 - v2 requirements: anything out of scope for now but likely future
-- Traceability table: map each requirement to its source (Jira ticket or manual) and Phase (TBD until roadmap)
+- Traceability table: map each requirement to its source and Phase (TBD until roadmap)
 
-## Step 4: Create ROADMAP.md
+## Step 5: Create ROADMAP.md
 
 Design a logical phase sequence in `.planning/ROADMAP.md`:
 - **If from Jira:** group related tickets into phases (epics → phase groups, stories → plans within a phase)
 - **If manual:** group related requirements into phases
 - Each phase delivers a user-visible increment
 - Earlier phases enable later phases (dependency chain)
-- Phase names should be clear and action-oriented (e.g., "Authentication & User Management", "Core Feature MVP")
-- Each phase includes:
-  - Goal and dependencies
-  - Requirements covered (with Jira ticket IDs if applicable)
-  - 2-4 success criteria (from Jira acceptance criteria where available)
-  - Source: `Jira: PROJ-42, PROJ-43` or `Manual`
-  - Planned plan count (TBD is fine)
+- Phase names should be clear and action-oriented
+- Each phase includes: Goal, dependencies, requirements covered, 2-4 success criteria, source
 - Typically 4-8 phases for a standard project
 - Order by: Jira priority → dependency chain → logical progression
 
-## Step 5: Create STATE.md
+## Step 6: Create STATE.md
 
 Initialize `.planning/STATE.md`:
 - Phase: 1 of [N]
 - Status: Ready to plan
 - Progress: 0%
 - Last activity: today's date + "Project initialized"
-- All metrics at zero
 
-## Step 6: Update copilot-instructions.md
+## Step 7: Update AGENTS.md
 
-Update `.github/copilot-instructions.md`:
+Update `AGENTS.md`:
 - Fill in "What This Project Is" with the 2-3 sentence description
 - Fill in "Core value"
 - Set "Phase: 1 of [N] — [Phase Name]"
 - Set "Status: Ready to plan"
-- Fill in "Active Constraints" from the constraints list
+- Fill in "Active Constraints"
 
 ## Completion
 
@@ -107,13 +92,12 @@ Print a summary:
 ```
 ✅ Project initialized: [Project Name]
    .planning/PROJECT.md      — requirements + decisions
-   .planning/REQUIREMENTS.md — [N] requirements with IDs [+ N from Jira]
+   .planning/REQUIREMENTS.md — [N] requirements with IDs
    .planning/ROADMAP.md      — [N] phases
    .planning/STATE.md        — ready to plan
-   [Jira source: PROJECT / Sprint NAME — N tickets imported]
 
 Next steps:
   1. Run /map-codebase (if existing codebase)
-  2. Run @Planner "Plan phase 1" to plan the first phase
+  2. Run /plan-phase 1 to plan the first phase
   3. Run /redefine-roadmap if priorities change later
 ```

package/{.github/copilot-context/prompts/pause-work.prompt.md → get-shit-done/templates/opencode/commands/pause-work.md}

@@ -1,11 +1,6 @@
 ---
-name: pause-work
 description: Save current session state so work can be resumed in a new session — writes .planning/continue-here.md
-mode: agent
-tools:
-  - editFiles
-  - runInTerminal
-  - search
+agent: executor
 ---
 
 # Pause Work
@@ -17,14 +12,9 @@ Save the current session state to `.planning/continue-here.md` so the next sessi
 Gather current state information:
 
 ```bash
-# Last few commits
 git log --oneline -5
-
-# Uncommitted changes
 git status
 git diff --stat HEAD
-
-# Test status
 npm test 2>&1 | tail -10
 ```
 
@@ -33,9 +23,9 @@ Read `.planning/STATE.md` for project-level context.
 ## Step 2: Document Current State
 
 Think through:
-- What was the last **completed** action? (Be concrete — a test passing, a file created, a PR merged)
+- What was the last **completed** action?
 - What work is **in progress** and where exactly did it stop?
-- What **remains** in the current plan? What comes after?
+- What **remains** in the current plan?
 - What **decisions** were made this session?
 - Are there any **blockers** or watch-outs for the next session?
 - What is the **exact next action** to resume?
@@ -55,9 +45,7 @@ Write `.planning/continue-here.md`:
 
 ## What Was Just Completed
 
-[Concrete description of the last completed action]
-
-- ✅ [Completed item 1 — file created / test passing / feature shipped]
+- ✅ [Completed item 1]
 - ✅ [Completed item 2]
 
 ## What Remains
@@ -71,16 +59,15 @@ Upcoming plans:
 
 ## Decisions Made This Session
 
-- [Decision and rationale — lock these in]
 - [Decision and rationale]
 
 ## Blockers / Watch-Outs
 
-- [Any issue the next session needs to know before touching code]
+- [Any issue the next session needs to know]
 
 ## Exact Next Action
 
-**Resume by doing:** [Single, concrete action — e.g., "Open `src/services/user.service.ts` and implement the `sendWelcomeEmail()` call at line ~45, then run `npm test` to verify"]
+**Resume by doing:** [Single, concrete action]
 
 ---
 *Saved: [timestamp]*

package/{.github/copilot-context/prompts/plan-phase.prompt.md → get-shit-done/templates/opencode/commands/plan-phase.md}

@@ -1,11 +1,6 @@
 ---
-name: plan-phase
 description: Plan implementation for a roadmap phase — produces a detailed, executable step-by-step plan
-mode: agent
-tools:
-  - editFiles
-  - search
-  - runInTerminal
+agent: planner
 ---
 
 # Plan Phase
@@ -37,10 +32,7 @@ Load relevant codebase docs based on the phase type:
 
 Before planning, explore the codebase to understand the current state:
 ```bash
-# Find existing code related to the phase domain
 grep -rn "[relevant terms]" src/ --include="*.ts" 2>/dev/null | head -30
-
-# Check existing file structure for the area
 ls -la src/[relevant-directory]/ 2>/dev/null
 ```
 
@@ -91,47 +83,32 @@ status: ready
 **Implementation:**
 [Specifics — data structures, algorithms, API contracts, patterns to follow]
 
-### 2. [Step name]
-[etc.]
-
 ### N. Tests
-[Specific test cases to write — description of each scenario]
+[Specific test cases to write]
 
 ## Success Criteria
 - [ ] [Observable behavior that proves this plan is complete]
-- [ ] [Observable behavior]
 - [ ] All tests pass (`npm test`)
 - [ ] No TypeScript errors (`tsc --noEmit`)
 ```
 
-If the phase requires multiple plans, create `[NN]-02-[name].md`, `[NN]-03-[name].md`, etc.
+If the phase requires multiple plans, create `[NN]-02-[name].md`, etc.
 
 ## Step 5: Update ROADMAP.md
 
-Update the plan list in `.planning/ROADMAP.md` for this phase:
-```
-Plans:
-- [ ] [NN]-01: [Brief description]
-- [ ] [NN]-02: [Brief description]
-```
+Update the plan list in `.planning/ROADMAP.md` for this phase.
 
 ## Step 6: Update STATE.md
 
 Update `.planning/STATE.md`:
 - Status: `Ready to execute`
 - Current focus: this phase
-- Note the key decisions made during planning under Accumulated Context
 
 ## Completion
 
-Print a summary:
 ```
 ✅ Phase [N] planned: [Phase Name]
    [N] plans created in .planning/phases/[NN]-[name]/
 
-Plans:
-  [NN]-01: [Name] — [brief description]
-  [NN]-02: [Name] — [brief description]
-
 Ready to execute. Run /execute-phase [N] to start implementation.
 ```

package/{.github/copilot-context/prompts/progress.prompt.md → get-shit-done/templates/opencode/commands/progress.md}

@@ -1,9 +1,6 @@
 ---
-name: progress
 description: Show current project progress — phase status, completion percentage, and what's next
-mode: ask
-tools:
-  - search
+agent: planner
 ---
 
 # Show Progress

package/{.github/copilot-context/prompts/redefine-roadmap.prompt.md → get-shit-done/templates/opencode/commands/redefine-roadmap.md}

@@ -1,10 +1,6 @@
 ---
 description: "Restructure your project roadmap — reorder, regroup, reprioritize, or rebuild phases from scratch"
-mode: agent
-tools:
-  - editFiles
-  - search
-  - jira/*
+agent: executor
 ---
 
 # Redefine Roadmap
@@ -23,7 +19,7 @@ Restructure `.planning/ROADMAP.md` — reorder phases, reprioritize, split/merge
 
 Ask the user what kind of restructuring they want:
 
-1. **Reorder** — "Move phase 3 before phase 2", "Priority changed, X is now urgent"
+1. **Reorder** — "Move phase 3 before phase 2"
 2. **Split** — "Phase 2 is too big, break it into smaller phases"
 3. **Merge** — "Phases 3 and 4 are related, combine them"
 4. **Rebuild from Jira** — "Forget the current roadmap, rebuild from sprint [X]"
@@ -34,14 +30,14 @@ Ask the user what kind of restructuring they want:
 
 ### Step 1: Load current state
 
-Read these files:
+Read:
 - `.planning/ROADMAP.md` — current phase structure
 - `.planning/STATE.md` — what phase is in progress, what's completed
 - `.planning/REQUIREMENTS.md` — which requirements are mapped to which phases
 
 ### Step 2: Understand the change
 
-Based on user input, determine:
+Determine:
 - Which phases are **locked** (completed — never modify these)
 - Which phases are **in progress** (warn before modifying)
 - Which phases are **changeable** (not started)
@@ -49,12 +45,7 @@ Based on user input, determine:
 
 ### Step 3: If rebuilding from Jira
 
-Use Jira tools to fetch the new source of truth:
-- `mcp_jira_jira_search` — flexible JQL queries
-- `mcp_jira_jira_get_issue` — individual ticket details
-- `mcp_jira_jira_get_sprint_issues` — sprint-based planning
-
-Map tickets to new phases (same logic as `/sync-jira`).
+Use Jira MCP tools to fetch the new source of truth. Map tickets to new phases.
 
 ### Step 4: Apply changes
 
@@ -65,16 +56,12 @@ Map tickets to new phases (same logic as `/sync-jira`).
 
 ### Step 5: Show diff summary
 
-Display:
-- **Before:** old phase list with statuses
-- **After:** new phase list
-- **Changes:** what was reordered, split, merged, added, or removed
-- **Warnings:** any completed work that was affected, any in-progress phases that moved
+Display before/after comparison, changes made, and any warnings.
 
 ## Safety Rules
 
-- **NEVER modify completed phases** — they are locked and represent shipped work
+- **NEVER modify completed phases** — they are locked
 - **Warn before modifying in-progress phases** — ask for confirmation
-- **Preserve Jira ticket IDs** — maintain traceability through restructuring
+- **Preserve Jira ticket IDs** — maintain traceability
 - **Back up before major restructuring** — suggest committing current state first
 - Always show the before/after comparison before writing changes

package/get-shit-done/templates/opencode/commands/refine-backlog.md

@@ -0,0 +1,77 @@
+---
+description: "Review and improve existing Jira tickets — add acceptance criteria, clarify descriptions, fix structure"
+agent: product-owner
+---
+
+# Refine Backlog
+
+Review existing Jira tickets and improve their quality: add missing acceptance criteria, clarify vague descriptions, standardize structure, and identify gaps.
+
+## What You Need
+
+The user should provide ONE of:
+- **Specific ticket IDs** (e.g., `PROJ-101, PROJ-102`)
+- **A JQL query** (e.g., `project = PROJ AND status = "To Do" AND "Acceptance Criteria" is EMPTY`)
+- **A project key** — review all backlog items
+- **A sprint** — review tickets in the current/next sprint
+
+If none provided, ask: "Which tickets or project should I review?"
+
+## Workflow
+
+### Step 1: Fetch tickets
+
+Read the specified tickets from Jira. For each ticket, evaluate:
+
+1. **Title quality** — Is it clear and action-oriented? Or vague like "Fix stuff"?
+2. **Description completeness** — Does it explain what and why?
+3. **Acceptance criteria** — Are they specific, testable, measurable? Or missing/vague?
+4. **Type correctness** — Is a task really a task, or should it be a story/bug?
+5. **Priority** — Is it set? Does it make sense relative to other tickets?
+6. **Links** — Are dependencies and relationships captured?
+7. **Labels/Components** — Are they consistent with the project's conventions?
+
+### Step 2: Present findings
+
+For each ticket that needs improvement, show:
+
+```
+PROJ-101: "Fix login" ⚠️ Needs work
+  Current:  No AC, vague title, no description
+  Proposed:
+    Title: "Fix login timeout causing session expiry after 5 minutes"
+    Description: Users report being logged out after 5 min of inactivity...
+    AC:
+      - [ ] Session persists for configured timeout period (default 30min)
+      - [ ] Refresh token extends session on activity
+      - [ ] User sees warning 2 min before expiry
+    Priority: High (was: unset)
+
+PROJ-102: "User dashboard" ✅ Looks good
+  (no changes needed)
+
+Apply changes to [N] tickets? (yes/no/edit)
+```
+
+### Step 3: Apply (only after confirmation)
+
+- Update each approved ticket
+- Report what was changed
+
+## Refinement Checklist
+
+For every ticket, ensure:
+- [ ] Title is clear, specific, and action-oriented
+- [ ] Description explains the what and why
+- [ ] At least 2-3 measurable acceptance criteria
+- [ ] Priority is set
+- [ ] Type is correct (story/task/bug/epic)
+- [ ] Dependencies are linked
+- [ ] No duplicates exist in the backlog
+
+## Important
+
+- **NEVER modify tickets that are In Progress or later** — warn and skip
+- **Always show before/after** — never update silently
+- Don't change ticket scope — only improve clarity and structure
+- If a ticket is too big, suggest splitting it (use `/break-down-epic`)

package/{.github/copilot-context/prompts/resume-work.prompt.md → get-shit-done/templates/opencode/commands/resume-work.md}

@@ -1,10 +1,6 @@
 ---
-name: resume-work
 description: Resume work from a saved session state — reads .planning/continue-here.md and .planning/STATE.md to orient the next session
-mode: ask
-tools:
-  - search
-  - runInTerminal
+agent: planner
 ---
 
 # Resume Work
@@ -23,12 +19,9 @@ If `.planning/continue-here.md` does not exist, fall back to STATE.md and ROADMA
 ## Step 2: Verify Environment
 
 ```bash
-# Confirm current git state
 git status
 git log --oneline -3
 git branch --show-current
-
-# Quick test health check
 npm test 2>&1 | tail -15
 ```
 
@@ -36,8 +29,6 @@ Note any unexpected test failures or uncommitted changes.
 
 ## Step 3: Present Resume Summary
 
-Format the context summary clearly:
-
 ```
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
   Resuming: [Project Name]
@@ -50,7 +41,6 @@ Where We Left Off
 
 Last Completed
   ✅ [Last completed item]
-  ✅ [Item before that]
 
 What Remains (current plan)
   ◻ [Next task]
@@ -58,10 +48,9 @@ What Remains (current plan)
 
 Decisions Locked In
   • [Decision 1]
-  • [Decision 2]
 
 Watch-Outs
-  ⚠️ [Any blocker or fragile area to be aware of]
+  ⚠️ [Any blocker or fragile area]
 
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 

package/get-shit-done/templates/opencode/commands/set-profile.md

@@ -0,0 +1,65 @@
+---
+description: Switch the AI model used by all GSD agents (quality / balanced / budget) or set per-agent overrides
+agent: executor
+---
+
+# Set Model Profile
+
+Switch the model used by the Planner, Executor, and Verifier agents. This edits the `model:` field in all agent files in `.opencode/agents/` and saves your choice to `.planning/config.json`.
+
+## Profile Table
+
+| Profile | Planner | Executor | Verifier | Best for |
+|---------|---------|----------|----------|----------|
+| `quality` | anthropic/claude-opus-4 | anthropic/claude-opus-4 | anthropic/claude-sonnet-4 | Critical architecture, max reasoning |
+| `balanced` | anthropic/claude-sonnet-4 | anthropic/claude-sonnet-4 | anthropic/claude-sonnet-4 | Normal development (default) |
+| `budget` | openai/gpt-4.1 | openai/gpt-4.1 | openai/gpt-4.1-mini | High-volume, cost-sensitive work |
+| `gpt` | openai/gpt-4.1 | openai/gpt-4.1 | openai/gpt-4.1 | Prefer OpenAI models throughout |
+
+## Steps
+
+1. **Read current config** — load `.planning/config.json` and note the current `model_profile` value.
+
+2. **Ask the user** which profile they want (quality / balanced / budget / gpt), or if they want a per-agent override.
+
+3. **Apply the chosen profile** — update the `model:` field in ALL of the following agent files:
+   - `.opencode/agents/planner.md`
+   - `.opencode/agents/executor.md`
+   - `.opencode/agents/verifier.md`
+
+   Use this mapping per agent:
+
+   | Agent file | quality | balanced | budget | gpt |
+   |------------|---------|----------|--------|-----|
+   | planner.md | anthropic/claude-opus-4 | anthropic/claude-sonnet-4 | openai/gpt-4.1 | openai/gpt-4.1 |
+   | executor.md | anthropic/claude-opus-4 | anthropic/claude-sonnet-4 | openai/gpt-4.1 | openai/gpt-4.1 |
+   | verifier.md | anthropic/claude-sonnet-4 | anthropic/claude-sonnet-4 | openai/gpt-4.1-mini | openai/gpt-4.1 |
+
+   The line to change looks like:
+   ```
+   model: anthropic/claude-sonnet-4
+   ```
+   Change only that line in the frontmatter block (between the `---` delimiters).
+
+4. **Also update `opencode.json`** — set the top-level `model` field to match the executor's model.
+
+5. **Save to config** — update `.planning/config.json`:
+   - Set `"model_profile"` to the chosen profile name
+   - If they set overrides, add them to `"model_overrides"`
+
+6. **Confirm** — report the final state:
+   ```
+   Profile: balanced
+   Planner  → anthropic/claude-sonnet-4
+   Executor → anthropic/claude-sonnet-4
+   Verifier → anthropic/claude-sonnet-4
+   ```
+
+## Available model IDs (OpenCode format: provider/model)
+
+- `anthropic/claude-opus-4` — Claude Opus 4 (most capable)
+- `anthropic/claude-sonnet-4` — Claude Sonnet 4 (fast + smart)
+- `openai/gpt-4.1` — GPT-4.1
+- `openai/gpt-4.1-mini` — GPT-4.1 Mini (fastest/cheapest)
+- `openai/o3` — OpenAI o3 (reasoning)
+- `google/gemini-2.5-pro` — Gemini 2.5 Pro