opencodekit 0.23.2 → 0.23.4

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)

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

@@ -1,148 +0,0 @@
----
-description: Create and submit a pull request
-argument-hint: "[--draft]"
-agent: build
----
-
-# Pull Request
-
-## Load Skills
-
-```typescript
-skill({ name: "verification-before-completion" });
-```
-
-## Parse Arguments
-
-| Argument  | Default | Description        |
-| --------- | ------- | ------------------ |
-| `--draft` | false   | Create as draft PR |
-
-## Phase 1: Pre-PR Verification
-
-```bash
-git status --porcelain
-```
-
-If uncommitted changes exist, ask whether to commit first.
-
-All gates must pass before creating the PR.
-
-Check `package.json` scripts, `Makefile`, or `justfile` for project-specific commands first — prefer those over generic defaults.
-
-If any gate fails, stop. Fix errors first, then run `/pr` again.
-
-## Phase 2: Gather Context
-
-### Memory Grounding
-
-Search memory for relevant findings to include in the PR description.
-
-### Git Context
-
-```bash
-git branch --show-current
-git log main...HEAD --oneline
-git diff main...HEAD --stat
-```
-
-Read `.opencode/artifacts/$(cat .opencode/artifacts/.active)/spec.md` to extract goal and success criteria for the PR description.
-
-## Phase 2B: Pre-PR Review
-
-This is the last gate before code hits GitHub. Run it every time.
-
-Run **5 parallel agents** for review: security/correctness, performance/architecture, type-safety/tests, conventions/patterns, simplicity/completeness.
-
-```bash
-BASE_SHA=$(git rev-parse origin/main 2>/dev/null || git merge-base HEAD origin/main)
-HEAD_SHA=$(git rev-parse HEAD)
-```
-
-Fill placeholders:
-
-- `{WHAT_WAS_IMPLEMENTED}`: what this PR delivers (from git log summary)
-- `{PLAN_OR_REQUIREMENTS}`: PRD path or brief requirements
-- `{BASE_SHA}` / `{HEAD_SHA}`: from above
-
-**Gate rule:** All Critical issues must be resolved before pushing. No exceptions.
-Important issues: fix or document as known limitation in PR body.
-
-After fixing issues, re-run verification gates from Phase 1 if code was changed.
-
-## Phase 3: Push and Confirm
-
-Show what will be pushed and ask the user:
-
-```typescript
-question({
-  questions: [
-    {
-      header: "Push",
-      question: "Ready to push and create PR. Proceed?",
-      options: [
-        { label: "Push & create PR (Recommended)", description: "Push branch and create PR" },
-        { label: "Push & draft PR", description: "Create as draft for review" },
-        { label: "Show diff first", description: "Review changes before pushing" },
-      ],
-    },
-  ],
-});
-```
-
-If confirmed:
-
-```bash
-git push -u origin $(git branch --show-current)
-```
-
-## Phase 4: Create PR
-
-```bash
-# Verify gh CLI is installed
-command -v gh >/dev/null 2>&1 || { echo "Error: gh CLI not found. Install: https://cli.github.com"; exit 1; }
-
-gh pr create --title "<title>" --body "$(cat <<'EOF'
-## Summary
-
-[1-2 sentences: what this PR does and why]
-
-## Changes
-
-- `file.ts`: [what changed]
-- `other.ts`: [what changed]
-
-## Testing
-
-- All tests pass
-- Lint and typecheck pass
-- Manual verification: [how to test]
-
-## Checklist
-
-- [x] Tests added/updated
-- [x] All gates pass
-- [ ] Docs updated (if applicable)
-EOF
-)"
-```
-
-If `--draft`, add `--draft` flag.
-
-Add a link to `.opencode/artifacts/$(cat .opencode/artifacts/.active)/spec.md` for requirements context.
-
-## Output
-
-Report:
-
-1. PR URL
-2. Status (Ready for Review / Draft)
-3. Branch → main
-4. Gate results
-
-## Related Commands
-
-| Need         | Command        |
-| ------------ | -------------- |
-| Ship first   | `/ship <id>`   |
-| Verify first | `/verify <id>` |

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

@@ -1,65 +0,0 @@
----
-description: Refactor code for clarity, performance, or maintainability
-argument-hint: "<file or path> [--scope minimal|moderate|aggressive]"
-agent: build
----
-
-# Refactor: $ARGUMENTS
-
-Improve code quality without changing external behavior.
-
-## Load Skills
-
-```typescript
-skill({ name: "verification-before-completion" });
-```
-
-## Parse Arguments
-
-| Argument | Default | Description |
-|---|---|---|
-| `<file or path>` | required | File or directory to refactor |
-| `--scope` | minimal | `minimal` (rename/restructure), `moderate` (extract modules), `aggressive` (redesign) |
-
-## When to Refactor
-
-- Module has grown beyond its original purpose
-- Tests are hard to write because of tight coupling
-- Similar logic appears in multiple places
-- Files have crossed 300+ lines with unclear boundaries
-
-## Process
-
-### Phase 1: Assess
-
-1. Read all files in scope
-2. Identify: duplication, shallow interfaces, unclear naming, mixed concerns
-3. Plan the refactor — show plan if >3 files would change
-
-### Phase 2: Lock Behavior
-
-- If the module has tests, they must still pass after refactor
-- If no tests exist, run existing verification (typecheck, lint)
-- No behavior changes in a refactor — external API must be preserved
-
-### Phase 3: Execute
-
-- One change at a time, verify after each
-- Prefer small commits with clear messages
-- `refactor(scope): what changed`
-
-### Phase 4: Verify
-
-```bash
-npm run typecheck
-npm run lint
-npm test
-```
-
-## Output
-
-Report:
-1. What changed and why
-2. Files modified
-3. Verification results
-4. What was left for future refactors

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

