opencodekit 0.23.2 → 0.23.4

package/dist/template/.opencode/command/test.md

@@ -1,66 +0,0 @@
----
-description: Write or generate tests for code
-argument-hint: "<file or function> [--unit|--integration|--e2e]"
-agent: build
----
-
-# Test: $ARGUMENTS
-
-Write or generate tests for the specified code.
-
-## Load Skills
-
-```typescript
-skill({ name: "test-driven-development" });
-skill({ name: "testing-anti-patterns" });
-skill({ name: "verification-before-completion" });
-```
-
-## Parse Arguments
-
-| Argument | Default | Description |
-|---|---|---|
-| `<file or function>` | required | File path or function name to test |
-| `--unit` | auto | Unit test (default for utils, helpers) |
-| `--integration` | false | Integration test (default for API, DB) |
-| `--e2e` | false | End-to-end test (requires full setup) |
-
-## Process
-
-### Phase 1: Understand
-
-1. Read the file and understand the function/module contract
-2. Identify: inputs, outputs, side effects, error states, edge cases
-3. Check existing tests for patterns and structure
-
-### Phase 2: Write Tests
-
-Cover:
-- Happy path (expected input → expected output)
-- Edge cases (empty, null, boundary values)
-- Error states (invalid input, missing dependencies)
-- Contract invariants (what must always be true)
-
-Follow the existing test patterns in the project. If none exist, check `vitest.config.ts`.
-
-### Phase 3: Run and Verify
-
-```bash
-vitest <path>  # or npm test
-```
-
-TDD if writing implementation simultaneously: RED → GREEN → REFACTOR.
-
-## Anti-Patterns
-
-- Testing implementation details instead of behavior
-- Mocking without understanding the real dependency
-- Test-only code in production files (exporting internals just for tests)
-- Brittle assertions (matching full objects when partial match suffices)
-
-## Output
-
-Report:
-1. Tests written
-2. Coverage summary
-3. Verification results

package/dist/template/.opencode/command/ui-review.md

