opencodekit 0.21.10 → 0.22.0

package/dist/template/.opencode/skill/ux-quality-gates/SKILL.md

@@ -1,137 +0,0 @@
----
-name: ux-quality-gates
-description: Use when designing, reviewing, planning, or shipping user-facing UI where UX correctness matters — applies information architecture, usability heuristics, forms, recovery, loading states, semantic HTML, and component consistency checks.
-version: 1.0.0
-tags: [ui, design, code-quality]
-dependencies: []
----
-
-# UX Quality Gates
-
-## Overview
-
-UX quality is not visual polish. A screen passes only when users can understand scope, complete the primary task, recover from errors, and use it with keyboard/screen reader support.
-
-This skill consolidates high-signal UX review patterns into gates for `/design`, `/ui-review`, `/ui-slop-check`, `/plan`, and `/ship`.
-
-## When to Use
-
-- Designing or reviewing user-facing components, pages, dashboards, forms, or flows.
-- Planning UI PRDs that include loading, error, empty, success, destructive, or async states.
-- Auditing changed UI files before shipping.
-- Checking enterprise/data-heavy UIs with selection, bulk actions, filters, or tables.
-
-## When NOT to Use
-
-- Backend-only work.
-- Pure visual asset generation with no interaction or user flow.
-- Trivial copy/color tweaks where no behavior, state, or structure changes.
-
-## Core Gates
-
-| Gate                     | Pass Condition                                                              | Failure Signals                                                                  |
-| ------------------------ | --------------------------------------------------------------------------- | -------------------------------------------------------------------------------- |
-| Information architecture | UI names match user vocabulary; scope and relationships are visible         | Engineer terms, mixed synonyms, hidden side effects                              |
-| Primary action           | One dominant action per view/section                                        | Multiple filled buttons, equal cancel/confirm, destructive action beside primary |
-| Forms                    | Label, helper, validation, and error wiring are explicit                    | Placeholder-as-label, errors not associated, disabled submit hiding issues       |
-| Recovery                 | Every failure path offers retry, undo, fallback, or support                 | Dead-end errors, disappearing error toasts, no rollback for optimistic UI        |
-| State coverage           | Empty/loading/error/success states exist and match final layout             | Global spinner, mismatched skeleton, no no-results state                         |
-| Accessibility            | WCAG 2.2 AA baseline, keyboard path, focus, semantic HTML                   | No skip path, focus trap, unlabeled controls, ARIA replacing native HTML         |
-| Semantic web             | Correct landmarks/headings/native controls; SEO only when page is indexable | Div buttons, multiple h1s, missing route focus/scroll handling                   |
-| Component family         | Shared token DNA across related components                                  | One-off radius/color/height/shadow, inconsistent focus/error states              |
-
-## Usability Heuristic Pass
-
-Check every UI against these ten questions:
-
-1. **System status** — Does the UI show what is happening now?
-2. **Real-world language** — Does copy use user vocabulary, not implementation terms?
-3. **User control** — Can users cancel, undo, go back, or recover?
-4. **Consistency** — Are names, controls, and patterns reused consistently?
-5. **Error prevention** — Are dangerous or invalid actions prevented before they happen?
-6. **Recognition over recall** — Are options, context, and relationships visible?
-7. **Efficiency** — Are shortcuts or bulk actions available where volume requires them?
-8. **Minimalism** — Is each visible element serving the current task?
-9. **Error recovery** — Does error copy say what happened, why, and how to fix it?
-10. **Help** — Is guidance present where users may be stuck?
-
-## Pattern Rules
-
-### Destructive Actions
-
-Require confirmation for permanent deletion, bulk destructive actions, permission/security changes, billing/account scope changes, and irreversible workflow transitions.
-
-Confirmation anatomy:
-
-- Title names the entity/action specifically.
-- Body lists concrete consequences.
-- Primary label is explicit, e.g. `Delete project`, not `OK` or `Yes`.
-- Cancel is easy and default-focused.
-- Highest-risk actions require typing the entity name.
-
-Prefer undo for low-stakes reversible actions.
-
-### Forms
-
-- Labels are always visible; placeholders are examples only.
-- Helper text explains expected input or consequences.
-- Validate on blur by default; use debounced real-time validation for complex fields.
-- Submit catches all errors and moves focus/scroll to the first error.
-- Use `aria-describedby`, `aria-invalid`, and `role="alert"` for errors.
-- Required/optional marker shows the minority case.
-- Use correct `type`, `autocomplete`, `fieldset`, and `legend`.
-- Disable submit only for short forms where all validity is visible; otherwise allow submit and show errors.
-
-### Loading and Async States
-
-| Wait | Pattern                                      |
-| ---- | -------------------------------------------- |
-| <1s  | Inline spinner or optimistic update          |
-| 1-3s | Skeleton matching final layout               |
-| >3s  | Determinate/progressive status when possible |
-
-- Button loading prevents duplicate submit without shifting layout.
-- Skeletons are recessive and match final dimensions.
-- Optimistic updates must have rollback.
-- Error toasts persist until dismissed or replaced by a visible recovery path.
-
-### Notifications and Recovery
-
-- Success toast: auto-dismiss after 4-6s unless action is needed.
-- Error toast/banner: persists until resolved or dismissed.
-- Toasts have at most one action.
-- Inline errors live beside the affected control.
-- Failed sections degrade locally instead of blanking the whole app.
-- Transient failures get retry; repeated failures escalate to support or alternative path.
-
-### Data Display and Selection
-
-Use for data-heavy UIs only:
-
-- Offer grid/list/table only when each view changes task value.
-- Persist view choice when useful.
-- Selection supports row/card click, checkbox indicator, keyboard Space, and range selection where expected.
-- Bulk action toolbar shows selected count.
-- Destructive bulk actions name the count and scope.
-- Distinguish filtered no-results from genuinely empty state.
-- Tables may need sticky headers/first column, row actions, and resize/reorder for enterprise density.
-
-## Review Output
-
-When reporting findings, include:
-
-- Gate name.
-- Severity: Critical, Warning, or Info.
-- Location with `file:line` when reviewing code.
-- User impact.
-- Concrete fix.
-
-## Common Mistakes
-
-| Mistake                                 | Fix                                                              |
-| --------------------------------------- | ---------------------------------------------------------------- |
-| Treating UX as aesthetics               | Check task completion, recovery, and state coverage first        |
-| Adding every UX rule to every task      | Apply data/table/SEO rules only when relevant                    |
-| Using ARIA to patch non-semantic markup | Prefer native elements, add ARIA only when semantics are missing |
-| Making errors transient                 | Persistent errors need persistent recovery                       |
-| Importing many overlapping skills       | Use this consolidated gate and existing design/a11y skills       |

