opencodekit 0.23.3 → 0.23.4

package/dist/template/.opencode/workflows/deep-research.md

@@ -0,0 +1,58 @@
+# deep-research
+
+Fan out web searches across multiple angles on a question, cross-check sources for contradictions, and produce a cited report with confidence levels. Use when you need multi-source verification or current-events coverage.
+
+## Args
+
+- `question` (required) — The research question or topic
+
+## Phases
+
+### Phase 1: research
+
+- **Agent:** @scout
+- **Concurrency:** Dynamic (1 agent per distinct angle, min 3, max 10)
+- **Prompt:**
+
+Search for different perspectives on the question: {question}. Cover opposing viewpoints, authoritative sources, and recent developments. For each finding, include the URL and publication date. Return findings grouped by angle in this format:
+
+## Angle: [angle name]
+- **Finding:** [summary]
+- **Source:** [URL]
+- **Date:** [publication date]
+- **Confidence:** [high/medium/low]
+
+Keep each finding under 200 words.
+
+### Phase 2: cross-check
+
+- **Depends on:** Phase 1
+- **Agent:** @review
+- **Concurrency:** Dynamic (estimate ~5 findings per agent, min 2, max 10)
+- **Prompt:**
+
+Cross-check these findings: {phase_1_output}. Flag contradictions between sources, identify confirmable facts with supporting citations, and note where sources disagree or lack evidence. Return a verified fact set in this format:
+
+## Verified Facts
+- **Fact:** [statement]
+- **Confidence:** [high/medium/low]
+- **Supporting sources:** [list of URLs]
+
+## Contradictions
+- **Claim A:** [statement]
+- **Claim B:** [contradicting statement]
+- **Resolution:** [which is more credible and why]
+
+Keep each item under 150 words.
+
+## Final Synthesis (Main Agent)
+
+After Phase 2 completes, synthesize the final report directly from {phase_2_output}.
+
+Write a final cited report using markdown with sections:
+1. **Executive Summary** — Brief overview of key findings
+2. **Key Findings** — Detailed findings with inline citations
+3. **Contradictions & Uncertainties** — Areas of disagreement or low confidence
+4. **Sources** — Complete list of all sources consulted
+
+Annotate each claim with confidence level (high/medium/low). Keep the report under 2000 words.

package/dist/template/.opencode/workflows/development-lifecycle-workflow.md

