opencodekit 0.21.10 → 0.23.0

package/dist/template/.opencode/skill/brand-asset-protocol/SKILL.md

@@ -1,222 +0,0 @@
----
-name: brand-asset-protocol
-description: Use when designing anything for a specific brand (logo, marketing site, product launch animation, branded slide deck, redesign). MUST load before producing branded visuals. Forces real logo + product image + UI screenshot fetch BEFORE any design work — color values alone are not enough for brand recognition. Includes 5-10-2-8 quality bar (5 search rounds, 10 candidates, pick 2 best, each ≥8/10).
----
-
-# Brand Asset Protocol
-
-> Adapted from `huashu-design`. Brand recognition lives in **assets first, color second**. Generic CSS shapes can never substitute a real logo or product image.
-
-## When to Use
-
-Trigger this protocol whenever the task names a real brand or product:
-
-- "Design a launch animation for **DJI Pocket 4**"
-- "Redesign the **Stripe** dashboard"
-- "Build a landing page for **Linear**"
-- "Make a slide deck about **Anthropic Claude**"
-- Internal client work: "Design something for **our company**"
-
-If the task is generic ("design a SaaS landing page"), skip this skill — use `design-direction-advisor` instead.
-
-## Prerequisite: Verify the Brand Exists First
-
-Before fetching assets, confirm the brand/product **exists and you know its current state**. Never assert from training data — search.
-
-```
-Trigger: any specific product/version (Pocket 4, Gemini 3 Pro, new SDK, etc.)
-Action: WebSearch "<product> launch date specs 2026" → read 1-3 authoritative results
-Cost: 10 seconds. Skipping this can cost 1-2 hours of rework.
-```
-
-Forbidden phrases that signal you should search instead of guess:
-
-- ❌ "I think X hasn't launched yet"
-- ❌ "X is currently version N" (without checking)
-- ❌ "X probably doesn't exist"
-- ✅ "Let me search for the latest state of X"
-
-## Asset Hierarchy: Why Color Alone Fails
-
-| Asset                        | Recognition contribution     | Required for                              |
-| ---------------------------- | ---------------------------- | ----------------------------------------- |
-| **Logo**                     | Highest — instant ID         | **Every** branded project                 |
-| **Product photos / renders** | Very high — the "main actor" | Physical products (hardware, packaging)   |
-| **UI screenshots**           | Very high — the "main actor" | Digital products (apps, SaaS, dashboards) |
-| Color palette                | Medium — easily collides     | Supporting role                           |
-| Typography                   | Low — needs the above        | Supporting role                           |
-| Vibe keywords                | Low — internal QA only       | Supporting role                           |
-
-**Rule**: Pulling colors + fonts but skipping logo/product/UI → protocol violation. Generic placeholders, CSS silhouettes, or hand-drawn SVG cannot substitute real assets.
-
-## The 5-Step Protocol (Strict Sequence)
-
-### Step 1 — Ask (one full asset checklist, not vague "got brand guidelines?")
-
-Send this exact list:
-
-```
-For <brand/product>, which of these do you have? (priority order)
-1. Logo (SVG / high-res PNG) — required for any brand
-2. Product photos / official renders — required for physical products
-3. UI screenshots / interface assets — required for digital products
-4. Color values (HEX / RGB / palette doc)
-5. Font list (display / body)
-6. Brand guidelines PDF / Figma design system / brand site URL
-
-Send what you have; I'll fetch / generate the rest.
-```
-
-### Step 2 — Search Official Sources
-
-| Asset           | Where to look                                                                               |
-| --------------- | ------------------------------------------------------------------------------------------- |
-| **Logo**        | `<brand>.com/brand`, `/press`, `/press-kit`, `brand.<brand>.com`, header inline SVG         |
-| **Product img** | Product detail page hero + gallery, official YouTube launch film frames, press releases     |
-| **UI**          | App Store / Play Store screenshots, official site screenshots section, demo video frames    |
-| **Colors**      | Site inline CSS / Tailwind config / brand guidelines PDF                                    |
-| **Fonts**       | `<link rel="stylesheet">` references on official site, Google Fonts trace, brand guidelines |
-
-Fallback queries: `<brand> logo download SVG`, `<brand> press kit`, `<brand> <product> official renders`, `<brand> app screenshots`.
-
-### Step 3 — Download (three fallback paths per asset type)
-
-**Logo (mandatory for every brand):**
-
-```bash
-# 1. Direct file (best)
-curl -o assets/<brand>/logo.svg https://<brand>.com/logo.svg
-
-# 2. Extract inline SVG from homepage HTML (~80% of cases)
-curl -A "Mozilla/5.0" -L https://<brand>.com -o assets/<brand>/homepage.html
-# then grep <svg>...</svg> for the logo node
-
-# 3. Official social avatar (last resort): GitHub/Twitter/LinkedIn org image
-```
-
-**Product photos (mandatory for physical products):**
-
-1. Official product page hero (right-click image URL, curl it)
-2. Official press kit / press releases
-3. Launch video frames (`yt-dlp` + `ffmpeg`)
-4. Wikimedia Commons (public domain)
-5. AI generation **using the official product photo as reference** — never replace with CSS silhouettes
-
-**UI screenshots (mandatory for digital products):**
-
-- App Store / Play Store product page (note: may be marketing mockups, not real UI — verify)
-- Official site screenshots section
-- Product demo video frames
-- Official Twitter/X launch posts (often the latest version)
-- Real screenshots from your own account when possible
-
-### Step 4 — Quality Bar: The 5-10-2-8 Rule (non-Logo assets)
-
-> Logo rules differ: any logo must be used (no logo → stop and ask user). Other assets (product photos, UI, hero imagery) follow 5-10-2-8.
-
-| Dimension              | Standard                                                                                                | Anti-pattern                        |
-| ---------------------- | ------------------------------------------------------------------------------------------------------- | ----------------------------------- |
-| **5 search rounds**    | Cross-search official site / press kit / social / YouTube / Wikimedia / user account                    | First page of results, stop         |
-| **10 candidates**      | Gather at least 10 before filtering                                                                     | Grab 2, no choice                   |
-| **Pick 2 best**        | Curate 2 finals from the 10                                                                             | Use everything = visual overload    |
-| **Each ≥8/10 quality** | Below 8 → use honest placeholder or AI-generate from official reference. **Better none than mediocre.** | Pad brand-spec.md with 7/10 fillers |
-
-**8/10 scoring dimensions** (record per asset in `brand-spec.md`):
-
-1. **Resolution** — ≥2000px (≥3000px for print/large screen)
-2. **Copyright clarity** — official > public domain > free stock > unclear (unclear = 0)
-3. **Brand vibe match** — consistent with the vibe keywords in `brand-spec.md`
-4. **Lighting/composition consistency** — the 2 finals should not clash
-5. **Standalone narrative** — each asset must independently express a narrative role, not just decorate
-
-### Step 5 — Codify in `brand-spec.md` (single source of truth)
-
-```markdown
-# <Brand> · Brand Spec
-
-> Captured: YYYY-MM-DD
-> Sources: <list>
-> Completeness: complete / partial / inferred
-
-## 🎯 Core Assets (first-class)
-
-### Logo
-
-- Primary: `assets/<brand>/logo.svg`
-- Inverse: `assets/<brand>/logo-white.svg`
-- Use cases: <intro / outro / corner watermark / global>
-- Forbidden: <no stretch / no recolor / no outline>
-
-### Product Photos (required for physical products)
-
-- Hero: `assets/<brand>/product-hero.png` (2000×1500)
-- Detail: `assets/<brand>/product-detail-1.png`
-- Scene: `assets/<brand>/product-scene.png`
-
-### UI Screenshots (required for digital products)
-
-- Home: `assets/<brand>/ui-home.png`
-- Feature: `assets/<brand>/ui-feature-<name>.png`
-
-## 🎨 Supporting Assets
-
-### Palette
-
-- Primary: #XXXXXX <source>
-- Background: #XXXXXX
-- Ink: #XXXXXX
-- Accent: #XXXXXX
-- Forbidden: <colors the brand explicitly avoids>
-
-### Typography
-
-- Display: <font stack>
-- Body: <font stack>
-- Mono: <font stack>
-
-### Signature Details
-
-- <which details are taken to 120%>
-
-### Forbidden Zone
-
-- <explicit "do not" rules>
-
-### Vibe Keywords
-
-- <3-5 adjectives>
-```
-
-## Execution Discipline (after spec exists)
-
-- **All HTML must reference asset file paths from `brand-spec.md`** — no CSS silhouettes, no hand-drawn SVG substitutes.
-- **Logo as `<img>`** referencing the real file. Never redraw.
-- **Product photos as `<img>`** referencing real files. No CSS silhouettes.
-- **CSS variables injected from spec**: `:root { --brand-primary: ...; }` — HTML only uses `var(--brand-*)`.
-- This converts brand consistency from "by intent" to "by structure" — adding a new color requires editing the spec first.
-
-## Failure Fallbacks
-
-| Missing                      | Action                                                                                                                       |
-| ---------------------------- | ---------------------------------------------------------------------------------------------------------------------------- |
-| **Logo not findable**        | **Stop and ask the user.** Logo is the foundation of brand recognition. Don't fake it.                                       |
-| **Product photo (physical)** | Prefer AI generation **using official reference image** → ask user → honest placeholder ("product photo TBD") as last resort |
-| **UI screenshot (digital)**  | Ask user for screenshots from their account → official demo video frames. Don't use generic mockup generators.               |
-| **Color values**             | Run `design-direction-advisor` skill, recommend 3 directions with explicit assumption labels                                 |
-
-**Forbidden**: silently using CSS silhouettes / generic gradients when assets can't be found. **Better to stop and ask than to fake.**
-
-## Real Failures (why this protocol exists)
-
-- **Kimi animation**: Guessed "should be orange" from memory. Actual brand color: `#1783FF` blue. Full rework.
-- **Lovart design**: Mistook a demo brand color in a product screenshot for Lovart's own. Almost destroyed the entire design.
-- **DJI Pocket 4 launch animation**: Pulled colors but skipped logo + product image, used CSS silhouettes. Output was "generic black-bg + orange-accent tech animation" with zero DJI recognition. Designer's note: _"Otherwise, what are we even expressing?"_
-
-## Cost Comparison
-
-| Path                       | Time                                                                                |
-| -------------------------- | ----------------------------------------------------------------------------------- |
-| **Run protocol correctly** | Logo 5 min + product/UI 10 min + color grep 5 min + spec write 10 min = **~30 min** |
-| **Skip protocol**          | Generic output → user rework 1-2 hours, sometimes full redo                         |
-
-**The cheapest stability investment in branded design work.** For client deliverables, launch events, or important customer projects, the 30-minute protocol is insurance.