@@ -1,109 +0,0 @@
----
-description: Review UI/UX design for quality, aesthetics, and best practices
-argument-hint: "<image-or-component-path> [--responsive] [--dark-mode]"
-agent: vision
-model: proxypal/gemini-3-pro-preview
----
-
-# UI Review: $ARGUMENTS
-
-## Load Skills
-
-```typescript
-skill({ name: "accessibility-audit" }); // WCAG checklists
-skill({ name: "frontend-design" }); // Anti-patterns, design quality
-```
-
-## Input
-
-Parse `$ARGUMENTS`:
-
-- **Path** (required): Image, screenshot, or component file
-- **`--responsive`**: Include responsive breakpoint review
-- **`--dark-mode`**: Include dark mode review
-
-## Review Workflow
-
-### 1. Analyze the Input
-
-Analyze the input:
-
-- Content inventory (elements, text, icons)
-- Visual properties (colors, typography, spacing, layout)
-- Design patterns and potential issues
-
-### 2. Usability Heuristic Pass
-
-Before visual scoring, check:
-
-- System status is visible for async or multi-step work
-- Labels and navigation use user vocabulary, not implementation terms
-- Users can cancel, undo, go back, retry, or recover from failure
-- Controls, names, and layouts are consistent across the surface
-- Dangerous or invalid actions are prevented before they happen
-- Options and relationships are visible without relying on memory
-- High-volume workflows expose efficient paths where appropriate
-- Empty/loading/error/success states are present and useful
-
-Any failure that blocks task completion or recovery is **Critical**, even if the screen looks polished.
-
-### 3. Score Categories
-
-Rate each 1-10 with brief justification:
-
-| Category                          | What to Evaluate                                               |
-| --------------------------------- | -------------------------------------------------------------- |
-| **Information Architecture**      | User vocabulary, scope clarity, relationships, navigation      |
-| **Task Flow & Recovery**          | Primary action, cancellation, undo/retry, error recovery       |
-| **Forms & Data Interaction**      | Labels, helper text, validation, selection, bulk actions       |
-| **Typography**                    | Hierarchy, readability, weight contrast, intentional choices   |
-| **Color**                         | Palette cohesion, contrast, semantic usage, no AI slop         |
-| **Layout & Spacing**              | Visual hierarchy, consistency, alignment, white space          |
-| **Interactive States**            | Hover, focus, active, disabled, loading/error/success coverage |
-| **Accessibility & Semantic HTML** | WCAG AA compliance, native semantics, keyboard/focus behavior  |
-| **Component Consistency**         | Shared token DNA: radius, height, border, shadow, states       |
-| **Visual Polish**                 | Consistency, attention to detail, motion, shadows, icons       |
-
-### 4. Conditional Reviews
-
-**If `--responsive`**: Check at 375px, 768px, 1280px, 1536px+. Flag touch targets, horizontal scroll, text sizing.
-
-**If `--dark-mode`**: Check contrast on dark backgrounds, adapted colors (not just inverted), shadow adjustments, focus visibility.
-
-### 5. Report Findings
-
-Group by severity:
-
-- **Critical (Must Fix)**: Accessibility failures, broken interactions, dead-end errors, unsafe destructive actions
-- **Warning (Should Fix)**: AI slop patterns, inconsistent spacing, missing states, confusing IA/naming
-- **Info (Nice to Have)**: Polish opportunities
-
-For each finding: location, impact, and recommended fix.
-
-## Output
-
-Deliver:
-
-1. Category scores (1-10 each) with justification
-2. Overall assessment (1-2 sentences)
-3. Findings grouped by severity with actionable fixes
-4. Code fixes for critical issues (if reviewing component code)
-
-## Record Findings
-
-```typescript
-observation({
-  type: "warning",
-  title: "UI: [Component] [issue type]",
-  narrative: "Found [issue] in [location]. Impact: [description]...",
-  concepts: "ui, accessibility, [category]",
-  confidence: "high",
-});
-```
-
-## Related Commands
-
-| Need                | Command   |
-| ------------------- | --------- |
-| Design from scratch | `/design` |
-| Ship implementation | `/ship`   |

package/dist/template/.opencode/opencodex-fast.jsonc

@@ -1,3 +0,0 @@
-{
-  "enabled": false
-}

package/dist/template/.opencode/plugin/rtk.ts

@@ -1,43 +0,0 @@
-import type { Plugin } from "@opencode-ai/plugin";
-
-// RTK OpenCode plugin — rewrites commands to use rtk for token savings.
-// Requires: rtk >= 0.23.0 in PATH.
-//
-// This is a thin delegating plugin: all rewrite logic lives in `rtk rewrite`,
-// which is the single source of truth (src/discover/registry.rs).
-// To add or change rewrite rules, edit the Rust registry — not this file.
-
-export const RtkOpenCodePlugin: Plugin = async ({ $ }) => {
-	try {
-		await $`which rtk`.quiet();
-	} catch {
-		console.warn("[rtk] rtk binary not found in PATH — plugin disabled");
-		return {};
-	}
-
-	return {
-		"tool.execute.before": async (input, output) => {
-			const tool = String(input?.tool ?? "").toLowerCase();
-			if (tool !== "bash" && tool !== "shell") return;
-			const args = output?.args;
-			if (!args || typeof args !== "object") return;
-
-			const command = (args as Record<string, unknown>).command;
-			if (typeof command !== "string" || !command) return;
-			// This config is symlinked as both global and project OpenCode config.
-			// OpenCode may load this plugin twice in that layout, so avoid rewriting
-			// commands that have already been routed through rtk.
-			if (/^\s*(?:RTK_[A-Z_]+=\S+\s+)*rtk\b/.test(command)) return;
-
-			try {
-				const result = await $`rtk rewrite ${command}`.quiet().nothrow();
-				const rewritten = String(result.stdout).trim();
-				if (rewritten && rewritten !== command) {
-					(args as Record<string, unknown>).command = rewritten;
-				}
-			} catch {
-				// rtk rewrite failed — pass through unchanged
-			}
-		},
-	};
-};