@@ -0,0 +1,129 @@
+# development-lifecycle-workflow
+
+Multi-agent workflow that chains the development lifecycle phases with parallelism. Uses specialized agents (scouts, reviewers, planners) and composes with the batch-implement workflow for parallel implementation.
+
+## Args
+
+- `feature` (required) — The feature or change to implement
+
+## Phases
+
+### Phase 1: Research Approaches
+
+- **Agent:** @scout
+- **Concurrency:** Dynamic (1 agent per approach, min 2, max 5)
+- **Prompt:**
+
+Research different approaches to implementing: {feature}. For each approach, analyze:
+1. Technical feasibility
+2. Trade-offs and risks
+3. Implementation complexity
+4. Dependencies and constraints
+
+Return findings in this format:
+
+## Approach 1: [name]
+- **Description:** [summary]
+- **Pros:** [list]
+- **Cons:** [list]
+- **Complexity:** [low/medium/high]
+- **Risks:** [list]
+
+Keep each approach under 300 words.
+
+### Phase 2: Validate Requirements
+
+- **Depends on:** Phase 1
+- **Agent:** @review
+- **Concurrency:** Dynamic (1 agent per approach, min 1, max 5)
+- **Prompt:**
+
+Review these approaches: {phase_1_output}. Validate the requirements and constraints for each approach. Check for:
+1. Technical accuracy
+2. Feasibility given project constraints
+3. Alignment with existing patterns
+4. Missing considerations
+
+Return validated requirements in this format:
+
+## Validated Requirements
+- **Approach 1:** [validated requirements]
+- **Approach 2:** [validated requirements]
+- **Approach 3:** [validated requirements]
+
+## Recommendations
+- **Recommended approach:** [which approach and why]
+- **Critical constraints:** [list]
+
+Keep each section under 200 words.
+
+### Phase 3: Create Implementation Plan
+
+- **Depends on:** Phase 2
+- **Agent:** @plan
+- **Concurrency:** 1
+- **Prompt:**
+
+Based on the validated requirements: {phase_2_output}, create a detailed implementation plan for the recommended approach. Break down into independent tasks that can be implemented in parallel.
+
+Return the plan in this format:
+
+## Implementation Plan
+
+### Overview
+[Brief description of the approach]
+
+### Tasks
+- **Task 1:** [description]
+  - Files: [list]
+  - Dependencies: [none or task names]
+- **Task 2:** [description]
+  - Files: [list]
+  - Dependencies: [none or task names]
+
+Keep each task description under 100 words.
+
+### Phase 4: Parallel Implementation
+
+- **Depends on:** Phase 3
+- **Workflow:** batch-implement
+- **Args:** plan from Phase 3
+
+Execute the batch-implement workflow with the implementation plan from Phase 3. This will:
+1. Review the plan for task independence
+2. Implement tasks in parallel
+3. Verify each implementation
+4. Merge the results
+
+### Phase 5: Verify Different Aspects
+
+- **Depends on:** Phase 4
+- **Agent:** @review
+- **Concurrency:** 3 (one per aspect: correctness, code-quality, performance-security)
+- **Prompt:**
+
+Verify the implementation from different aspects: {phase_4_output}. Each reviewer should focus on a different aspect:
+
+**Reviewer 1: Correctness**
+- Verify all requirements are met
+- Check for logic errors
+- Validate edge cases
+
+**Reviewer 2: Code Quality**
+- Check for code style and patterns
+- Identify code smells
+- Verify test coverage
+
+**Reviewer 3: Performance & Security**
+- Check for performance bottlenecks
+- Identify security vulnerabilities
+- Validate error handling
+
+Return findings in this format:
+
+## Aspect: [correctness/code-quality/performance-security]
+- **Status:** [pass/fail]
+- **Issues:** [list with file:line refs]
+- **Recommendations:** [list]
+
+Keep each finding under 150 words.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "opencodekit",
-  "version": "0.23.3",
+  "version": "0.23.4",
   "description": "CLI tool for bootstrapping and managing OpenCodeKit projects",
   "keywords": [
     "agents",

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

@@ -1,46 +0,0 @@
----
-description: Reduce ambiguity before planning or implementation
-argument-hint: "<request> [--quick|--deep]"
-agent: build
----
-
-# Clarify: $ARGUMENTS
-
-Reduce ambiguity before planning or implementation. Use when the request is real but still fuzzy.
-
-## Load Skills
-
-```typescript
-skill({ name: "brainstorming" });
-```
-
-## Parse Arguments
-
-| Argument | Default | Description |
-|---|---|---|
-| `<request>`            | required | Freeform request text                     |
-| `--quick` | false | Minimize to 1-3 high-leverage questions |
-| `--deep` | false | Cover non-goals, risks, interfaces, success criteria |
-
-**Mode rules:** Default → make next command obvious. `--quick` → 1-3 questions. `--deep` → exhaustive. `--deep` wins if both appear.
-
-## When to Use / Not Use
-
-**Use:** Request is fuzzy, scope unclear, multiple interpretations of "done," `/plan` would be premature because main decision is unresolved.  
-**Skip:** Request is specific enough to plan directly, task is mechanical, ambiguity is only about codebase facts you can inspect.
-
-## Core Rules
-
-- **Inspect first, ask second** — never ask for codebase facts you can discover directly
-- **One question at a time** — each must reduce a real ambiguity
-- **Prefer structured choices** (multiple choice, yes/no)
-- **Surface non-goals explicitly** — what should *not* change is as important as what should
-- **Stop once the next command is obvious**
-
-## Process
-
-1. Read request, identify unknowns blocking execution
-2. Search memory, check existing patterns
-3. Ask questions one at a time, resolve before next
-4. Surface non-goals and constraints
-5. Recommend next command: `/plan`, `/create`, `/ship`, or `/design`

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

@@ -1,53 +0,0 @@
----
-description: Create a well-structured conventional commit from staged or unstaged changes
-argument-hint: "[--all] [--amend] [message override]"
-agent: build
----
-
-# Commit: $ARGUMENTS
-
-Create a well-structured conventional commit from current changes.
-
-## Load Skills
-
-```typescript
-skill({ name: "verification-before-completion" });
-```
-
-## Process
-
-### Phase 1: Inspect Changes
-
-```bash
-git status --short
-git diff --cached --stat   # if staged
-git diff --stat            # if unstaged
-```
-
-### Phase 2: Review Diffs
-
-Read each changed file. Look for:
-- Debug code, console.log, TODOs that should be resolved
-- Accidental changes outside scope
-- Missing error handling or edge cases
-
-### Phase 3: Construct Commit
-
-Format: `type(scope): description`
-
-Types: `feat` (feature), `fix` (bug), `test` (test-only), `refactor` (no behavior change), `chore` (config/tooling), `docs`, `style`, `perf`.
-
-### Phase 4: Commit
-
-```bash
-git add <files>    # stage specific files — never git add .
-git commit -m "type(scope): description
-
-- bullet points of key changes"
-```
-
-### Phase 5: Verify
-
-```bash
-git log --oneline -3
-```

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

@@ -1,129 +0,0 @@
----
-description: UI/UX visual design with aesthetic direction and code output
-argument-hint: "<component|page|system> [topic] [--quick]"
-agent: vision
----
-
-# Design: $ARGUMENTS
-
-Design a component, page, or design system with a clear aesthetic point of view.
-
-> **Design track (optional):** Not part of the core `/create → /ship` workflow.
-> Use when you need visual design guidance before or during implementation.
-
-## Parse Arguments
-
-| Argument    | Default  | Description                                 |
-| ----------- | -------- | ------------------------------------------- |
-| `component` | —        | Design a specific component                 |
-| `page`      | —        | Design a page layout                        |
-| `system`    | —        | Create or extend a design system            |
-| `[topic]`   | required | What to design (e.g. "button", "dashboard") |
-| `--quick`   | false    | High-level direction only, skip code        |
-
-## Load Skills
-
-```typescript
-skill({ name: "frontend-design" }); // Design system guidance, anti-patterns, references
-```
-
----
-
-## Phase 1: Detect Existing Design System
-
-```bash
-srcwalk files "**/tailwind.config.{js,ts,mjs}"
-srcwalk files "**/globals.css"
-srcwalk files "**/components.json"  # shadcn
-```
-
-Read what exists. Don't design in a vacuum — build on the project's current system.
-
----
-
-## Phase 2: Check Memory
-
-```typescript
-memory - search({ query: "[topic] design UI", limit: 3 });
-memory - search({ query: "design system colors typography", limit: 3 });
-```
-
-Reuse existing aesthetic decisions. Don't contradict previous design choices unless the user asks.
-
----
-
-## Phase 3: UX Structure Decisions
-
-Before visual design, define the interaction structure. A beautiful screen with unclear scope, weak recovery, or missing states is still failed design.
-
-State these decisions explicitly:
-
-1. **Primary action** — the one dominant action for the component/page/flow
-2. **User-facing vocabulary** — entity/action names the UI will use consistently
-3. **Scope and relationships** — what this UI affects, where the user is, and what related objects matter
-4. **Dangerous actions** — destructive/bulk/account/security actions and their confirm/undo/recovery pattern
-5. **State model** — empty, loading, error, success, disabled, and optimistic states required
-6. **Pattern selection** — form, table/list/grid, notification, modal, or navigation pattern if applicable
-
-Keep these decisions concrete and explicit.
-
----
-
-## Phase 4: Design
-
-The `frontend-design` skill provides all reference material:
-
-- Aesthetic directions and design philosophy
-- Typography and font pairing guidance
-- Color systems (OKLCH)
-- Animation patterns (Motion + Tailwind)
-- Anti-patterns and AI slop avoidance
-- shadcn/ui component patterns
-- Tailwind v4 configuration
-
-**Before designing, state:**
-
-1. **Aesthetic direction** — which style and why
-2. **Key characteristics** — 3 specific elements you'll apply
-3. **UX gates satisfied** — primary action, states, recovery, and accessibility baseline
-
-Then produce the design:
-
-| Task Type   | Output                                |
-| ----------- | ------------------------------------- |
-| `component` | Spec (variants, sizes, states) + code |
-| `page`      | Layout structure + section breakdown  |
-| `system`    | Tokens (CSS variables) + guidelines   |
-
-For `--quick`: Skip code output. Provide direction + key decisions only.
-
----
-
-## Phase 5: Record Decision
-
-```typescript
-observation({
-  type: "decision",
-  title: "Design: [topic]",
-  narrative: "Chose [direction] because [rationale]. Key tokens: [colors, fonts].",
-  concepts: "design, ui, [topic]",
-  confidence: "high",
-});
-```
-
----
-
-## Examples
-
-```bash
-/design component button           # Full component design with code
-/design page landing --quick       # High-level page direction only
-/design system                     # Create/extend design system tokens
-```
-
-## Related Commands
-
-| Need               | Command        |
-| ------------------ | -------------- |
-| Review existing UI | `/ui-review`   |
-| Ship it            | `/ship <bead>` |

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

@@ -1,169 +0,0 @@
----
-description: Think through an idea with structured alternatives before committing to a change
-argument-hint: "<idea or question>"
-agent: plan
----
-
-# Explore: $ARGUMENTS
-
-Think through an idea, problem, or approach with structured alternatives and tradeoffs — before committing to a plan.
-
-> **Workflow:** **`/explore`** → `/create` (if worth pursuing) or discard
->
-> Use when you're not sure WHAT to build or HOW to approach it. This is ideation with rigor, not open-ended brainstorming.
->
-> **When to use:** Before `/create`, when the approach isn't obvious. Skip for clear, well-scoped work.
-
-## Load Skills
-
-```typescript
-skill({ name: "brainstorming" }); // Collaborative refinement
-```
-
-## Phase 1: Ground
-
-Search for prior art and past decisions:
-
-```typescript
-memory_search({ query: "<topic keywords>", limit: 5 });
-```
-
-```bash
-# What exists in the codebase already?
-git log --oneline -20 | grep -i "<keyword>"
-```
-
-Spawn an explore agent to understand the current state:
-
-```typescript
-task({
-  subagent_type: "explore",
-  description: "Map existing patterns for this area",
-  prompt: `Search the codebase for existing implementations, patterns, and conventions related to: $ARGUMENTS
-
-  Return: what exists today, what patterns are used, what files are involved.`,
-});
-```
-
-## Phase 2: Frame the Problem
-
-Before proposing solutions, state the problem clearly:
-
-1. **What's the goal?** (outcome, not task)
-2. **What constraints exist?** (tech stack, time, compatibility, user preferences)
-3. **What's the risk of doing nothing?** (is this urgent or nice-to-have?)
-
-If the problem isn't clear after reading context, ask the user to clarify — but max 2 questions.
-
-## Phase 3: Generate Alternatives
-
-Produce 2-3 approaches. For each:
-
-| Aspect       | What to Cover                          |
-| ------------ | -------------------------------------- |
-| **Approach** | 1-2 sentence summary                   |
-| **How**      | Key implementation steps (3-5 bullets) |
-| **Pros**     | What this gets right                   |
-| **Cons**     | What this gets wrong or makes harder   |
-| **Effort**   | S (<1h), M (1-3h), L (1-2d), XL (>2d)  |
-| **Risk**     | What could go wrong                    |
-
-**Rules for alternatives:**
-
-- At least one must be the simplest viable option
-- At least one must be different in kind, not just degree (different architecture, not just different library)
-- Don't pad with bad options to make the recommended one look good
-
-## Phase 4: Recommend
-
-Pick one approach and explain why:
-
-```markdown
-## Recommendation
-
-**Approach:** [Name]
-**Effort:** [S/M/L/XL]
-**Why:** [2-3 sentences — why this over the others]
-**When to reconsider:** [What signals would make you switch to an alternative]
-```
-
-## Phase 5: Output Proposal
-
-Write the proposal as a structured document:
-
-```markdown
-# Exploration: [Topic]
-
-## Problem
-
-[What we're trying to solve]
-
-## Constraints
-
-- [Constraint 1]
-- [Constraint 2]
-
-## Alternatives
-
-### Option A: [Name]
-
-- **How:** ...
-- **Pros:** ...
-- **Cons:** ...
-- **Effort:** S/M/L/XL
-
-### Option B: [Name]
-
-- **How:** ...
-- **Pros:** ...
-- **Cons:** ...
-- **Effort:** S/M/L/XL
-
-### Option C: [Name] (if applicable)
-
-...
-
-## Recommendation
-
-**Option [X]** because [reasoning].
-**Reconsider if:** [triggers for switching]
-
-## Next Step
-
-`/create "[description based on chosen approach]"`
-```
-
-**If a plan exists:** Save to `.opencode/artifacts/$(cat .opencode/artifacts/.active)/research.md`
-**If no plan:** Display inline, don't create files.
-
-## Phase 6: Ask User
-
-Present the proposal and ask:
-
-```typescript
-question({
-  questions: [
-    {
-      header: "Approach",
-      question: "Which approach do you want to pursue?",
-      options: [
-        { label: "Option A (Recommended)", description: "[brief]" },
-        { label: "Option B", description: "[brief]" },
-        { label: "Option C", description: "[brief]" },
-        { label: "None — need more research", description: "Spawn scout agents" },
-      ],
-    },
-  ],
-});
-```
-
-If user picks an approach → suggest `/create "[description]"` with the chosen approach baked in.
-If user wants more research → spawn `@scout` for the specific unknowns.
-
-## Related Commands
-
-| Need                      | Command                             |
-| ------------------------- | ----------------------------------- |
-| Commit to an approach     | `/create`                           |
-| Research external options | `/research`                         |
-| Open-ended ideation       | Load `brainstorming` skill directly |

package/dist/template/.opencode/command/improve-architecture.md

@@ -1,55 +0,0 @@
----
-description: Proactive architecture health check — find shallow modules, propose deep-module redesigns
-argument-hint: "[path|module|'all'] [--scope surface|deep]"
-agent: review
----
-
-# Improve Architecture: $ARGUMENTS
-
-Proactive architecture health check. Find shallow modules and propose deep-module redesigns.
-
-## Load Skills
-
-```typescript
-skill({ name: "deep-module-design" });
-skill({ name: "verification-before-completion" });
-```
-
-## Architecture Check
-
-Apply Ousterhout's deep module principles:
-- **Small interface** — does this module expose more than it should?
-- **Information hiding** — are implementation details leaking?
-- **Pull complexity downward** — are callers doing work the module should own?
-
-## Process
-
-### Phase 1: Scan
-
-If path given, focus on that directory. If `all`, scan the full project.
-
-For each module, assess:
-- Lines of interface vs lines of implementation
-- Number of callers and how they use it
-- What knowledge is embedded but not encapsulated
-- What would break if the module were redesigned
-
-### Phase 2: Propose
-
-For each finding:
-
-| Module | Issue | Proposed Redesign | Effort | Risk |
-|---|---|---|---|---|
-| path/to/module | Shallow interface exposing internals | Encapsulate behind 3 functions | M | Low |
-
-### Phase 3: Prioritize
-
-Rank proposals by impact/effort ratio. Recommend top 1-3 changes worth making.
-
-## Output
-
-Report:
-1. Modules reviewed
-2. Findings (current issue, proposed redesign, effort, risk)
-3. Top recommendations
-4. Quick wins (S-effort changes)