package/dist/template/.opencode/skill/code-search-patterns/SKILL.md

@@ -1,224 +0,0 @@
----
-name: code-search-patterns
-description: Use when navigating unfamiliar code with search-first patterns, combining built-in/LSP navigation with srcwalk CLI
-version: 1.0.0
-tags: [workflow, code-quality, context, subagent]
-dependencies: []
----
-
-# Code Search Patterns
-
-Unified navigation skill for fast, low-waste code understanding:
-
-- **Main agent**: built-in tools + LSP + srcwalk CLI
-- **Subagents**: Bash + `srcwalk` CLI
-
-This skill merges practical navigation heuristics with concrete tool usage so you can locate behavior, trace impact, and edit safely with fewer calls.
-
-## When to Use
-
-- Exploring unfamiliar modules before editing
-- Tracing call chains across files and directories
-- Checking blast radius before signature/export changes
-- Dispatching subagents that need structural code navigation
-- Reducing token/tool-call waste during implementation
-
-## When NOT to Use
-
-- Trivial single-file edits where symbol location is already known
-- Pure docs/config reads with no dependency tracing
-- Tasks focused on external web research (use web research tools instead)
-
-## Core Principle
-
-> Collapse multiple tool calls into fewer, smarter ones. Every unnecessary read or search wastes tokens and turns.
-
-## Navigation Patterns
-
-### 1) Search First, Read Second
-
-Start with symbol/content search to find exact locations, then read only the needed slice.
-
-- **Good**: `search -> targeted read`
-- **Avoid**: `read many files -> search later`
-
-Use LSP (`findReferences`, `outgoingCalls`) or srcwalk search first; read deep only after narrowing scope.
-
-### 2) Multi-Symbol Search
-
-When flow spans multiple functions, query them together (`A,B,C`) instead of serial one-by-one lookups.
-
-- Faster call-chain reconstruction
-- Fewer repeated scans of the same files
-
-### 3) Don’t Re-Read What Search Already Returned
-
-If search output already includes definition body/context, proceed from it.
-Re-read only when you need:
-
-- exact edit anchors,
-- additional surrounding lines,
-- or untruncated content.
-
-### 4) Blast Radius Check (Before Breaking Changes)
-
-Before renaming/removing/changing signatures, inspect downstream impact first.
-
-- LSP: `findReferences`, `incomingCalls`
-- srcwalk: `srcwalk impact <symbol>` or `srcwalk callers <symbol>`
-
-Then apply edits from dependents inward.
-
-### 5) Context Locality
-
-Prefer nearby package/module scope first.
-
-- built-in search: constrain `path`
-- srcwalk: pass `--scope <dir>` to restrict the scan area
-
-Locality reduces irrelevant matches and token churn.
-
-### 6) Outline Before Deep Read
-
-For large files, inspect structure first (symbols/outline), then read only target sections.
-
-- LSP: `documentSymbol`
-- srcwalk read: smart outline by default, then section drill-in
-
-### 7) Follow Call Chain, Not File Tree
-
-Start at entry behavior and walk calls (`definition -> outgoing -> next definition`) instead of reading folders linearly.
-
-This exposes real execution flow with fewer reads.
-
-## srcwalk CLI
-
-`srcwalk` is available to all agents (main agent and subagents) via Bash. It combines grep + tree-sitter AST into one CLI tool.
-
-```bash
-srcwalk guide          # Print agent routing policy (run once per session)
-srcwalk find <symbol>  # Symbol search (definitions + usages)
-srcwalk <file>         # Smart file read (outline for large files)
-srcwalk map            # Codebase structural overview
-srcwalk files '<glob>' # Find files by pattern
-srcwalk callers <sym>  # Reverse call graph
-srcwalk impact <sym>   # Blast-radius heuristic
-```
-
-### Auto-detection
-
-| Query shape                       | Auto-detected action                 |
-| --------------------------------- | ------------------------------------ |
-| Existing file path (`src/foo.ts`) | Read file (smart outline/full)       |
-| Identifier (`initCommand`)        | Symbol search (definitions + usages) |
-| `find <symbol>`                   | Explicit symbol search               |
-| `files <glob>`                    | File discovery                       |
-
-### Core operations
-
-#### 1) Read file
-
-```bash
-srcwalk src/index.ts
-srcwalk src/index.ts --full
-srcwalk src/index.ts --section 45-89
-```
-
-#### 2) Search symbols
-
-```bash
-srcwalk find initCommand --scope src/
-srcwalk find "initCommand,detectMode" --scope src/
-```
-
-#### 3) Search text/regex
-
-```bash
-srcwalk find "TODO" --scope src/
-srcwalk find "/TODO.*fix/" --scope src/
-```
-
-#### 4) Find callers
-
-```bash
-srcwalk callers initCommand --scope src/
-```
-
-#### 5) List files
-
-```bash
-srcwalk files "*.test.ts" --scope src/
-```
-
-#### 6) Blast radius
-
-```bash
-srcwalk impact initCommand --scope src/
-srcwalk callers initCommand --scope src/
-```
-
-#### 7) Codebase map
-
-```bash
-srcwalk map --scope src/
-```
-
-### Useful flags
-
-| Flag                    | Purpose                                       | Example                             |
-| ----------------------- | --------------------------------------------- | ----------------------------------- |
-| `--scope <dir>`         | Restrict scan area                            | `--scope src/commands/`             |
-| `--section <range\|sym>` | Targeted file slice (line range or symbol)   | `--section 120-180`, `--section fn` |
-| `--full`                | Force full file output (no outline)           | `--full`                            |
-| `--budget <n>`          | Limit output token size                       | `--budget 2000`                     |
-| `--json`                | Machine-readable output                       | `--json`                            |
-| `--filter <qualifiers>` | Filter find results by field:value            | `--filter kind:fn`                  |
-| `--glob <pattern>`      | File pattern filter within find               | `--glob "*.ts"`                     |
-| `--expand[=<n>]`        | Inline source for top N matches               | `--expand 3`                        |
-| `--depth <n>`           | Depth for callers/callees traversal           | `--depth 2`                         |
-
-### Example subagent dispatch
-
-```ts
-task({
-  subagent_type: "general",
-  prompt: `Use srcwalk via Bash for navigation.
-
-1) Locate symbol and usages:
-srcwalk find initCommand --scope src/
-
-2) Find callers:
-srcwalk callers initCommand --scope src/
-
-3) Check blast radius before edits:
-srcwalk impact initCommand --scope src/
-
-4) Read only the relevant section:
-srcwalk src/commands/init.ts --section 500-620
-
-Then implement the requested change with minimal file edits.`,
-});
-```
-
-## Cost Awareness
-
-Navigation cost compounds quickly. Optimize for fewer, richer calls.
-
-- Prefer one structural search over multiple blind reads
-- Reuse search output; avoid duplicate reads of the same symbol body
-- Scope aggressively (`path`, `scope`) to cut noise
-- Use section reads for large files instead of full-file pulls
-
-Target heuristic: understand a symbol and its direct impact in **≤3 calls** whenever possible.
-
-## Common Mistakes
-
-| Mistake                                          | Better pattern                                                      |
-| ------------------------------------------------ | ------------------------------------------------------------------- |
-| Reading big files before locating symbol         | Search first, then section read                                     |
-| Re-reading code already shown in search output   | Work from returned snippet; re-read only if needed for edit anchors |
-| Serially tracing one function at a time          | Multi-symbol search + callers/deps                                  |
-| Ignoring blast radius before API/signature edits | Run references/incoming/deps first                                  |
-| Unscoped repository-wide search                  | Use `path`/`--scope` to localize                                    |
-| Using CLI defaults when mode is ambiguous        | Use explicit subcommand (`find`, `files`, `callers`) or `--filter kind:<label>` |
-| Overusing `--full` on large files                | Outline first, then `--section`                                     |

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

