opencodekit 0.21.4 → 0.21.6

package/dist/template/.opencode/skill/think-in-code/SKILL.md

@@ -0,0 +1,136 @@
+---
+name: think-in-code
+description: Use when answering questions that require counting, filtering, parsing, joining, or summarizing data — write a small script that prints only the answer instead of reading large files into context. Saves 90%+ tokens vs raw reads. Adapted from context-mode (mksglu/context-mode).
+version: 1.0.0
+tags: [context, workflow]
+dependencies: []
+---
+
+# Think in Code
+
+Compute answers with a small script. Don't drag raw data through context.
+
+## Core Principle
+
+> The model's job is to think. The script's job is to count, parse, filter, join. Then `console.log` only the answer.
+
+When you need a fact derived from data (logs, JSON, CSV, command output, file lists), the cheapest path is:
+
+1. Write 5–30 lines of code that produces the answer
+2. Run it
+3. Read **only** the printed answer
+
+Reading the raw data into context first is almost always wrong.
+
+## When to Use
+
+- Counting things in files / API output / logs ("how many failed runs in the last 100?")
+- Filtering large lists ("which dependencies haven't been updated in 6 months?")
+- Parsing structured output (`gh pr list --json`, `git log --pretty=...`, large JSON config)
+- Joining data across sources ("which files in `git diff` also have failing tests?")
+- Summarizing logs (top 10 error messages, error rate over time)
+- Computing diffs/intersections between two lists
+
+## When NOT to Use
+
+- The data is already small (<50 lines and you need most of it)
+- You need to **read** the content for understanding, not extract a fact (e.g. reviewing a PR)
+- The script itself would be longer than just reading the slice you need
+- A single `grep -c` or `wc -l` already answers it — just run that
+
+## Quick Decision
+
+| Situation                               | Approach                                        |
+| --------------------------------------- | ----------------------------------------------- |
+| "How many X in Y?"                      | Script → `console.log(count)`                   |
+| "Which Z match condition?"              | Script → `console.log(matches.join('\n'))`      |
+| "Top N by metric?"                      | Script → `console.log(top.map(...).join('\n'))` |
+| "What does this code do?"               | Read the file                                   |
+| "What's broken in this 30-line config?" | Read the file                                   |
+| "Count errors in 2MB log"               | Script — never `cat` it                         |
+
+## Patterns
+
+### Node one-liner (preferred for JSON / npm / fs work)
+
+```bash
+node -e "
+const fs = require('fs');
+const data = JSON.parse(fs.readFileSync('package-lock.json', 'utf8'));
+const deps = Object.keys(data.packages || {}).filter(k => k.startsWith('node_modules/'));
+console.log('Total deps:', deps.length);
+console.log('Unique top-level:', new Set(deps.map(d => d.split('/')[1])).size);
+"
+```
+
+### Python one-liner (preferred for CSV / data crunching)
+
+```bash
+python3 -c "
+import csv, sys
+with open('data.csv') as f:
+    rows = list(csv.DictReader(f))
+errors = [r for r in rows if r['status'] == 'error']
+print(f'errors: {len(errors)} / {len(rows)}')
+print(f'top hosts:', sorted({r[\"host\"] for r in errors})[:5])
+"
+```
+
+### Bash (only when output is guaranteed small)
+
+```bash
+# OK — output is one number
+git log --since='1 week ago' --oneline | wc -l
+
+# OK — already filtered small
+gh pr list --state open --json number,title --jq '.[] | select(.title | contains("fix")) | .number'
+
+# NOT OK — dumps everything into context
+cat huge-log.txt | grep ERROR
+# Better:
+grep -c ERROR huge-log.txt                    # if you only need the count
+grep ERROR huge-log.txt | head -20            # if you need samples
+```
+
+### Save script to a file when it's reusable
+
+```bash
+cat > /tmp/count-deps.js <<'EOF'
+const fs = require('fs');
+const lock = JSON.parse(fs.readFileSync(process.argv[2], 'utf8'));
+const pkgs = Object.keys(lock.packages || {});
+const stale = pkgs.filter(p => p.includes('node_modules/') && !p.includes('node_modules/.'));
+console.log(JSON.stringify({ total: pkgs.length, packages: stale.length }, null, 2));
+EOF
+node /tmp/count-deps.js package-lock.json
+```
+
+## Anti-Patterns
+
+| Anti-Pattern                                              | Why It's Wrong                               | Do Instead                                  |
+| --------------------------------------------------------- | -------------------------------------------- | ------------------------------------------- |
+| `cat huge.json` then "let me parse this in my head"       | Pulls 100KB+ into context for one answer     | `node -e "..."` to compute and print answer |
+| `gh pr list --json ...` printing all fields               | Dumps 50+ PRs of metadata you don't need     | `--jq` to filter to just the field you want |
+| `find . -name '*.ts'` to count files                      | Lists every path                             | `find . -name '*.ts' \| wc -l`              |
+| Reading 5 large logs to compare error rates               | 5x context bloat for one comparison          | Script that opens all 5 and prints summary  |
+| `curl https://api/...` raw piped to read                  | Whole response body in context               | `curl ... \| jq '.field'` or save to file   |
+| Asking the model to "estimate" instead of running a count | Hallucination risk; counts are deterministic | Run the script                              |
+
+## Verification
+
+Before considering an answer "done":
+
+1. The script ran without error
+2. The printed output is what you reasoned about (don't substitute memory for output)
+3. If the question was "how many", the script printed a number — not raw rows you then counted manually
+
+## Why This Skill Exists
+
+Adapted from the **Think in Code** pillar of [context-mode](https://github.com/mksglu/context-mode). The original ships a sandboxed executor that _forces_ this pattern; we keep the discipline as a prompt-level skill so it works without bundling new infrastructure.
+
+The savings compound: a single avoided 100KB read pays for many script iterations, and downstream summarization/handoff becomes cheaper too.
+
+## References
+
+- context-mode: https://github.com/mksglu/context-mode
+- Pairs with: `verification-before-completion`, `code-search-patterns`, `rtk-command-compression`

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

@@ -0,0 +1,137 @@
+---
+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/package.json

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