@ultrakit/ultrakit 0.0.0

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

@@ -0,0 +1,222 @@
+---
+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/chrome-devtools/SKILL.md

@@ -0,0 +1,76 @@
+---
+name: chrome-devtools
+description: Use when debugging web apps in Chrome — performance profiling, network inspection, DOM debugging, or console automation. MUST load before any Chrome DevTools-based debugging session.
+version: 1.0.0
+tags: [automation, debugging]
+dependencies: []
+---
+
+# Chrome DevTools (MCP)
+
+## When to Use
+
+- When you need to debug or inspect a live Chrome page via DevTools Protocol tools.
+
+## When NOT to Use
+
+- When cross-browser automation is required (use Playwright-based skills instead).
+
+
+## Available Tools
+
+- `take_snapshot` - Get accessibility tree snapshot with element UIDs
+- `take_screenshot` - Capture screenshot of page or element
+- `navigate_page` - Navigate to URL, back, forward, or reload
+- `new_page` - Open a new browser tab
+- `list_pages` - List all open pages/tabs
+- `click` - Click element by UID
+- `fill` - Type text into element
+- `hover` - Hover over element
+- `press_key` - Press keyboard key (Enter, Tab, etc.)
+- `evaluate_script` - Run JavaScript in page context
+- `wait_for` - Wait for text to appear
+
+## Workflow
+
+1. **Snapshot** the page using `take_snapshot` to get element UIDs
+2. **Navigate** to target URL using `navigate_page`
+3. **Interact** using `click`, `fill`, `hover` with UIDs from snapshot
+4. **Screenshot** to capture results using `take_screenshot`
+
+## Quick Start
+
+```
+# Get page structure with element UIDs
+skill_mcp(skill_name="chrome-devtools", tool_name="take_snapshot")
+
+# Navigate to URL
+skill_mcp(skill_name="chrome-devtools", tool_name="navigate_page", arguments='{"type": "url", "url": "https://example.com"}')
+
+# Click element (use UID from snapshot)
+skill_mcp(skill_name="chrome-devtools", tool_name="click", arguments='{"uid": "e123"}')
+
+# Fill input field
+skill_mcp(skill_name="chrome-devtools", tool_name="fill", arguments='{"uid": "e456", "value": "hello"}')
+
+# Take screenshot
+skill_mcp(skill_name="chrome-devtools", tool_name="take_screenshot")
+```
+
+## Tips
+
+- **Always `take_snapshot` first** to get element UIDs
+- **Element UIDs change** after navigation - take fresh snapshot
+- **Use `wait_for`** after actions that trigger page changes
+- **Use `evaluate_script`** for custom JS when tools don't cover your need
+
+## vs Playwright
+
+| Feature             | chrome-devtools      | playwright         |
+| ------------------- | -------------------- | ------------------ |
+| Browser support     | Chrome only          | Chrome, FF, WebKit |
+| Performance tracing | ✅ (full MCP has it) | ❌                 |
+| Network inspection  | ✅ (full MCP has it) | ❌                 |
+| Cross-browser       | ❌                   | ✅                 |
+
+> **Note**: This skill loads 11 essential tools. For full 26+ tools (performance, network, console), modify `mcp.json` to remove `includeTools` filter.

package/dist/template/.opencode/skill/chrome-devtools/mcp.json

@@ -0,0 +1,19 @@
+{
+  "chrome-devtools": {
+    "command": "npx",
+    "args": ["-y", "chrome-devtools-mcp@latest", "--stdio"],
+    "includeTools": [
+      "take_snapshot",
+      "take_screenshot",
+      "navigate_page",
+      "new_page",
+      "list_pages",
+      "click",
+      "fill",
+      "hover",
+      "press_key",
+      "evaluate_script",
+      "wait_for"
+    ]
+  }
+}

package/dist/template/.opencode/skill/ci-cd-and-automation/SKILL.md