@@ -1,211 +0,0 @@
----
-name: code-simplification
-description: Use when reducing code complexity, eliminating dead code, or refactoring for clarity — enforces measure-before-cutting discipline to prevent breaking changes disguised as cleanup
-version: 1.0.0
-tags: [code-quality, refactoring]
-dependencies: [verification-before-completion]
----
-
-# Code Simplification
-
-> **Replaces** ad-hoc "cleanup" refactors that introduce bugs — enforces systematic simplification with verification at every step
-
-## When to Use
-
-- Code is harder to understand than it needs to be
-- Functions are too long (>50 lines), files are too large (>500 lines)
-- Dead code, unused imports, or unnecessary abstractions exist
-- You're asked to "clean up" or "simplify" a module
-- Complexity is making bugs harder to fix
-
-## When NOT to Use
-
-- The code works, is readable, and isn't blocking anything — leave it alone
-- You're implementing a new feature (use incremental-implementation instead)
-- The "simplification" is actually a rewrite with different behavior
-
-## Common Rationalizations
-
-| Rationalization                        | Rebuttal                                                                                 |
-| -------------------------------------- | ---------------------------------------------------------------------------------------- |
-| "This code is ugly, let me rewrite it" | Ugly but working > beautiful but broken. Simplify incrementally, not wholesale           |
-| "Nobody uses this, I'll delete it"     | Verify with grep/find-references FIRST. "Nobody uses this" is the #1 cause of breakage   |
-| "I'll simplify it while I'm in here"   | Mixing feature work with refactoring makes both harder to review and revert              |
-| "This abstraction isn't needed"        | Check if it serves a testing, extension, or boundary purpose before removing             |
-| "I can make this more elegant"         | Elegant for whom? Optimize for the next reader, not for cleverness                       |
-| "The tests will catch any issues"      | Tests cover known behavior. Simplification can change behavior in ways tests don't cover |
-
-## Overview
-
-Code simplification is the discipline of making code easier to understand and maintain WITHOUT changing its behavior. The key word is discipline — undisciplined simplification introduces bugs.
-
-**Core principle:** Measure complexity, simplify the worst offender, verify nothing broke, repeat.
-
-## The Process
-
-```
-1. MEASURE  — Identify what's actually complex (not just what feels complex)
-2. ISOLATE  — Pick ONE simplification target
-3. VERIFY   — Ensure tests exist for current behavior
-4. SIMPLIFY — Apply the smallest change that reduces complexity
-5. CONFIRM  — Run full verification to prove behavior is unchanged
-6. REPEAT   — Pick the next target
-```
-
-## Complexity Signals
-
-| Signal                | Threshold        | Action                                      |
-| --------------------- | ---------------- | ------------------------------------------- |
-| Function length       | >50 lines        | Extract helper functions                    |
-| File length           | >500 lines       | Split into modules                          |
-| Nesting depth         | >3 levels        | Flatten with early returns or extract       |
-| Parameter count       | >4 params        | Use an options object                       |
-| Cyclomatic complexity | >10 per function | Break into smaller functions                |
-| Dead code             | Any              | Remove after verifying with find-references |
-| Unused imports        | Any              | Remove (linter usually catches these)       |
-| Duplicate code        | 3+ copies        | Extract shared function                     |
-
-## Simplification Patterns
-
-### Extract Function
-
-```typescript
-// BEFORE: Long function with embedded logic
-function processOrder(order: Order) {
-  // 20 lines of validation
-  // 15 lines of pricing
-  // 10 lines of notification
-}
-
-// AFTER: Named steps
-function processOrder(order: Order) {
-  validateOrder(order);
-  const total = calculateTotal(order);
-  notifyCustomer(order, total);
-}
-```
-
-### Early Return (Flatten Nesting)
-
-```typescript
-// BEFORE: Deep nesting
-function getUser(id: string) {
-  if (id) {
-    const user = db.find(id);
-    if (user) {
-      if (user.active) {
-        return user;
-      }
-    }
-  }
-  return null;
-}
-
-// AFTER: Guard clauses
-function getUser(id: string) {
-  if (!id) return null;
-  const user = db.find(id);
-  if (!user) return null;
-  if (!user.active) return null;
-  return user;
-}
-```
-
-### Remove Dead Code
-
-```
-1. Search: grep/find-references for the symbol
-2. Verify: No callers exist (check tests too)
-3. Remove: Delete the code
-4. Confirm: All tests still pass
-```
-
-**NEVER assume code is dead without searching.** Check:
-
-- Direct calls
-- Dynamic references (string-based lookups, reflection)
-- Test-only usage
-- Configuration references
-
-### Inline Unnecessary Abstraction
-
-```typescript
-// BEFORE: Wrapper that adds nothing
-function getUserName(user: User): string {
-  return user.name;
-}
-
-// AFTER: Just use the property directly
-user.name;
-```
-
-Only inline if the abstraction doesn't serve a testing, boundary, or extension purpose.
-
-### Replace Conditional with Early Exit
-
-```typescript
-// BEFORE
-function handle(input: string) {
-  let result = "";
-  if (isValid(input)) {
-    result = transform(input);
-  } else {
-    throw new Error("Invalid");
-  }
-  return result;
-}
-
-// AFTER
-function handle(input: string) {
-  if (!isValid(input)) throw new Error("Invalid");
-  return transform(input);
-}
-```
-
-## What NOT to Simplify
-
-- **Working error handling** — even if verbose, it's there for a reason
-- **Compatibility shims** — they exist because something needs them
-- **Performance-critical paths** — "simpler" may mean "slower"
-- **Code with extensive test coverage pointing at specific behavior** — the tests document WHY it's complex
-- **Other people's current work** — don't simplify files with active PRs
-
-## Red Flags — STOP
-
-If you catch yourself:
-
-- Changing behavior while "simplifying"
-- Removing code without checking references first
-- Simplifying more than one thing per commit
-- "Cleaning up" files you weren't asked to touch
-- Making the code "more elegant" without a clear readability improvement
-
-**STOP.** Revert the current change and pick a smaller target.
-
-## Verification
-
-Before each simplification:
-
-```bash
-# Ensure tests exist for current behavior
-npm test -- --related [file]
-```
-
-After each simplification:
-
-```bash
-npm run typecheck
-npm run lint
-npm test
-```
-
-**If ANY test fails, the simplification changed behavior.** Either:
-
-1. The simplification is wrong — revert it
-2. The test is testing implementation details — fix the test, but document WHY
-
-## See Also
-
-- **incremental-implementation** — Build new features in slices; simplify afterward
-- **systematic-debugging** — When simplification reveals hidden bugs
-- **defense-in-depth** — When simplifying validation, ensure all layers still hold