liteagents 2.24.1 → 3.5.0

package/packages/droid/droids/1-create-prd.md

@@ -1,7 +1,6 @@
 ---
 name: 1-create-prd
-description: Create PRDs through structured discovery
-when_to_use: Define Scope - use to clearly outline what needs to be built with a Product Requirement Document (PRD)
+description: Create PRDs through structured discovery. Define Scope - use to clearly outline what needs to be built with a Product Requirement Document (PRD)
 model: inherit
 tools: ["Read", "LS", "Grep", "Glob", "Create", "Edit", "MultiEdit", "ApplyPatch", "Execute", "WebSearch", "FetchUrl", "mcp"]
 ---
@@ -168,3 +167,8 @@ B) Proceed to task generation
 - [ ] Asked essential questions (max 2 rounds, max 10 total)?
 - [ ] Waited for user answers (didn't assume)?
 - [ ] Remaining unknowns moved to Open Questions?
+- [ ] PRD focuses on what/why, not how?
+- [ ] Requirements specific and actionable?
+- [ ] Removed redundancy and bloat?
+- [ ] Noted constraints without expanding into architecture?
+- [ ] Non-goals stated (min 2-3)?

package/packages/droid/droids/2-generate-tasks.md

@@ -1,7 +1,6 @@
 ---
 name: 2-generate-tasks
-description: Convert PRDs into development task lists
-when_to_use: Detailed Planning - use to break down the PRD into a granular, actionable task list
+description: Convert PRDs into development task lists. Detailed Planning - use to break down the PRD into a granular, actionable task list
 model: inherit
 tools: ["Read", "LS", "Grep", "Glob", "Create", "Edit", "MultiEdit", "ApplyPatch", "Execute", "WebSearch", "FetchUrl", "mcp"]
 ---

package/packages/droid/droids/3-process-task-list.md

@@ -1,7 +1,6 @@
 ---
 name: 3-process-task-list
-description: Execute task lists with sequential commits
-when_to_use: Iterative Implementation - use to guide the AI to tackle one task at a time, allowing you to review and approve each change
+description: Execute task lists with sequential commits. Iterative Implementation - use to guide the AI to tackle one task at a time, allowing you to review and approve each change
 model: inherit
 tools: ["Read", "LS", "Grep", "Glob", "Create", "Edit", "MultiEdit", "ApplyPatch", "Execute", "WebSearch", "FetchUrl", "mcp"]
 ---

package/packages/droid/droids/code-developer.md

@@ -1,7 +1,6 @@
 ---
 name: code-developer
-description: Implement code, debug, refactor, optimize
-when_to_use: Use for code implementation, debugging, refactoring, optimization, and development best practices
+description: Implement code, debug, refactor, optimize. Use for code implementation, debugging, refactoring, optimization, and development best practices
 model: inherit
 tools: ["Read", "LS", "Grep", "Glob", "Create", "Edit", "MultiEdit", "ApplyPatch", "Execute", "WebSearch", "FetchUrl", "mcp"]
 ---
@@ -37,29 +36,26 @@ digraph CodeDeveloper {
   work_type [label="Work type?", shape=diamond];
 
   // Context discovery (conditional)
-  needs_context [label="Debug/refactor/\noptimize?", shape=diamond];
+  needs_context [label="Debug or\nrefactor?", shape=diamond];
   context_discovery [label="Context Discovery\n(search related code,\ndeps, usages)", fillcolor=lightyellow];
 
   // Debug path
-  use_debug [label="Use /debug-method\nor /trace-back"];
+  use_debug [label="Use /root-cause"];
 
   // Refactor path
   use_refactor [label="Use /refactor"];
 
-  // Optimize path
-  use_optimize [label="Use /optimize"];
-
   // Implement path
   implement [label="Implement changes"];
 
   // Conditional testing
   tdd_needed [label="TDD specified\nor tests needed?", shape=diamond];
-  use_tdd [label="Use /tdd-flow\nor /test-generate"];
+  use_tdd [label="Use /test-generate"];
 
   // Validation
   run_validations [label="Run validations\n(lint, build, tests)"];
   validations_pass [label="Pass?", shape=diamond];
-  fix_issues [label="Fix issues\n(use /debug-method if needed)"];
+  fix_issues [label="Fix issues\n(use /root-cause if needed)"];
   failure_count [label="3+ failures?", shape=diamond];
 
   // Security check
@@ -76,7 +72,7 @@ digraph CodeDeveloper {
 
   // Review and complete
   code_review [label="Run /branch-review"];
-  verification [label="Run /verify-done", fillcolor=orange];
+  verification [label="Run the proof", fillcolor=orange];
 
   // Story-specific
   update_story [label="Update story\n(checkbox, changelog)"];
@@ -100,12 +96,10 @@ digraph CodeDeveloper {
 
   work_type -> use_debug [label="debug"];
   work_type -> use_refactor [label="refactor"];
-  work_type -> use_optimize [label="optimize"];
   work_type -> implement [label="implement"];
 
   use_debug -> implement;
   use_refactor -> implement;
-  use_optimize -> implement;
 
   implement -> tdd_needed;
   tdd_needed -> use_tdd [label="YES"];
@@ -184,14 +178,13 @@ All require `*` prefix. Invocation commands in table above. Additional:
 
 | Situation | Delegate To |
 |-----------|-------------|
-| Bug encountered | `/debug-method` (use `/trace-back` when the error is deep in the stack) |
-| Error deep in stack | `/trace-back` |
-| Refactoring code | `/refactor` |
-| Need tests (when required) | `/test-generate` or `/tdd-flow` |
-| Writing any test | `/test-traps` (avoid mocks, production pollution) |
-| Before completion | `/verify-done` |
+| Bug encountered | `/root-cause` |
+| Error deep in stack | `/root-cause` (Phase 1, step 5) |
+| Refactoring code, or a perf problem | `/refactor` (its perf pass is on by default) |
+| Need tests (when required) | `/test-generate` |
+| Writing any test | AGENT_RULES.md → Testing Standards |
+| Before completion | Run the proof and read its output |
 | After code changes | `/security` |
 | Task complete / general review | `/branch-review` (reviews the branch + full security audit, verifies claims, reports findings — never fixes) |
-| Performance issues | `/optimize` |
 
 You are an autonomous implementation specialist. Execute with precision, delegate appropriately, and communicate clearly when you need guidance or encounter blockers.

package/packages/droid/droids/feature-planner.md

@@ -1,7 +1,6 @@
 ---
 name: feature-planner
-description: Epics, user stories, prioritization, backlog management
-when_to_use: Use for creating epics and user stories, prioritization, backlog navigation, story refinement, and sprint planning
+description: Epics, user stories, prioritization, backlog management. Use for creating epics and user stories, prioritization, backlog navigation, story refinement, and sprint planning
 model: inherit
 tools: ["Read", "LS", "Grep", "Glob", "Create", "Edit", "MultiEdit", "ApplyPatch", "Execute", "WebSearch", "FetchUrl", "mcp"]
 ---

package/packages/droid/droids/market-researcher.md

@@ -1,7 +1,6 @@
 ---
 name: market-researcher
-description: Research markets, analyze competitors, brainstorm
-when_to_use: Use for market research, brainstorming, competitive analysis, project briefs, and initial project discovery
+description: Research markets, analyze competitors, brainstorm. Use for market research, brainstorming, competitive analysis, project briefs, and initial project discovery
 model: inherit
 tools: ["Read", "LS", "Grep", "Glob", "Create", "Edit", "MultiEdit", "ApplyPatch", "Execute", "WebSearch", "FetchUrl", "mcp"]
 ---

package/packages/droid/droids/orchestrator.md

@@ -1,7 +1,6 @@
 ---
 name: orchestrator
-description: Route to agents, execute workflows, discover resources
-when_to_use: Use for workflow coordination, multi-agent tasks, role switching, and when unsure which specialist to consult
+description: Route to agents, execute workflows, discover resources. Use for workflow coordination, multi-agent tasks, role switching, and when unsure which specialist to consult
 model: inherit
 tools: ["Read", "LS", "Grep", "Glob", "Create", "Edit", "MultiEdit", "ApplyPatch", "Execute", "WebSearch", "FetchUrl", "mcp"]
 ---
@@ -77,7 +76,7 @@ Predefined multi-agent sequences:
 | Workflow | Sequence | When |
 |----------|----------|------|
 | **Greenfield** | market-researcher → feature-planner → 1-create-prd → 2-generate-tasks → 3-process-task-list | New product/feature from scratch |
-| **Brownfield** | context-builder → system-architect → feature-planner | Understand existing codebase |
+| **Brownfield** | system-architect → feature-planner | Understand existing codebase |
 | **Feature** | feature-planner → 1-create-prd → 2-generate-tasks → 3-process-task-list | Add feature to existing product |
 | **Bug Fix** | code-developer → quality-assurance | Fix and verify |
 | **Sprint** | feature-planner (*sprint-plan) → 2-generate-tasks | Plan sprint from backlog |
@@ -96,7 +95,7 @@ Quick routing when user has clear intent:
 | review, quality, test | quality-assurance |
 | design, UI, wireframe | ui-designer |
 | architecture, tech, design doc | system-architect |
-| understand, document, brownfield | context-builder |
+| understand, brownfield, existing codebase | system-architect |
 
 ## Commands
 

package/packages/droid/droids/quality-assurance.md

@@ -1,7 +1,6 @@
 ---
 name: quality-assurance
-description: Code quality validation, test architecture, security review
-when_to_use: Use for code review, test coverage analysis, security scanning, quality gate decisions, and improvement recommendations
+description: Code quality validation, test architecture, security review. Use for code review, test coverage analysis, security scanning, quality gate decisions, and improvement recommendations
 model: inherit
 tools: ["Read", "LS", "Grep", "Glob", "Create", "Edit", "MultiEdit", "ApplyPatch", "Execute", "WebSearch", "FetchUrl", "mcp"]
 ---
@@ -59,13 +58,15 @@ digraph QualityAssurance {
 
 Before any analysis, read (if exists):
 - `AGENTS.md` - Project instructions, patterns, conventions
+<!-- mirror:literal:start — names every tool's config file on purpose -->
 - `AGENT.md` / `AGENTS.md` - Agent configurations
+<!-- mirror:literal:end -->
 - `README.md` - Project overview
 - Test config files (`jest.config`, `pytest.ini`, etc.)
 
 ## Slash Commands Available
 
-Use these during analysis: `/branch-review`, `/security`, `/verify-done`
+Use these during analysis: `/branch-review`, `/security`
 
 ## Analysis Areas
 

package/packages/droid/droids/system-architect.md

@@ -1,7 +1,6 @@
 ---
 name: system-architect
-description: Design MVP-first architectures with opensource preference
-when_to_use: Use for system design, HLA/HLD creation, technology selection, and architecture validation from epics, user stories, or PRDs
+description: Design MVP-first architectures with opensource preference. Use for system design, HLA/HLD creation, technology selection, and architecture validation from epics, user stories, or PRDs
 model: inherit
 tools: ["Read", "LS", "Grep", "Glob", "Create", "Edit", "MultiEdit", "ApplyPatch", "Execute", "WebSearch", "FetchUrl", "mcp"]
 ---

package/packages/droid/droids/ui-designer.md

@@ -1,7 +1,6 @@
 ---
 name: ui-designer
-description: Design lightweight, functional UI with simplified flows
-when_to_use: Use for UI/UX design, user journeys, low-fidelity mockups, flow simplification, and framework selection
+description: Design lightweight, functional UI with simplified flows. Use for UI/UX design, user journeys, low-fidelity mockups, flow simplification, and framework selection
 model: inherit
 tools: ["Read", "LS", "Grep", "Glob", "Create", "Edit", "MultiEdit", "ApplyPatch", "Execute", "WebSearch", "FetchUrl", "mcp"]
 ---

package/packages/opencode/AGENTS.md

@@ -6,7 +6,7 @@ Opencode is a lightweight CLI tool that provides workflow automation commands.
 
 These subagents are available when using Claude Code CLI. Opencode can reference them but doesn't implement them directly.
 
-### Subagents (11 total)
+### Subagents (10 total)
 
 | ID | Title | When To Use |
 |---|---|---|
@@ -14,7 +14,6 @@ These subagents are available when using Claude Code CLI. Opencode can reference
 | 2-generate-tasks | 2-Generate Tasks | Detailed Planning - use to break down the PRD into a granular, actionable task list |
 | 3-process-task-list | 3-Process Task List | Iterative Implementation - use to guide the AI to tackle one task at a time, allowing you to review and approve each change |
 | code-developer | Full Stack Developer | Use for code implementation, debugging, refactoring, and development best practices |
-| context-builder | Context Initializer | Use to initialize project context for new/existing projects, discover and organize documentation, create AGENTS.md and KNOWLEDGE_BASE.md for optimal token-efficient memory |
 | feature-planner | Product Manager | Use for creating epics and user stories, prioritization, backlog navigation, story refinement, and retrospectives |
 | market-researcher | Business Analyst | Use for market research, brainstorming, competitive analysis, project briefs, and initial project discovery |
 | orchestrator | Master Orchestrator | Use for workflow coordination, multi-agent tasks, role switching guidance, and when unsure which specialist to consult |
@@ -22,28 +21,23 @@ These subagents are available when using Claude Code CLI. Opencode can reference
 | system-architect | Architect | Use for system design, architecture documents, technology selection, API design, and infrastructure planning |
 | ui-designer | UX Expert | Use for UI/UX design, wireframes, prototypes, front-end specifications, and user experience optimization |
 
-## Opencode Commands (18 total)
+## Opencode Commands (13 total)
 
-| ID | Description | Usage | Auto |
-|---|---|---|---|
-| brainstorming | Refines rough ideas into fully-formed designs through collaborative questioning | /brainstorming <session-type> <topic> | false |
-| docs-builder | Reorg a docs corpus, split an oversized doc, search it, keep pages current, index them | /docs-builder [reorg \| cleanup <file.md>] | false |
-| live-canvas | Design UI variations and collect click-to-annotate feedback from the browser (batch mode only on Opencode) | /live-canvas | false |
-| optimize | Analyze and optimize performance issues | /optimize <target-area> | - |
-| refactor | Refactor code while maintaining behavior and tests | /refactor <code-section> | - |
+| ID | Description | Usage |
+|---|---|---|
+| brainstorming | Refines rough ideas into fully-formed designs through collaborative questioning | /brainstorming <session-type> <topic> |
+| docs-builder | Reorg a docs corpus, split an oversized doc, search it, keep pages current, index them | /docs-builder [reorg \| cleanup <file.md>] |
+| live-canvas | Design UI variations and collect click-to-annotate feedback from the browser (batch mode only on Opencode) | /live-canvas |
+| refactor | Refactor and optimize code while maintaining behavior and tests | /refactor <code-section> | - |
 | remember | Consolidate stashes + friction into project memory | /remember | - |
 | branch-review | Pre-merge review: general review + full security audit, verify pass, no fixes | /branch-review [target] [level] | - |
-| trace-back | Systematically traces bugs backward through call stack to identify source | /trace-back <issue-description> | false |
+| root-cause | Find the cause before changing code - evidence, backward trace, one hypothesis, fix at the source | /root-cause <bug-or-error-description> |
 | security | Security audit — recurring six, injection, auth, trust boundaries; reports, never fixes | /security [target] | - |
 | ship | Mechanical pre-deploy gate — tests, build, tree state | /ship | - |
 | release | Verify, sweep docs, cut a version — then hand back the merge/tag/publish sequence | /release | - |
-| skill-creator | Guide for creating effective skills and extending Claude capabilities | /skill-creator <skill-type> <skill-description> | false |
+| skill-creator | Guide for creating effective skills and extending Claude capabilities | /skill-creator <skill-type> <skill-description> |
 | stash | Save session context for compaction recovery or handoffs | /stash ["optional-name"] | - |
-| debug-method | Four-phase debugging framework - investigate root cause before any fixes | /debug-method <bug-or-error-description> | false |
-| tdd-flow | Write test first, watch it fail, write minimal code to pass | /tdd-flow <feature-or-behavior-to-test> | true |
 | test-generate | Generate tests, run them, verify each one actually exercises the code | /test-generate <file> | - |
-| test-traps | Prevents testing mock behavior and production pollution with test-only methods | /test-traps <testing-scenario> | true |
-| verify-done | Requires running verification commands before making any success claims | /verify-done <work-to-verify> | true |
 
 All resources are auto-discovered from frontmatter in their respective directories:
 - **Agents**: `./agent/*.md`

package/packages/opencode/agent/code-developer.md

@@ -41,29 +41,26 @@ digraph CodeDeveloper {
   work_type [label="Work type?", shape=diamond];
 
   // Context discovery (conditional)
-  needs_context [label="Debug/refactor/\noptimize?", shape=diamond];
+  needs_context [label="Debug or\nrefactor?", shape=diamond];
   context_discovery [label="Context Discovery\n(search related code,\ndeps, usages)", fillcolor=lightyellow];
 
   // Debug path
-  use_debug [label="Use /debug-method\nor /trace-back"];
+  use_debug [label="Use /root-cause"];
 
   // Refactor path
   use_refactor [label="Use /refactor"];
 
-  // Optimize path
-  use_optimize [label="Use /optimize"];
-
   // Implement path
   implement [label="Implement changes"];
 
   // Conditional testing
   tdd_needed [label="TDD specified\nor tests needed?", shape=diamond];
-  use_tdd [label="Use /tdd-flow\nor /test-generate"];
+  use_tdd [label="Use /test-generate"];
 
   // Validation
   run_validations [label="Run validations\n(lint, build, tests)"];
   validations_pass [label="Pass?", shape=diamond];
-  fix_issues [label="Fix issues\n(use /debug-method if needed)"];
+  fix_issues [label="Fix issues\n(use /root-cause if needed)"];
   failure_count [label="3+ failures?", shape=diamond];
 
   // Security check
@@ -80,7 +77,7 @@ digraph CodeDeveloper {
 
   // Review and complete
   code_review [label="Run /branch-review"];
-  verification [label="Run /verify-done", fillcolor=orange];
+  verification [label="Run the proof", fillcolor=orange];
 
   // Story-specific
   update_story [label="Update story\n(checkbox, changelog)"];
@@ -104,12 +101,10 @@ digraph CodeDeveloper {
 
   work_type -> use_debug [label="debug"];
   work_type -> use_refactor [label="refactor"];
-  work_type -> use_optimize [label="optimize"];
   work_type -> implement [label="implement"];
 
   use_debug -> implement;
   use_refactor -> implement;
-  use_optimize -> implement;
 
   implement -> tdd_needed;
   tdd_needed -> use_tdd [label="YES"];
@@ -188,14 +183,13 @@ All require `*` prefix. Invocation commands in table above. Additional:
 
 | Situation | Delegate To |
 |-----------|-------------|
-| Bug encountered | `/debug-method` (use `/trace-back` when the error is deep in the stack) |
-| Error deep in stack | `/trace-back` |
-| Refactoring code | `/refactor` |
-| Need tests (when required) | `/test-generate` or `/tdd-flow` |
-| Writing any test | `/test-traps` (avoid mocks, production pollution) |
-| Before completion | `/verify-done` |
+| Bug encountered | `/root-cause` |
+| Error deep in stack | `/root-cause` (Phase 1, step 5) |
+| Refactoring code, or a perf problem | `/refactor` (its perf pass is on by default) |
+| Need tests (when required) | `/test-generate` |
+| Writing any test | AGENT_RULES.md → Testing Standards |
+| Before completion | Run the proof and read its output |
 | After code changes | `/security` |
 | Task complete / general review | `/branch-review` (reviews the branch + full security audit, verifies claims, reports findings — never fixes) |
-| Performance issues | `/optimize` |
 
 You are an autonomous implementation specialist. Execute with precision, delegate appropriately, and communicate clearly when you need guidance or encounter blockers.

package/packages/opencode/agent/orchestrator.md

@@ -81,7 +81,7 @@ Predefined multi-agent sequences:
 | Workflow | Sequence | When |
 |----------|----------|------|
 | **Greenfield** | market-researcher → feature-planner → 1-create-prd → 2-generate-tasks → 3-process-task-list | New product/feature from scratch |
-| **Brownfield** | context-builder → system-architect → feature-planner | Understand existing codebase |
+| **Brownfield** | system-architect → feature-planner | Understand existing codebase |
 | **Feature** | feature-planner → 1-create-prd → 2-generate-tasks → 3-process-task-list | Add feature to existing product |
 | **Bug Fix** | code-developer → quality-assurance | Fix and verify |
 | **Sprint** | feature-planner (*sprint-plan) → 2-generate-tasks | Plan sprint from backlog |
@@ -100,7 +100,7 @@ Quick routing when user has clear intent:
 | review, quality, test | quality-assurance |
 | design, UI, wireframe | ui-designer |
 | architecture, tech, design doc | system-architect |
-| understand, document, brownfield | context-builder |
+| understand, brownfield, existing codebase | system-architect |
 
 ## Commands
 

package/packages/opencode/agent/quality-assurance.md

@@ -63,13 +63,15 @@ digraph QualityAssurance {
 
 Before any analysis, read (if exists):
 - `AGENTS.md` - Project instructions, patterns, conventions
+<!-- mirror:literal:start — names every tool's config file on purpose -->
 - `AGENT.md` / `AGENTS.md` - Agent configurations
+<!-- mirror:literal:end -->
 - `README.md` - Project overview
 - Test config files (`jest.config`, `pytest.ini`, etc.)
 
 ## Slash Commands Available
 
-Use these during analysis: `/branch-review`, `/security`, `/verify-done`
+Use these during analysis: `/branch-review`, `/security`
 
 ## Analysis Areas
 

package/packages/opencode/command/brainstorming.md

@@ -1,8 +1,5 @@
 ---
-name: brainstorming
 description: Use when creating or developing, before writing code or implementation plans - refines rough ideas into fully-formed designs through collaborative questioning, alternative exploration, and incremental validation. Don't use during clear 'mechanical' processes
-usage: /brainstorming <session-type> <topic>
-auto_trigger: false
 ---
 
 # Brainstorming Ideas Into Designs
@@ -43,7 +40,7 @@ Start by understanding the current project context, then ask questions one at a
 
 **Implementation (if continuing):**
 - Ask: "Ready to set up for implementation?"
-- Create isolated workspace (use git worktrees if needed)
+- Create isolated workspace for implementation
 - Create detailed implementation plan
 
 ## Key Principles

package/packages/opencode/command/branch-review.md

@@ -1,9 +1,5 @@
 ---
-name: branch-review
 description: Review a branch before merge [target] [level]
-usage: /branch-review [target] [low|medium|high|max]
-argument-hint: [file, branch (e.g. main), range (main..HEAD), or empty] [effort level]
-allowed-tools: Read, Grep, Glob, Agent, Bash(git diff *), Bash(git log *), Bash(git show *), Bash(git status *), Bash(git grep *), Bash(git rev-parse *), Bash(git merge-base *), Bash(rg *)
 ---
 Pre-merge review gate. Two stages — **general review** then a **full security
 audit** — followed by an adversarial verify pass. It **never edits code**: it
@@ -11,7 +7,7 @@ reports findings and hands them back. Fixing is a separate, separately
 authorized action.
 
 Only **Critical** and **High** findings block the merge. Everything else is
-appended to the **fix ledger** (`.claude/remember/fix-ledger.md`) — a local,
+appended to the **fix ledger** (`.opencode/remember/fix-ledger.md`) — a local,
 cumulative list, living beside `MEMORY.md`, that `/refactor` (no arguments)
 works through between features. Like its neighbours it is a private working
 artifact, usually gitignored; it persists across reviews, it is not a
@@ -44,17 +40,17 @@ at the current HEAD SHA.
   review of a report. (Same rule `/security` carries inside stage 2.)
 - **No edits — two exceptions.** You have no authorization to change code,
   even for a finding you are certain about. Report it. The only files you may
-  write are `.claude/remember/fix-ledger.md` (append bullets; never rewrite or
-  delete) and `.claude/remember/last-review.md` (overwrite; the review record
+  write are `.opencode/remember/fix-ledger.md` (append bullets; never rewrite or
+  delete) and `.opencode/remember/last-review.md` (overwrite; the review record
   described at the end of this file).
 - **Prove it with two checks, because neither sees what the other does.**
   `git status --porcelain`, at start and again before you report, proves no
   **tracked** file changed — that is the "never edits code" guarantee, and it
-  is the one that matters. It cannot police your own two writes: `.claude/`
+  is the one that matters. It cannot police your own two writes: `.opencode/`
   is normally gitignored, so porcelain stays empty whether you wrote the
   allowed files, wrote nothing, or overwrote `MEMORY.md`. `git status
-  --ignored` does not close it either — it collapses to `!! .claude/`, the
-  directory, not the files. So also take `md5sum .claude/remember/*` before
+  --ignored` does not close it either — it collapses to `!! .opencode/`, the
+  directory, not the files. So also take `md5sum .opencode/remember/*` before
   you start and again before you report, and show the comparison: only
   `fix-ledger.md` and `last-review.md` may differ.
 
@@ -95,7 +91,7 @@ Record the **HEAD SHA** you reviewed, and **report the target you resolved**
 (the literal range or path) in your output, so the orchestrator can see what
 was actually read rather than assuming.
 
-**Re-review after fixes: read `.claude/remember/last-review.md` first.** Its
+**Re-review after fixes: read `.opencode/remember/last-review.md` first.** Its
 `sha:` line is the previously-reviewed commit and its `blockers:` list is what
 you owe an answer on — take both from the file, never from the orchestrator's
 recollection, for the same reason `/release` does. Then:
@@ -231,7 +227,7 @@ check before escalating.
 
 ### Ledger (non-blocking — medium / low)
 Not in the report. **Append** each one as a single bullet to
-`.claude/remember/fix-ledger.md` (create the file with the header below if
+`.opencode/remember/fix-ledger.md` (create the file with the header below if
 missing):
 
 ```
@@ -256,7 +252,7 @@ with `UNVERIFIED:` so `/refactor` retests before acting.
 The **snippet is the anchor**: 20–60 verbatim characters from the line,
 unique enough for `git grep -F` to find it after lines shift. No line
 numbers, no TODO comments in code — the ledger is the single writer. Before
-appending, dedupe with **plain `grep -F "<snippet>" .claude/remember/fix-ledger.md`**;
+appending, dedupe with **plain `grep -F "<snippet>" .opencode/remember/fix-ledger.md`**;
 if it is already there, skip it. Do not touch existing bullets.
 
 **A bullet you disprove is deleted, not annotated.** If you establish that an
@@ -280,7 +276,7 @@ Then a coverage line: stage 1 at level `<level>`, stage 2 full, stage 3 —
 each `ran ✓/✗` with its evidence. A stage you did not actually run is a **✗**, never an
 assumed pass.
 
-**Write the review record** to `.claude/remember/last-review.md`, overwriting
+**Write the review record** to `.opencode/remember/last-review.md`, overwriting
 it. `/release` reads this file; a SHA that lives only in a chat message is
 gone after a compaction or a handover, and the only remaining source is the
 orchestrator — the one party this command already refuses to take a review's
@@ -326,7 +322,7 @@ does not move — which means nothing was fixed, which is the correct outcome.
 
 End with:
 - **Reviewed at HEAD `<sha>` on `<branch>`, target `<resolved range or path>`,
-  tree clean at start; at exit clean or the two `.claude/remember/` paths
+  tree clean at start; at exit clean or the two `.opencode/remember/` paths
   only.**
 - **Fix ledger: N open, M added this run** (N = bullet count). When N > 0,
   add: "N fixes waiting — run `/refactor` between features." The ledger is a

package/packages/opencode/command/docs-builder.md

@@ -1,9 +1,5 @@
 ---
-name: docs-builder
 description: Reorg a docs corpus, split an oversized doc, search it, keep pages current, index them
-usage: /docs-builder [reorg | cleanup <file.md> | search <query words...>]
-argument-hint: [reorg | cleanup <file.md> | search <query words...> — empty asks first run vs. drift]
-allowed-tools: Read, Write, Edit, Grep, Glob, Task, AskUserQuestion, Bash(node:*), Bash(git:*), Bash(rg:*)
 ---
 
 # docs-builder

package/packages/opencode/command/live-canvas.md

@@ -1,5 +1,4 @@
 ---
-name: live-canvas
 description: Conduct design interviews, generate UI variations, and collect live click-to-annotate feedback that streams into the session so edits land without leaving the browser. Use when the user wants rapid iterative UI refinement, not just batched feedback.
 ---
 
@@ -26,7 +25,7 @@ Live Canvas supports two feedback transports. **The user picks every time** —
 
 ### Host detection — do this first
 
-This SKILL.md is the Claude Code variant of the skill. Same content is mirrored as docs for Droid/Amp/Opencode under `packages/<tool>/commands/live-canvas/`, but those tools don't support the MCP channel.
+This SKILL.md is the Claude Code variant of the skill. Same content is mirrored as docs for Droid/Amp/Opencode under `packages/<tool>/` beside the other capabilities, but those tools don't support the MCP channel.
 
 **If running under Droid, Amp, or Opencode (not Claude Code):**
 - Skip the mode question entirely.
@@ -109,6 +108,8 @@ Or pick JSON now to stay in this session — feedback gets written to a file
 you paste back here. No relaunch needed.
 ```
 
+<!-- mirror:literal:start — Live mode is the Claude Code MCP plugin; these are
+     Claude's real paths in every kit, because no other tool can install it -->
 **Case C — first-time setup block:**
 
 ```
@@ -125,6 +126,7 @@ Live mode needs a one-time install. Two steps:
 That's it — once the plugin is installed, /live-canvas in any session can
 claim the channel. Re-run /live-canvas and pick Live.
 ```
+<!-- mirror:literal:end -->
 
 Do not try to run any of these commands yourself. Three reasons:
 1. The `/plugin` steps are Claude Code slash commands — not doable from inside a running session.
@@ -418,7 +420,7 @@ Create all files under `.claude-design/`:
 
 ### The overlay
 
-**One template, every framework:** `~/.claude/skills/live-canvas/templates/overlay-vanilla.js`. Single file, zero dependencies, plain DOM. Works in vanilla JS, Vue, Svelte, Rails, Django, Phoenix, plain HTML, Next.js, Vite-React, Remix — anywhere a `<script>` tag runs.
+**One template, every framework:** `~/.config/opencode/command/live-canvas/templates/overlay-vanilla.js`. Single file, zero dependencies, plain DOM. Works in vanilla JS, Vue, Svelte, Rails, Django, Phoenix, plain HTML, Next.js, Vite-React, Remix — anywhere a `<script>` tag runs.
 
 Copy it into a directory served by the dev server (e.g. `public/overlay-vanilla.js` for Next.js, `static/overlay-vanilla.js` for Vite, the public dir for Rails/Django). Reference it from the lab page.
 
@@ -545,7 +547,7 @@ The Live Canvas page must include:
 1. **Header** with:
    - Design Brief summary (target, scope, key requirements)
    - Instructions for reviewing
-   - **Lab banner (REQUIRED)** — paste `~/.claude/skills/live-canvas/templates/lab-banner.html` at the top of the lab page. Same text in any mode. For React/TSX labs, translate the inline style to a JS object: camelCase keys, string values. E.g. `style="border-radius:8px; padding:10px 14px; font-size:13px"` → `style={{ borderRadius: '8px', padding: '10px 14px', fontSize: '13px' }}`. Keep the text and `role="note"`.
+   - **Lab banner (REQUIRED)** — paste `~/.config/opencode/command/live-canvas/templates/lab-banner.html` at the top of the lab page. Same text in any mode. For React/TSX labs, translate the inline style to a JS object: camelCase keys, string values. E.g. `style="border-radius:8px; padding:10px 14px; font-size:13px"` → `style={{ borderRadius: '8px', padding: '10px 14px', fontSize: '13px' }}`. Keep the text and `role="note"`.
 
 2. **Variant Grid** with:
    - Clear labels (A, B, C, D, E)
@@ -568,7 +570,7 @@ The Live Canvas page must include:
 
    The overlay (`overlay-vanilla.js`) enables users to click on elements and leave comments. Without it, the Live Canvas is just a static page with no way to collect structured feedback.
 
-   - Copy `~/.claude/skills/live-canvas/templates/overlay-vanilla.js` into a directory served by the dev server (e.g. `public/`, `static/`, or wherever the framework serves static assets).
+   - Copy `~/.config/opencode/command/live-canvas/templates/overlay-vanilla.js` into a directory served by the dev server (e.g. `public/`, `static/`, or wherever the framework serves static assets).
    - Reference it from the lab page via `<script>` tag and call `LiveCanvas.init({...})` once with `target`, `channelUrl` (Live mode), and optional `batchEndpoint`. See "Wiring the overlay" above for the exact snippets per framework.
    - Every variant container in the lab page MUST have a `data-variant="X"` attribute (A, B, C, D, E, or F). The overlay uses this to route comments to the right variant file.