@@ -0,0 +1,202 @@
+---
+name: ci-cd-and-automation
+description: Use when setting up CI/CD pipelines, GitHub Actions workflows, automated testing in CI, or deployment automation — covers pipeline design, caching, secrets management, and release workflows
+version: 1.0.0
+tags: [devops, workflow]
+dependencies: []
+---
+
+# CI/CD & Automation
+
+> **Replaces** manual deployment checklists and ad-hoc scripts with repeatable, auditable automation pipelines
+
+## When to Use
+
+- Setting up or modifying CI/CD pipelines (GitHub Actions, GitLab CI, etc.)
+- Adding automated testing, linting, or type-checking to a repository
+- Configuring deployment automation or release workflows
+- Optimizing CI performance (caching, parallelism, conditional runs)
+
+## When NOT to Use
+
+- Local development scripts (use Makefile or package.json scripts)
+- One-time migration scripts that don't repeat
+- Infrastructure provisioning (use infrastructure-as-code tools directly)
+
+## Overview
+
+CI/CD pipelines are the quality gates between code and production. A well-designed pipeline catches problems early, runs fast, and deploys safely.
+
+**Core principle:** Every step that a human does manually before merging or deploying should be automated in the pipeline. If it can be automated, it must be.
+
+## Pipeline Design
+
+### Verification Pipeline (PR/Push)
+
+```yaml
+# Ordered by speed: fastest gates first
+steps:
+  1. Lint          # seconds — catches formatting/style issues
+  2. Typecheck     # seconds — catches type errors
+  3. Unit tests    # seconds-minutes — catches logic bugs
+  4. Build         # minutes — catches compilation issues
+  5. Integration   # minutes — catches integration bugs
+  6. E2E tests     # minutes — catches user-facing bugs (optional per-PR)
+```
+
+**Fail-fast rule:** Run cheapest checks first. Don't waste 10 minutes on E2E tests if linting fails in 5 seconds.
+
+### Deployment Pipeline (Main/Release)
+
+```
+1. All verification steps pass
+2. Build production artifacts
+3. Deploy to staging
+4. Run smoke tests against staging
+5. Deploy to production (manual gate or auto)
+6. Run smoke tests against production
+7. Monitor error rates for rollback window
+```
+
+## GitHub Actions Patterns
+
+### Basic PR Verification
+
+```yaml
+name: verify
+on: [pull_request]
+jobs:
+  check:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - uses: actions/setup-node@v4
+        with:
+          node-version-file: ".node-version"
+          cache: "pnpm"
+      - run: pnpm install --frozen-lockfile
+      - run: pnpm lint
+      - run: pnpm typecheck
+      - run: pnpm test
+      - run: pnpm build
+```
+
+### Caching Strategy
+
+| What         | Cache Key         | Restore Key | Impact       |
+| ------------ | ----------------- | ----------- | ------------ |
+| Dependencies | `lockfile hash`   | `os-deps-`  | 30-60s saved |
+| Build output | `source hash`     | `os-build-` | 1-5min saved |
+| Test cache   | `test files hash` | `os-test-`  | Variable     |
+
+```yaml
+- uses: actions/cache@v4
+  with:
+    path: ~/.pnpm-store
+    key: ${{ runner.os }}-pnpm-${{ hashFiles('**/pnpm-lock.yaml') }}
+    restore-keys: ${{ runner.os }}-pnpm-
+```
+
+### Parallel Jobs
+
+```yaml
+jobs:
+  lint:
+    runs-on: ubuntu-latest
+    steps: [checkout, setup, "pnpm lint"]
+
+  typecheck:
+    runs-on: ubuntu-latest
+    steps: [checkout, setup, "pnpm typecheck"]
+
+  test:
+    runs-on: ubuntu-latest
+    steps: [checkout, setup, "pnpm test"]
+
+  build:
+    needs: [lint, typecheck, test] # Only build after all checks pass
+    runs-on: ubuntu-latest
+    steps: [checkout, setup, "pnpm build"]
+```
+
+## Secrets Management
+
+| Rule                                       | Reason                                        |
+| ------------------------------------------ | --------------------------------------------- |
+| Never echo secrets in CI logs              | Logs are often accessible to all contributors |
+| Use GitHub Secrets / environment variables | Encrypted at rest, masked in logs             |
+| Rotate secrets on exposure                 | Assume compromised if ever logged             |
+| Separate secrets per environment           | Staging keys ≠ production keys                |
+| Use OIDC for cloud providers               | No long-lived credentials needed              |
+
+## Release Automation
+
+### Semantic Versioning
+
+```
+MAJOR.MINOR.PATCH
+  │      │     └── Bug fixes (backward compatible)
+  │      └──────── New features (backward compatible)
+  └─────────────── Breaking changes
+```
+
+### Tag-Based Release
+
+```yaml
+on:
+  push:
+    tags: ["v*"]
+jobs:
+  release:
+    steps:
+      - uses: actions/checkout@v4
+      - run: pnpm build
+      - run: pnpm publish # or deploy
+      - uses: softprops/action-gh-release@v2
+        with:
+          generate_release_notes: true
+```
+
+## Common Rationalizations
+
+| Excuse                              | Rebuttal                                                                          |
+| ----------------------------------- | --------------------------------------------------------------------------------- |
+| "CI is slow, I'll test locally"     | Local tests miss environment-specific issues. Optimize CI instead of skipping it. |
+| "We can add CI later"               | Every merged PR without CI is a potential regression. Set up day one.             |
+| "The pipeline is too complex"       | Complexity means you're catching real issues. Simplify steps, not coverage.       |
+| "Manual deploy is faster"           | Until someone deploys the wrong branch. Automation prevents human error.          |
+| "Caching is premature optimization" | 5 minutes saved per PR × 20 PRs/week = 100 minutes/week. Cache from day one.      |
+
+## CI Performance Optimization
+
+| Technique              | Savings                   | Effort                 |
+| ---------------------- | ------------------------- | ---------------------- |
+| Dependency caching     | 30-60s per run            | Low — add cache action |
+| Parallel jobs          | 50-70% of sequential time | Low — split into jobs  |
+| Conditional runs       | Skip unchanged paths      | Medium — path filters  |
+| Build artifact caching | 1-5min per run            | Medium — cache config  |
+| Self-hosted runners    | Faster hardware           | High — infrastructure  |
+
+## Red Flags — STOP
+
+- CI pipeline takes >15 minutes for a PR check
+- Secrets hardcoded in workflow files
+- No caching configured despite slow builds
+- Tests skipped in CI "to save time"
+- Manual deployment steps in the release process
+- No rollback mechanism for failed deployments
+
+## Verification
+
+- [ ] All verification steps run on every PR
+- [ ] Pipeline fails fast (cheapest checks first)
+- [ ] Dependencies are cached
+- [ ] Secrets are never printed in logs
+- [ ] Release process is tag-triggered and automated
+- [ ] Rollback procedure is documented and tested
+
+## See Also
+
+- **verification-gates** — Detecting project type and running appropriate checks
+- **git-workflow-and-versioning** — Branch strategy and commit conventions
+- **security-and-hardening** — Secrets management and supply chain security