package/dist/template/.opencode/skill/agent-teams/SKILL.md

@@ -1,268 +0,0 @@
----
-name: agent-teams
-description: >
-  Use when working with Claude Code-style agent teams for parallel research, review, competing hypotheses,
-  or any task that benefits from multiple agents working simultaneously under a lead coordinator.
-  Covers team configuration, task distribution, coordination patterns, and best practices.
-version: "1.0.0"
-license: MIT
-tags: [agent-coordination, workflow]
-dependencies: []
----
-
-# Agent Teams - Multi-Agent Team Coordination
-
-> **Replaces** single-agent sequential work when tasks benefit from parallel research, review, or competing hypotheses
-
-## When to Use
-
-- Parallel research, review, or competing approaches that need coordination
-- Tasks benefit from shared findings and a lead coordinating teammates
-
-## When NOT to Use
-
-- Single-agent tasks or tightly coupled edits where coordination overhead is wasteful
-- Simple parallel work that can use fire-and-forget subagents instead
-
-## Overview
-
-**Agent Teams = Lead + Teammates + Shared Task List + Messaging**
-
-- **Lead agent**: Coordinates the team - distributes tasks, monitors progress, synthesizes results
-- **Teammates**: Execute tasks independently but can message each other and the lead
-- **Task list**: Shared work queue that the lead manages
-- **Messaging**: Bidirectional communication between lead and teammates
-
-## When to Use Agent Teams vs Subagents
-
-| Criteria              | Agent Teams                            | Subagents (Task tool)               |
-| --------------------- | -------------------------------------- | ----------------------------------- |
-| **Coordination**      | Lead coordinates, teammates message    | Fire-and-forget, results return     |
-| **Communication**     | Bidirectional messaging                | One-way (result only)               |
-| **Task reassignment** | Dynamic - lead can reassign            | Fixed - each subagent does its task |
-| **Context sharing**   | Shared through lead                    | Independent contexts                |
-| **Best for**          | Research, review, competing approaches | Independent implementation tasks    |
-| **Overhead**          | Higher - coordination cost             | Lower - no coordination             |
-
-### Decision Matrix
-
-```
-Need coordination between workers?  → Agent Teams
-Workers are fully independent?      → Subagents (Task tool)
-Need competing hypotheses?          → Agent Teams
-Need shared findings?               → Agent Teams
-Simple parallel execution?          → Subagents (Task tool)
-```
-
-### Parallel Skill Selection
-
-| Scenario                                    | Use This Skill              |
-| ------------------------------------------- | --------------------------- |
-| 3+ independent bug investigations           | dispatching-parallel-agents |
-| Coordinated team (research + review + impl) | agent-teams                 |
-| Large plan with dependency graph            | swarm-coordination          |
-| 2 independent tasks                         | Just use 2 Task() calls     |
-
-## When to Use
-
-- **Parallel research**: Multiple agents researching different aspects of a problem
-- **Code review**: Multiple reviewers examining different files/concerns
-- **Competing hypotheses**: Agents try different approaches, best one wins
-- **Large refactors**: Agents handle different subsystems with coordination
-- **Architecture exploration**: Agents explore different design options simultaneously
-
-## When NOT to Use
-
-- Single-agent tasks (overhead not worth it)
-- Tightly coupled work where agents would constantly block each other
-- Tasks under 3 independent units of work
-- Simple file edits with no research needed
-
-## Team Configuration Patterns
-
-### Pattern 1: Research Team
-
-```
-Lead: build agent
-├── Teammate 1 (explore): Search codebase for existing patterns
-├── Teammate 2 (scout): Research external docs and best practices
-└── Teammate 3 (review): Analyze current implementation for issues
-```
-
-**Use when**: Entering unfamiliar territory, evaluating new libraries, understanding complex systems.
-
-### Pattern 2: Review Team
-
-```
-Lead: build agent
-├── Teammate 1 (review): Security audit
-├── Teammate 2 (review): Performance review
-└── Teammate 3 (review): Architecture review
-```
-
-**Use when**: Pre-merge review of significant features, security-sensitive changes.
-
-### Pattern 3: Competing Approaches
-
-```
-Lead: build agent
-├── Teammate 1 (general): Implement approach A
-├── Teammate 2 (general): Implement approach B
-└── Teammate 3 (general): Implement approach C
-```
-
-**Use when**: Multiple valid solutions exist and you need to compare empirically.
-
-### Pattern 4: Subsystem Team
-
-```
-Lead: build agent
-├── Teammate 1 (general): Handle frontend changes
-├── Teammate 2 (general): Handle backend changes
-└── Teammate 3 (general): Handle database migrations
-```
-
-**Use when**: Large features spanning multiple subsystems with clear boundaries.
-
-## Best Practices
-
-### Task Distribution
-
-1. **5-6 tasks per teammate maximum** - More than this degrades quality
-2. **Clear boundaries** - Each teammate should own distinct files/modules
-3. **Avoid file conflicts** - Never assign the same file to multiple teammates
-4. **Include verification** - Each task should include its own verification step
-
-### Coordination
-
-1. **Lead synthesizes** - Don't let teammates make final decisions; lead integrates
-2. **Regular check-ins** - Lead should review intermediate results, not just final
-3. **Fail fast** - If a teammate hits a blocker, escalate to lead immediately
-4. **Shared conventions** - Establish naming, formatting, and style before dispatching
-
-### Communication
-
-1. **Task descriptions should be self-contained** - Teammate shouldn't need to ask clarifying questions
-2. **Include context** - What files to read, what patterns to follow, what constraints exist
-3. **Specify output format** - What should the teammate report back?
-4. **Include acceptance criteria** - How does the lead know the task is done?
-
-## Implementation with OpenCode
-
-### Using the Task Tool (Current)
-
-```typescript
-// Spawn research team
-const codebaseAnalysis = Task({
-  subagent_type: "explore",
-  description: "Analyze auth patterns",
-  prompt: `Research authentication patterns in this codebase:
-    1. Find all auth-related files
-    2. Map the auth flow
-    3. Identify potential security issues
-    Report back: file list, flow diagram, issues found`,
-});
-
-const externalResearch = Task({
-  subagent_type: "scout",
-  description: "Research JWT best practices",
-  prompt: `Research current JWT best practices:
-    1. Token rotation patterns
-    2. Refresh token security
-    3. Common vulnerabilities
-    Report back: recommended patterns with code examples`,
-});
-
-const codeReview = Task({
-  subagent_type: "review",
-  description: "Review auth security",
-  prompt: `Security review of auth implementation:
-    1. Check token storage
-    2. Verify CSRF protection
-    3. Audit session management
-    Report back: vulnerabilities found with severity ratings`,
-});
-
-// Lead synthesizes all results into unified recommendation
-```
-
-### Using Swarm Coordination (Advanced)
-
-For more structured parallel work, combine with the `swarm-coordination` skill:
-
-```typescript
-// Load swarm for structured coordination
-skill({ name: "swarm-coordination" });
-
-// Analyze and plan
-swarm({ op: "plan", task: "Implement auth overhaul across 3 subsystems" });
-
-// Create delegation packets
-swarm({
-  op: "delegate",
-  bead_id: "auth-frontend",
-  title: "Frontend auth components",
-  outcome: "All auth forms and guards updated",
-  must_do: "Follow existing component patterns, run component tests",
-  must_not: "Don't modify API contracts, don't add new dependencies",
-});
-```
-
-## Anti-Patterns
-
-### ❌ Too Many Teammates
-
-```
-Lead
-├── T1: Button component     ← Too granular
-├── T2: Input component      ← Too granular
-├── T3: Form component       ← Too granular
-├── T4: Modal component      ← Too granular
-├── T5: Toast component      ← Too granular
-├── T6: Dialog component     ← Too granular
-├── T7: Dropdown component   ← Too granular
-└── T8: Tabs component       ← Too granular
-```
-
-**Fix**: Group related work. 2-3 teammates handling related components each.
-
-### ❌ Overlapping File Ownership
-
-```
-T1: Refactor auth service     ← Both touch auth.ts!
-T2: Add new auth endpoint     ← Both touch auth.ts!
-```
-
-**Fix**: One teammate owns auth.ts changes. The other waits or works on different files.
-
-### ❌ Missing Context
-
-```
-Task({ prompt: "Fix the auth bug" })  ← Which bug? What file? What behavior?
-```
-
-**Fix**: Include file paths, error messages, expected vs actual behavior, and reproduction steps.
-
-### ❌ No Verification
-
-```
-Task({ prompt: "Implement feature X" })  ← No way to verify success
-```
-
-**Fix**: Include acceptance criteria: "Run `npm test auth`, ensure all pass. Run `npm run typecheck`."
-
-## Checklist
-
-Before dispatching a team:
-
-- [ ] Identified 3+ independent tasks (otherwise use single agent)
-- [ ] Each task has clear file ownership (no overlaps)
-- [ ] Each task has self-contained context (files, patterns, constraints)
-- [ ] Each task has acceptance criteria (verification commands)
-- [ ] Lead has a synthesis plan (how to integrate results)
-- [ ] Tasks are sized appropriately (5-6 per teammate max)
-
-## See Also
-
-- `dispatching-parallel-agents` — for independent debugging-focused parallel investigations
-- `swarm-coordination` — for dependency-aware large-plan execution