@@ -1,128 +0,0 @@
----
-description: Review code for quality, security, and compliance
-argument-hint: "[path|pr-number|'all'] [--quick|--thorough]"
-agent: review
----
-
-# Review: $ARGUMENTS
-
-## Determine Input Type
-
-| Input Type            | Detection                    | Action                     |
-| --------------------- | ---------------------------- | -------------------------- |
-| No arguments          | Default                      | Review uncommitted changes |
-| Commit hash (40-char) | SHA pattern                  | `git show <hash>`          |
-| Branch name           | String, not matching above   | `git diff main...HEAD`     |
-| PR URL/number         | Contains "github.com" or "#" | `gh pr diff`               |
-| Current plan          | `.opencode/artifacts/$(cat .opencode/artifacts/.active)/spec.md`    | Review against spec        |
-
-## Before You Review
-
-- **Be certain**: Only flag issues you can verify with tools
-- **Don't invent problems**: If an edge case isn't specified, don't flag it
-- **Don't be a zealot about style**: Unless it violates project conventions, don't flag
-- **Review the changes**: Don't review pre-existing code that wasn't modified
-- **Investigate first**: If unsure, use explore/scout agents before flagging
-
-## Available Tools
-
-| Tool                 | Use When                                |
-| -------------------- | --------------------------------------- |
-| `explore`            | Finding patterns in codebase, prior art |
-| `scout`              | External research, best practices       |
-| `lsp`                | Finding symbol definitions, references  |
-| `srcwalk find`       | Finding code patterns                   |
-| `codesearch`         | Real-world usage examples               |
-
-## Phase 1: Gather Context
-
-```bash
-git status --short
-git diff --cached  # staged
-git diff           # unstaged
-```
-
-For each changed file:
-
-- Read the full file to understand context
-- Don't rely on diff alone — code that looks wrong in isolation may be correct
-
-If plan exists, read `.opencode/artifacts/$(cat .opencode/artifacts/.active)/spec.md` to review against spec.
-
-## Phase 2: Determine Scope
-
-| Input                    | Scope                 | How to Get Code           |
-| ------------------------ | --------------------- | ------------------------- |
-| File/directory path      | That path only        | `read` or `glob` + `read` |
-| Current plan             | Implementation vs spec | Read `.opencode/artifacts/$(cat .opencode/artifacts/.active)/spec.md` then `git diff` |
-| PR number (e.g., `#45`)  | PR changes            | `gh pr diff 45`           |
-| `all` or empty           | Recent changes        | `git diff main...HEAD`    |
-
-If plan exists, read `.opencode/artifacts/$(cat .opencode/artifacts/.active)/spec.md` to review against spec.
-
-## Phase 3: Automated Checks
-
-Use the `verification-before-completion` skill to run gates.
-
-Check `package.json` scripts, `Makefile`, or `justfile` for project-specific commands first — prefer those over generic defaults.
-
-Also scan for common issues appropriate to the detected language:
-
-- Debug statements (`console.log`, `print()`, `println!`, `fmt.Println`)
-- Loose typing (`any` in TypeScript, `type: ignore` in Python)
-- `TODO|FIXME|HACK` markers
-- Hardcoded secrets patterns
-
-## Phase 4: Manual Review
-
-Review each category:
-
-| Category            | Focus                                                                   |
-| ------------------- | ----------------------------------------------------------------------- |
-| **Security**        | Auth checks, input validation, no secrets in code, injection prevention |
-| **Performance**     | N+1 queries, unbounded loops, missing pagination, hot path ops          |
-| **Maintainability** | Complexity, DRY violations, dead code, naming clarity                   |
-| **Error Handling**  | Async error handling, error context, sanitized user errors              |
-| **Testing**         | Coverage on changed code, behavior tests, edge cases                    |
-| **Type Safety**     | No unjustified `any`, null handling, explicit return types              |
-
-**Depth levels:**
-
-- `--quick`: Automated checks + skim, critical issues only
-- Default: Full automated + manual review
-- `--thorough`: Deep analysis of all categories
-
-## Phase 5: Report
-
-Group findings by severity:
-
-- **Critical** (must fix before merge): with file:line, issue, fix
-- **Important** (should fix): with file:line, issue, fix
-- **Minor** (nice to have): with file:line, suggestion
-
-Include:
-
-1. Summary metrics (files reviewed, issues by severity)
-2. Strengths (what's done well, with file:line)
-3. Verdict: Ready to merge / With fixes / No
-4. Reasoning (1-2 sentences)
-
-Record significant findings with `observation()`:
-
-```typescript
-observation({
-  type: "discovery", // or "warning", "pattern", "bugfix"
-  title: "Review: [scope] [key finding]",
-  narrative: "[What was found, severity, file:line, recommended fix]",
-  concepts: "code-review, [category]",
-  confidence: "high",
-});
-```
-
-## Related Commands
-
-| Need                | Command        |
-| ------------------- | -------------- |
-| Ship after review   | `/ship <id>`   |
-| Verify completeness | `/verify <id>` |
-| Check status        | `/status`      |