package/dist/template/.opencode/skill/v1-run/SKILL.md

@@ -1,175 +0,0 @@
----
-name: v1-run
-description: Use when selecting npm packages, checking for vulnerabilities, comparing alternatives, or verifying package health scores. MUST load before recommending or evaluating npm dependencies. Requires network.
-version: 1.0.0
-tags: [integration, mcp, research]
-dependencies: []
----
-
-# v1.run MCP
-
-## When to Use
-
-- When you need real-time npm package health, vulnerabilities, or comparisons.
-
-## When NOT to Use
-
-- When package selection or security analysis is not in scope.
-
-
-## Overview
-
-v1.run is an MCP-first npm registry by Midday.ai that provides:
-
-- **Real-time version data** - No hallucinated packages
-- **Security vulnerabilities** - From OSV database
-- **Health scores** - Automated 0-100 scoring
-- **Package comparisons** - 50+ pre-built categories
-
-## MCP Endpoint
-
-**URL**: `https://api.v1.run/mcp`
-
-**Authentication**: None required (public API)
-
-## Configuration
-
-v1.run MCP is pre-configured as a skill. Load it with:
-
-```typescript
-skill({ name: "v1-run" });
-```
-
-### Manual Setup (if needed)
-
-```json
-{
-  "mcpServers": {
-    "v1": {
-      "url": "https://api.v1.run/mcp"
-    }
-  }
-}
-```
-
-## Available Tools
-
-| Tool                    | Description                                                                                                       |
-| ----------------------- | ----------------------------------------------------------------------------------------------------------------- |
-| `get_package_health`    | Comprehensive health assessment (primary tool) - version, vulns, score, downloads, TS support, AI recommendations |
-| `get_package_version`   | Get latest version of a package                                                                                   |
-| `check_deprecated`      | Check if package is deprecated + get alternatives                                                                 |
-| `check_types`           | Check TypeScript support (bundled or @types)                                                                      |
-| `check_vulnerabilities` | Security vulnerabilities from OSV database                                                                        |
-| `find_alternatives`     | Find alternative packages with recommendations                                                                    |
-| `compare_packages`      | Side-by-side comparison (2-5 packages)                                                                            |
-
-## Health Score System
-
-Packages are scored 0-100 based on:
-
-| Factor      | Weight | Measures                                |
-| ----------- | ------ | --------------------------------------- |
-| Downloads   | 20%    | Weekly downloads + trend direction      |
-| Bundle Size | 20%    | Smaller gzip = higher score             |
-| Freshness   | 25%    | Recent commits and releases             |
-| Community   | 10%    | Stars, contributors                     |
-| Quality     | 25%    | TypeScript, ESM, security, tree-shaking |
-
-## Usage Examples
-
-### Check Package Health
-
-```typescript
-// Get comprehensive health info for a package (primary tool)
-skill_mcp({ skill_name: "v1-run", tool_name: "get_package_health", arguments: '{"name": "zod"}' });
-```
-
-Response includes:
-
-- Latest version
-- Known vulnerabilities (CVEs)
-- Health score (0-100) with grade
-- Weekly downloads + trend
-- TypeScript support
-- Maintenance status
-- AI recommendation
-
-### Check for Deprecation
-
-```typescript
-// Check if package is deprecated and get alternatives
-skill_mcp({
-  skill_name: "v1-run",
-  tool_name: "check_deprecated",
-  arguments: '{"name": "request"}',
-});
-```
-
-### Check Vulnerabilities
-
-```typescript
-// Check specific version for security issues
-skill_mcp({
-  skill_name: "v1-run",
-  tool_name: "check_vulnerabilities",
-  arguments: '{"name": "lodash", "version": "4.17.20"}',
-});
-```
-
-### Find Alternatives
-
-```typescript
-// Find alternative packages
-skill_mcp({
-  skill_name: "v1-run",
-  tool_name: "find_alternatives",
-  arguments: '{"name": "moment"}',
-});
-```
-
-### Compare Packages
-
-```typescript
-// Compare similar packages (2-5 packages)
-skill_mcp({
-  skill_name: "v1-run",
-  tool_name: "compare_packages",
-  arguments: '{"packages": ["zod", "yup", "joi", "valibot"]}',
-});
-```
-
-## Pre-built Categories (50+)
-
-v1.run includes comparisons for popular package categories:
-
-- **HTTP clients**: axios, got, ky, node-fetch
-- **Date libraries**: moment, date-fns, dayjs, luxon
-- **Validation**: zod, yup, joi, ajv, valibot
-- **State management**: redux, zustand, jotai, recoil
-- **ORM**: prisma, drizzle, typeorm, sequelize
-- **Testing**: vitest, jest, mocha, ava
-- **Bundlers**: vite, esbuild, webpack, rollup
-- **Logging**: pino, winston, bunyan
-
-## When to Use
-
-Use v1.run MCP when:
-
-1. **Choosing between packages** - Get objective comparisons
-2. **Checking for vulnerabilities** - Before adding dependencies
-3. **Evaluating maintenance** - Is the package actively maintained?
-4. **Finding alternatives** - Discover better options for a package
-
-## Best Practices
-
-1. **Always check health** before adding new dependencies
-2. **Compare alternatives** when multiple packages solve the same problem
-3. **Verify TypeScript support** for TypeScript projects
-4. **Check bundle size** for frontend applications
-
-## Documentation
-
-- [v1.run](https://v1.run)
-- [GitHub: midday-ai/v1](https://github.com/midday-ai/v1)
-- [MCP Documentation](https://modelcontextprotocol.io)

package/dist/template/.opencode/skill/v1-run/mcp.json

@@ -1,6 +0,0 @@
-{
-	"v1": {
-		"command": "npx",
-		"args": ["-y", "mcp-remote", "https://api.v1.run/mcp"]
-	}
-}

package/dist/template/.opencode/skill/verification-gates/SKILL.md

@@ -1,63 +0,0 @@
----
-name: verification-gates
-description: >
-  Use when running pre-merge or pre-PR verification checks. Detects project type and runs appropriate build, test, lint, and typecheck commands.
-version: 1.0.0
-tags: [verification, testing, lint, typecheck, ci]
----
-
-# Verification Gates
-
-Detect project type and run the appropriate verification commands before merging or creating PRs.
-
-## When to Use
-
-- In `/pr` before creating a pull request
-- In `/review-codebase` during automated checks phase
-- In `/ship` during final verification
-- Any command that needs to verify code quality before completion
-
-## When NOT to Use
-
-- For incremental checks during development (just run the specific tool)
-- When only one check type is needed (e.g., lint-only)
-
-## Project Type Detection
-
-| Project Type    | Detect Via                    | Build            | Test            | Lint                          | Typecheck                             |
-| --------------- | ----------------------------- | ---------------- | --------------- | ----------------------------- | ------------------------------------- |
-| Node/TypeScript | `package.json`                | `npm run build`  | `npm test`      | `npm run lint`                | `npm run typecheck` or `tsc --noEmit` |
-| Rust            | `Cargo.toml`                  | `cargo build`    | `cargo test`    | `cargo clippy -- -D warnings` | (included in build)                   |
-| Python          | `pyproject.toml` / `setup.py` | —                | `pytest`        | `ruff check .`                | `mypy .`                              |
-| Go              | `go.mod`                      | `go build ./...` | `go test ./...` | `golangci-lint run`           | (included in build)                   |
-
-## Protocol
-
-### Step 1: Detect project type
-
-Check for indicator files in the project root. Multiple types may coexist (e.g., Node + Python monorepo).
-
-### Step 2: Run checks in parallel where possible
-
-```bash
-# Run typecheck and lint in parallel
-npm run typecheck &
-npm run lint &
-wait
-
-# Then run tests (may depend on build)
-npm test
-```
-
-### Step 3: Report results
-
-For each check, report:
-
-- **Pass/Fail** status
-- **Error count** (if failed)
-- **Key error messages** (first 5)
-
-### Step 4: Gate decision
-
-- **All pass:** Proceed with the command
-- **Any fail:** Stop and report. Let the user decide whether to proceed or fix.

package/dist/template/.opencode/skill/visual-analysis/SKILL.md

@@ -1,154 +0,0 @@
----
-name: visual-analysis
-description: Use when analyzing images, screenshots, UI mockups, or visual content for extracting information, comparing designs, or assessing visual properties like colors, typography, and layout
-version: 1.0.0
-tags: [design, research]
-dependencies: []
----
-
-# Visual Analysis Skill
-
-> **Replaces** guessing at visual properties from code alone — direct inspection of rendered output for colors, layout, spacing, and typography
-
-## When to Use
-
-- Analyzing UI mockups or screenshots
-- Extracting information from images
-- Comparing visual designs
-- Quick visual assessments
-
-## When NOT to Use
-
-- Pure text/code review without any visual assets.
-
-## Workflow
-
-1. **Capture** — Get the image (screenshot, mockup, or user-provided)
-2. **Analyze** — Use vision agent to extract specific properties (colors as hex, font sizes, spacing in px/rem)
-3. **Compare** — Cross-reference extracted values against design tokens and existing CSS
-4. **Report** — List discrepancies with specific values and file locations
-
-## Quick Mode
-
-Fast, focused analysis for specific questions.
-
-**Prompt pattern:**
-
-```
-Analyze this image: [attach image]
-[specific question]
-```
-
-**Examples:**
-
-- "What text is visible in this UI?"
-- "List all colors used with their hex values"
-- "Identify all interactive elements"
-
-## Deep Mode
-
-Comprehensive analysis with structured output.
-
-**Prompt pattern:**
-
-```
-Analyze this image comprehensively:
-
-1. CONTENT INVENTORY
-   - All UI elements present
-   - Text content
-   - Icons and imagery
-
-2. VISUAL PROPERTIES
-   - Color palette (hex values)
-   - Typography (fonts, sizes, weights)
-   - Spacing patterns
-   - Layout structure
-
-3. OBSERVATIONS
-   - Design patterns used
-   - Potential issues
-   - Notable features
-
-Output as structured markdown.
-```
-
-## Common Analysis Patterns
-
-### UI Component Analysis
-
-```
-Analyze this UI component:
-
-1. Component type and purpose
-2. Visual states (hover, focus, disabled)
-3. Accessibility considerations
-4. Props/variants needed
-5. Similar patterns in common UI libraries
-```
-
-### Screenshot Comparison
-
-```
-Compare these two images:
-
-1. Visual differences (be specific about location)
-2. Missing elements
-3. Spacing/sizing discrepancies
-4. Color accuracy
-5. Priority fixes ranked by visual impact
-```
-
-### Color Extraction
-
-```
-Extract all colors from this image.
-
-Output as JSON:
-{
-  "primary": ["#hex1", "#hex2"],
-  "secondary": ["#hex3"],
-  "neutral": ["#hex4", "#hex5"],
-  "accent": ["#hex6"]
-}
-
-Include approximate usage percentage for each color.
-```
-
-### Layout Analysis
-
-```
-Analyze the layout structure:
-
-1. Grid system (columns, gutters)
-2. Container widths
-3. Section divisions
-4. Responsive breakpoint hints
-5. Flexbox vs Grid recommendations
-
-Output CSS/Tailwind structure.
-```
-
-## Output Formats
-
-- **Markdown** (default): Structured text
-- **JSON**: For design tokens
-- **Code**: Direct implementation
-
-## Storage
-
-Save findings to `.opencode/memory/design/analysis/`
-
-## Anti-Patterns
-
-| Anti-Pattern                                                                   | Why It Fails                                                                 | Instead                                                                     |
-| ------------------------------------------------------------------------------ | ---------------------------------------------------------------------------- | --------------------------------------------------------------------------- |
-| Describing layout vaguely ("looks good") instead of extracting specific values | Feedback is non-actionable and hard to validate                              | Report measurable values (hex, px/rem, font size/weight) with locations     |
-| Not comparing against existing design tokens                                   | Findings drift from system standards and create inconsistent recommendations | Map extracted values to tokens first, then flag true mismatches             |
-| Analyzing low-resolution screenshots (artifacts mislead analysis)              | Compression/noise causes false readings for spacing and color                | Request higher-resolution captures or zoomed crops before final conclusions |
-
-## See Also
-
-- `mockup-to-code`
-- `design-system-audit`
-- `accessibility-audit`

package/dist/template/.opencode/skill/web-design-guidelines/SKILL.md

@@ -1,46 +0,0 @@
----
-name: web-design-guidelines
-description: Review UI code for Web Interface Guidelines compliance. Use when asked to "review my UI", "check accessibility", "audit design", "review UX", or "check my site against best practices".
-version: 1.0.0
-tags: [ui, design]
-dependencies: []
----
-
-# Web Interface Guidelines
-
-## When to Use
-
-- Reviewing UI files against Web Interface Guidelines for UX/design compliance.
-
-## When NOT to Use
-
-- Non-UI code reviews or when no files/pattern are provided.
-
-
-## How It Works
-
-1. Fetch the latest guidelines from the source URL below
-2. Read the specified files (or prompt user for files/pattern)
-3. Check against all rules in the fetched guidelines
-4. Output findings in the terse `file:line` format
-
-## Guidelines Source
-
-Fetch fresh guidelines before each review:
-
-```
-https://raw.githubusercontent.com/vercel-labs/web-interface-guidelines/main/command.md
-```
-
-Use WebFetch to retrieve the latest rules. The fetched content contains all the rules and output format instructions.
-
-## Usage
-
-When a user provides a file or pattern argument:
-
-1. Fetch guidelines from the source URL above
-2. Read the specified files
-3. Apply all rules from the fetched guidelines
-4. Output findings using the format specified in the guidelines
-
-If no files specified, ask the user which files to review.

package/dist/template/.opencode/skill/workspace-setup/SKILL.md

@@ -1,76 +0,0 @@
----
-name: workspace-setup
-description: >
-  Use when a command needs to create a feature branch or set up a workspace for bead work. Shared by /create and /ship.
-version: 1.0.0
-tags: [git, workspace, branch, setup]
----
-
-# Workspace Setup
-
-Set up a git workspace (branch or worktree) for bead-based work.
-
-## When to Use
-
-- In `/create` after bead creation, before task conversion
-- In `/ship` when auto-claiming an unclaimed bead
-- Any command that needs to transition from "no workspace" to "active workspace"
-
-## When NOT to Use
-
-- If bead is already `in_progress` with an existing branch
-- If user explicitly chose "Use current branch"
-
-## Protocol
-
-### Step 1: Ask the user
-
-```typescript
-question({
-  questions: [
-    {
-      header: "Workspace",
-      question: "How do you want to set up the workspace?",
-      options: [
-        {
-          label: "Create feature branch (Recommended)",
-          description: "git checkout -b <prefix>/<bead-id>-<title>",
-        },
-        {
-          label: "Use current branch",
-          description: "Work on current branch without creating a new one",
-        },
-      ],
-    },
-  ],
-});
-```
-
-> **Note:** `/create` may additionally offer a "Create worktree" option using `skill({ name: "using-git-worktrees" })`.
-
-### Step 2: Create branch (if selected)
-
-Map bead type to branch prefix:
-
-| Bead Type | Branch Prefix |
-| --------- | ------------- |
-| feature   | feat          |
-| bug       | fix           |
-| task      | task          |
-| epic      | epic          |
-
-Create the branch:
-
-```bash
-git checkout -b $PREFIX/$BEAD_ID-$TITLE_SLUG
-```
-
-Where `$TITLE_SLUG` is the bead title lowercased with spaces replaced by hyphens, truncated to ~50 chars.
-
-### Step 3: Confirm
-
-```bash
-git branch --show-current
-```
-
-Verify you're on the new branch before proceeding.