package/dist/template/.opencode/skill/code-navigation/SKILL.md

@@ -1,142 +0,0 @@
----
-name: code-navigation
-description: Use when navigating unfamiliar code, tracing cross-file dependencies, or before editing — efficient code reading patterns that minimize tool calls and token waste
-version: 1.0.0
-tags: [workflow, code-quality, context]
-dependencies: []
-agent_types: [planner, worker, reviewer]
-tools: []
----
-
-# Code Navigation Skill
-
-## When to Use
-
-- Exploring an unfamiliar codebase or module
-- Tracing a function call across multiple files
-- Understanding blast radius before a breaking change
-- Planning edits that touch multiple files
-
-## When NOT to Use
-
-- Simple single-file edits where you already know the location
-- Reading config or documentation files
-
-## Core Principle
-
-> Collapse multiple tool calls into fewer, smarter ones. Every unnecessary read or search wastes tokens and turns.
-
-## Choose The Right Navigation Tool
-
-- Use `srcwalk_search`, `srcwalk_read`, `srcwalk_files`, `srcwalk_deps` for symbol search, file reading, glob finds, and blast-radius checks
-- Use `srcwalk_callers`, `srcwalk_callees`, `srcwalk_flow`, `srcwalk_impact`, `srcwalk_map` for call graphs, orientation slices, impact triage, and repo maps — these are first-class Pi tools, no separate skill load needed
-- All tools are backed by the installed `srcwalk` binary via the `srcwalk.ts` extension
-
-## Navigation Patterns
-
-### Pattern 1: Search First, Read Second
-
-**Wrong** (3-6 tool calls):
-```
-glob("*.ts") → read(file1) → "too big" → grep("functionName") → read(file2) → read(file3, section)
-```
-
-**Right** (1-2 tool calls):
-```
-grep("functionName", path: "src/") → read(exact_file, offset: line-10, limit: 30)
-```
-
-Start with search (`srcwalk_search` or grep fallback) to locate, then read only what you need.
-
-### Pattern 2: Multi-Symbol Search
-
-When tracing a call chain (A calls B calls C), search for all symbols together:
-```
-grep({ pattern: "functionA|functionB|functionC", path: "src/" })
-```
-
-Or use `srcwalk_callers` for structural caller detection, or `srcwalk_flow` for a combined callers+callees+resolves slice.
-
-### Pattern 3: Don't Re-Read What You've Already Seen
-
-**Anti-pattern**: Search returns full function body, then agent reads the same file again.
-
-If search results already show the code you need, work from that output. Only re-read when:
-- You need surrounding context (lines above/below the match)
-- You need the exact content for editing (verify before edit)
-- The search result was truncated
-
-### Pattern 4: Blast Radius Check (Before Breaking Changes)
-
-**WHEN**: Before renaming, removing, or changing the signature of an export.
-**SKIP**: When adding new code, fixing internal bugs, or reading.
-
-Steps:
-1. `srcwalk_deps(path: "src/file.ts")` — find importers and downstream users
-2. `srcwalk_callers({ symbol: "symbolName", scope: "src" })` — find call sites with optional depth/filter
-3. Review each caller to assess impact
-4. Plan edits from leaf callers inward (furthest dependencies first)
-
-### Pattern 5: Context Locality
-
-When editing a file, search results from the same directory/package are more likely relevant. Pass context when available:
-- In grep: use `path: "src/same-module/"` to scope
-- In srcwalk_search: pass `context` param to boost nearby results
-
-### Pattern 6: Outline Before Deep Read
-
-For large files (>200 lines), get the structure first:
-```
-srcwalk_read(path: "src/large-file.ts")
-```
-
-This gives you structure and line ranges. Then read only the section you need.
-
-### Pattern 7: Follow the Call Chain (Not the File Tree)
-
-**Wrong**: Read files top-to-bottom hoping to understand the flow.
-**Right**: Start from the entry point, follow function calls:
-
-```
-1. `srcwalk_search(query: "entryPoint")` → find where it is defined
-2. `srcwalk_callees({ symbol: "entryPoint", scope: "src" })` or `srcwalk_flow` for call graph orientation
-3. `srcwalk_read(section: "line-range")` → drill into the interesting callee
-```
-
-## With Srcwalk Backend
-
-All navigation tools are native srcwalk_* tools. Available tools:
-
-| Task | Tool | Notes |
-|---|---|---|
-| `grep` + `read` | `srcwalk_search(expand: 2)` | Returns definitions with inline source — no second read needed |
-| `glob` | `srcwalk_files` | Adds token estimates per file |
-| Large file read | `srcwalk_read` | Auto-outlines, shows structure |
-| Direct callers | `srcwalk_callers` | Structural call-site evidence |
-| Transitive callers | `srcwalk_callers(depth: N)` | Multi-hop BFS up to 5 |
-| Forward call graph | `srcwalk_callees(detailed: true)` | Ordered sites with arg slots |
-| Function orientation | `srcwalk_flow` | Callers + callees + resolves |
-| Import + dependents | `srcwalk_deps` | File-scoped import evidence + heuristic |
-| Heuristic triage | `srcwalk_impact` | Follow up with callers for proof |
-| Repo shape | `srcwalk_map` | Token budgets + directory skeleton |
-
-**IMPORTANT**: Prefer `srcwalk_*` tools over built-in grep/glob/read for code navigation. Their expanded search results often include full source — do NOT re-read files already shown in search output.
-
-## Cost Awareness
-
-Every tool call has a token cost. Efficient navigation means:
-- Fewer tool calls per task
-- Less context consumed by redundant reads
-- More budget available for actual implementation
-
-**Target**: Find and understand any symbol in ≤3 tool calls, not 6+.
-
-## Common Mistakes
-
-| Mistake | Fix |
-|---|---|
-| Read entire large file | Use outline first, then section read |
-| Search → read same code again | Work from search results directly |
-| Trace calls one-by-one | `srcwalk_callers` / `srcwalk_callees` or multi-symbol `srcwalk_search` |
-| Explore randomly | Start from entry point, follow calls |
-| Forget to check blast radius | Always check before signature changes |