opencode-skills-collection 3.1.12 → 3.1.13

package/bundled-skills/design-system/references/motion-choreography.md

@@ -0,0 +1,111 @@
+# Motion choreography — a generalizable animation guideline
+
+When to animate, which transitions earn their keep, how long, and the craft that
+separates intentional motion from jitter. **Framework-agnostic** — the rules hold for
+plain CSS, the Web Animations API, the browser View Transition API, a JS motion library,
+or React's `<ViewTransition>`. Load from design-system's Motion section when a UI has
+state changes, navigation, list changes, or reveals worth animating.
+
+> Adapted & generalized from the Web Interface Guidelines (`vercel-labs/web-interface-guidelines` @ `4e799d4`, 2026-04-06) and the React View Transitions skill (`vercel-labs/agent-skills` @ `f8a72b9`, 2026-06-10). Their API specifics are React/Next-bound; the *choreography* below is portable.
+
+## 1. When to animate — earn every transition
+
+Animate only when the motion **communicates** one of: a spatial relationship, continuity
+("same thing, new place"), cause→effect, that data arrived, or deliberate delight.
+**If you can't articulate in one sentence what a transition communicates, cut it.** Motion
+with no message is noise that costs performance and attention.
+
+- **Input-driven, never autoplay.** Animate in response to a user action or a state change
+  they caused — not on a timer that plays at them.
+- This is the motion-specific case of restraint-rule: the default is *no* animation; a clear
+  communicative purpose is what forces a yes.
+
+## 2. Which transitions earn their keep — priority order
+
+When several kinds of change happen, implement every one that *applies* (not "pick one"),
+in roughly this order of value:
+
+1. **Shared element** — the same object persists across views (thumbnail → hero). Says "this
+   is the same thing, going deeper." Highest value; most worth the effort.
+2. **Reveal** — skeleton/loading → real content. Says "data loaded."
+3. **List identity** — items keep identity as the set reorders/filters. Says "same items,
+   new arrangement" (animate position, not a wholesale fade).
+4. **State change** — something enters/exits (panel, toast, row). Says "this appeared/left."
+5. **Route/section change** — moving to a new place.
+
+Skip a level only when the UI has no such change. A background refresh / silent
+revalidation should animate **nothing**.
+
+## 3. Style by the *kind* of navigation — direction must be honest
+
+The animation style must not imply a spatial relationship that isn't there:
+
+| Navigation kind | Animation | Why |
+|---|---|---|
+| **Hierarchical** (list → detail, parent → child) | directional slide (in from the side, out the other) | direction encodes depth |
+| **Ordered sequence** (prev/next photo, carousel, paginated) | directional slide; "next" from the right, "prev" from the left | direction encodes position |
+| **Lateral / sibling** (tab ↔ tab, unordered) | **fade / cross-fade** — NOT a slide | there's no depth; a slide lies about it |
+| **Reveal** (skeleton → content) | fade or short slide-up | content arriving |
+| **Background refresh / revalidation** | none | nothing happened the user must track |
+
+The single most common motion mistake is a directional slide on lateral navigation — it
+falsely implies forward/back depth between peers.
+
+## 4. Timing & easing (starting points, not law)
+
+| Interaction | Duration |
+|---|---|
+| Direct toggle (expand/collapse, switch) | 100–200 ms |
+| Route / section transition (slide) | 150–250 ms |
+| Reveal (skeleton → content) | 200–400 ms |
+| Shared-element morph | 300–500 ms |
+
+- **Easing matches the change:** entrances `ease-out` (decelerate in), exits `ease-in`
+  (accelerate away), positional moves `ease-in-out`. Choose by what's changing (size,
+  distance, trigger) — bigger/further → a touch longer.
+- A playful/toy direction (design-thinking) may stretch these and add spring/bounce; a
+  restrained/professional one keeps them tight. Match the feel to the chosen direction
+  rather than defaulting to the numbers.
+
+## 5. Mechanics — what to animate, and how (any stack)
+
+- **Compositor-friendly only:** animate `transform` and `opacity`. **Never** animate layout
+  properties (`width`, `height`, `top`, `left`) — they trigger reflow and jank.
+- **Never `transition: all`** — list the exact properties; `all` silently animates
+  layout-affecting props and janks.
+- **Correct `transform-origin`** — anchor motion where it "physically" starts (a menu from
+  its trigger, not screen-center).
+- **Interruptible** — a new user input cancels/redirects the in-flight animation; motion is
+  never a modal wait.
+- **SVG transforms** — apply to a `<g>` wrapper with `transform-box: fill-box;
+  transform-origin: center;` (avoids Safari origin bugs).
+- **Stack preference:** CSS > Web Animations API > JS library. Prefer the platform; reach for
+  a library only when the platform can't express it.
+
+## 6. Craft details that separate polished from amateur
+
+- **Motion blur on morphs.** A shared-element morph reads as fast and physical with a brief
+  blur at mid-transition (e.g. `filter: blur(3px)` around the 30% mark), clearing to sharp.
+- **Don't raster-scale text.** A shared-element morph between different text sizes (`h3 → h1`)
+  scales a *bitmap* of the small text up → a blurry ghost. Instead hold/cross-fade the text
+  (show the new text at full resolution, hide the old snapshot) rather than scaling it.
+- **Isolate persistent chrome.** Headers, navs, sidebars, sticky toolbars that stay on screen
+  across a transition must NOT slide with the page content — give them their own transition
+  identity (or exclude them) so they stay put while content moves beneath.
+- **Reveal anti-flicker.** If you show a spinner/skeleton, add a short show-delay (~150–300 ms)
+  and a minimum visible time (~300–500 ms) so a fast response doesn't flash the loader. (See
+  design-ux interaction add-ons.)
+
+## 7. Accessibility — reduced motion
+
+Honor `prefers-reduced-motion` for **public / multi-user** builds: drop the tweens (keep the
+end state / a 0s cross-fade), don't remove the information the motion conveyed. For
+**personal/single-user** projects this repo deliberately overrides that flag — see
+`motion-preference-rule`. Either way, avoid parallax, large viewport-spanning transforms, and
+strobing regardless of the flag.
+
+## The one-line test
+
+Before adding a transition: *what does this communicate, and is the style honest about it?*
+If you can't answer the first, cut it; if the style implies depth/position that isn't there
+(a slide between peers), change the style.

package/bundled-skills/design-thinking/SKILL.md

@@ -0,0 +1,109 @@
+---
+name: design-thinking
+description: Direction and intent for frontend design. Use with design when defining purpose, tone, domain, color world, and review bar; includes cross-domain lens from cinema, architecture, marketing, UX, automotive, industrial design.
+risk: unknown
+source: https://github.com/connerkward/ckw-design-skill/tree/main/design-thinking
+source_repo: connerkward/ckw-design-skill
+source_type: community
+date_added: 2026-07-01
+license: MIT
+license_source: https://github.com/connerkward/ckw-design-skill/blob/main/LICENSE
+author: Conner K Ward
+---
+
+# Design thinking
+## When to Use
+
+Use this skill when you need direction and intent for frontend design. Use with design when defining purpose, tone, domain, color world, and review bar; includes cross-domain lens from cinema, architecture, marketing, UX, automotive, industrial design.
+
+
+Apply with the **design** skill on every design task. Do this before coding.
+
+## Design thinking (before coding)
+
+- **Purpose**: What problem does this interface solve? Who uses it?
+- **Tone**: Pick an extreme and execute with intention — e.g. brutally minimal, maximalist, retro-futuristic, organic/natural, luxury/refined, playful/toy-like, editorial/magazine, brutalist/raw, art deco/geometric, soft/pastel, industrial/utilitarian.
+- **Constraints**: Framework, performance, accessibility.
+- **Differentiation**: One thing that makes it unforgettable.
+
+Commit to one bold direction. Intentionality over intensity.
+
+## Reserve impact for punctuation (use sparingly for effect)
+
+High-impact devices — full-bleed media, dramatic motion, oversized type, a saturated accent, parallax — lose their force the moment they become the default. If every section is a full-screen video, none of them land. Choose 1–2 moments to go big (the hero, the payoff) and make everything else quiet and contained, so the big moments read as deliberate punctuation rather than noise. Restraint is what gives the rare full-bleed beat its hit; wall-to-wall intensity reads as flat. This is the luxury of reduction — a single bold gesture in generous negative space beats maximalism. Applies equally to scale, color (one accent, not five), and motion (one signature move, not constant animation).
+
+## Domain and color
+
+- **Domain**: 5+ concepts, metaphors, or vocabulary from the product's world (territory, not features).
+- **Color world**: 5+ colors that "belong" in that world — what you'd see if this product were a physical space. Not "warm" or "cool"; name actual colors from that domain.
+- **Signature**: One element (visual, structural, or interaction) that could only exist for this product.
+
+## Review bar
+
+Ask: "Would I put my name on this?" Design-lead review means: not "does it work?" but "is this unmistakably intentional and crafted?"
+
+Non-negotiable craft invariants (a single failure fails the review):
+
+- **No font pop-in. Ever.** Title/display text must never flash a fallback face or reflow as the webfont loads. Gate it on `document.fonts.ready` and fade in. See design-system → *Never let fonts pop in*.
+- **First seen, first loaded.** Whatever is in the opening viewport (hero text, hero media, brand mark) must be prioritized to paint complete and correct before anything below the fold loads. See design-system → *Loading order*.
+
+---
+
+## Cross-domain lens
+
+When defining direction, choose which disciplines fit the product and apply 2–3 principles from each. Examples: dashboard → UX + automotive; brand campaign → cinema + marketing; app → UX + industrial design.
+
+### Cinema
+
+- **Framing and composition**: Viewport as frame; rule of thirds, leading lines, foreground/mid/background depth. What's in focus = primary hierarchy.
+- **Pacing and rhythm**: Sequence of reveals (like editing). One well-orchestrated load or scroll beat beats scattered motion.
+- **Color and mood**: Color grading = mood; consistent palette as "look."
+- **Focus and depth**: Focal plane and depth of field → visual hierarchy and layering (blur, opacity, scale).
+
+### Architecture
+
+- **Scale and proportion**: Human scale, rhythm of columns/grid, proportion of elements to viewport.
+- **Wayfinding**: User always knows where they are and where they can go (orientation, nav, breadcrumbs).
+- **Material and light**: Texture and shadow create depth; light direction implies elevation and emphasis.
+- **Negative space**: Intentional emptiness; space as structure, not leftover.
+- **Thresholds**: Entrance and transition moments (landing → app, modal open) as deliberate "crossings."
+
+### Marketing
+
+- **One hero message**: Single value proposition or takeaway above the fold; hierarchy of message, not feature list.
+- **Emotional vs rational**: Decide whether the first beat is emotional pull or rational clarity; align layout and copy.
+- **CTA prominence**: Primary action unmistakable; secondary actions present but not competing.
+- **Audience fit**: Tone and imagery match who it's for; avoid "generic user."
+- **Brand consistency**: One coherent voice and visual system across the artifact.
+
+### UX
+
+- **Goals and tasks**: Design around user goals and key tasks; reduce steps to completion.
+- **Information architecture**: Clear grouping and hierarchy; cognitive load minimal.
+- **Feedback and state**: Every action has visible feedback; loading, success, error states considered.
+- **Accessibility**: Color contrast, focus order, semantics. (Reduced motion: honor `prefers-reduced-motion` for public/multi-user projects; personal projects may ship full motion.)
+- **Progressive disclosure**: Show essentials first; detail on demand (expand, modal, step).
+
+### Automotive (exterior / interior)
+
+- **Silhouette and character**: One strong silhouette or "character line"; recognizable at a glance.
+- **Surface language**: Tension, flow, continuity of surfaces (like body panels); avoid arbitrary bumps.
+- **Proportion**: Balance of "cab" (content) to "wheel" (chrome/nav); stable, not top-heavy.
+- **Materials and trim**: Hard/soft, cold/warm, matte/gloss as hierarchy; primary = one material language, accent = another.
+- **Driver-centric layout**: Primary controls and info where the "driver" (user) looks first; secondary in reach but not competing.
+- **Control hierarchy**: One primary action surface; secondary actions grouped and identifiable.
+
+### Industrial design
+
+- **Form follows function**: Shape and layout reflect use; no decoration without reason.
+- **Material honesty**: Materials (or visual equivalent: texture, weight) feel appropriate to the function.
+- **Affordances**: Shape suggests use (clickable, draggable, input); obvious without labels where possible.
+- **Tactility**: Buttons and controls feel "pressable" or "grabbable" (hover/active state, depth).
+- **Product personality**: One clear character (friendly, serious, playful, premium); consistent across the UI.
+- **Simplify**: Remove until it breaks; "best part is no part" for UI clutter.
+
+## Limitations
+
+- Use this skill only when the task clearly matches its upstream source and local project context.
+- Verify commands, generated code, dependencies, credentials, and external service behavior before applying changes.
+- Do not treat examples as a substitute for environment-specific tests, security review, or user approval for destructive or costly actions.

package/bundled-skills/design-ux/SKILL.md

@@ -0,0 +1,75 @@
+---
+name: design-ux
+description: UX / usability audit — heuristic evaluation of INTERACTIVE UIs (not just visual polish). Load with design when a UI "feels off", "sucks to use", is hard to learn, needs an instruction wall, or before shipping an interactive tool/editor/app. Scores the RENDERED UI against Nielsen's 10 +...
+risk: unknown
+source: https://github.com/connerkward/ckw-design-skill/tree/main/deterministic-design/design-ux
+source_repo: connerkward/ckw-design-skill
+source_type: community
+date_added: 2026-07-01
+license: MIT
+license_source: https://github.com/connerkward/ckw-design-skill/blob/main/LICENSE
+author: Conner K Ward
+---
+
+# design-ux — usability audit (heuristic evaluation)
+## When to Use
+
+Use this skill when you need uX / usability audit — heuristic evaluation of INTERACTIVE UIs (not just visual polish). Load with design when a UI "feels off", "sucks to use", is hard to learn, needs an instruction wall, or before shipping an interactive tool/editor/app. Scores the RENDERED UI against Nielsen's 10 +...
+
+
+Usability ≠ aesthetics. design-system/design-spatial make it *look* right; this checks whether a first-timer can do the task **without being told how**. Use it whenever a UI "sucks to use," needs a paragraph of instructions, or before shipping anything interactive.
+
+## Rule 0 — fresh eyes, on the rendered artifact (inherited from design-spatial §1)
+
+**Never self-grade.** The builder rationalizes its own UI. Render the *live* UI in its **default first-load state** (not a hand-arranged screenshot), capture an **interaction trace** of the primary task, and have a **separate judge** (a subagent/VLM that did NOT build it) score it. A described list of changes is not an audit — the audit is a fresh judge hunting for what's *wrong* on the real screen.
+
+## The procedure
+
+1. **Name the primary task(s)** the UI exists for (e.g. "trim a clip and set its speed, then export"). The audit is relative to these, not to abstract prettiness.
+2. **Render default state + trace the task.** Screenshot the first-load UI (wide AND narrow — overflow gate from design-spatial §2). Then actually perform the primary task and screenshot each step.
+3. **Score every heuristic** (table below) on the artifact: pass / violation, **severity** (blocker / major / minor), a *specifically located* finding, and a concrete fix. Separate judge does this.
+4. **Prioritize**: blockers → majors → minors; cluster fixes that touch the same surface.
+5. **Fix, then RE-RENDER and RE-SCORE.** Do not claim fixed without re-auditing the new artifact (verify-outputs-rule).
+
+## Heuristics — score each (Nielsen's 10, 1994) + interaction add-ons
+
+| # | Heuristic (Nielsen) | What to check in THIS UI |
+|---|---|---|
+| 1 | **Visibility of system status** | Every action has visible feedback; current state/selection/mode always legible; progress for slow ops. |
+| 2 | **Match the real world** | Known metaphors & conventions (e.g. NLE: clips, trim handles, playhead) — not bespoke gestures users must learn. |
+| 3 | **User control & freedom** | Undo/redo, cancel, clear exits from any state; reversible by default. |
+| 4 | **Consistency & standards** | Same thing looks/behaves the same; platform conventions (⌘Z, Delete, drag-to-move) honored. |
+| 5 | **Error prevention** | Invalid states made impossible; destructive actions confirmed or trivially undoable. |
+| 6 | **Recognition over recall** | Options/affordances **visible** — no memorizing. *An instruction wall is a failure of this heuristic: if you must explain scroll-to-zoom / drag-edge / double-click in prose, the affordance is missing.* |
+| 7 | **Flexibility & efficiency** | Defaults carry novices; shortcuts/accelerators for experts; sensible first-run with nothing configured. |
+| 8 | **Aesthetic & minimalist** | Signal over chrome; no irrelevant elements competing; the *primary surface* carries the most visual weight. |
+| 9 | **Recognize/diagnose/recover from errors** | Plain-language errors (not raw stderr), and a path out. |
+| 10 | **Help & documentation** | Rarely needed if 1–9 hold; task-oriented, in-context, not a top-of-page lecture. |
+
+**Interaction add-ons (compose, don't restate):**
+- **Don't-make-me-think (Krug):** affordances self-evident; the UI teaches itself. Instruction paragraph ⇒ affordance debt (ties to #6).
+- **Fitts / transit time (design-spatial §3):** controls sit near where the task leaves the cursor. A selected object's properties belong **adjacent to the object** (dock/popover), not in a far panel — every edit shouldn't be a round-trip.
+- **Discoverability of gestures:** any non-obvious gesture (wheel, edge-drag, dbl-click) needs a **visible affordance** (handle, hover cue, icon) or it doesn't exist for most users.
+- **Visual-weight match (design-spatial):** the surface the user *operates* (timeline, canvas, editor) should be the visual hero — not a thin strip under a big passive preview.
+- **Progressive disclosure (design-thinking UX):** essentials first; advanced on demand. But disclosure ≠ hiding the primary tool.
+- **Tooltip timing:** delay the *first* tooltip in a group (~300–700ms hover-intent) so sweeping the cursor over controls doesn't flash tips; once one is open, **peers show instantly** (no per-tooltip re-delay) while the user scans the row. Fires-on-every-hover is noise; re-delays-on-each-neighbor is sluggish.
+- **Scroll-position restore:** Back/Forward returns the user to where they were, not the top — losing place after a detail→back trip is a silent, repeated tax. Browsers do this by default; the bug is *breaking* it with manual scroll resets or client routing that forgets.
+- **Idempotency on submit:** mutating actions carry an idempotency key so a double-click, retry, or flaky-network resend can't duplicate the effect (a second charge, a duplicate post). Pairs with "disable submit during the in-flight request + spinner" — the key is the server-side guarantee, the disable is the client-side courtesy.
+
+*(Tooltip / scroll-restore / idempotency from the Web Interface Guidelines, `vercel-labs/web-interface-guidelines` @ `4e799d4`, 2026-04-06.)*
+
+## Output format
+
+A scored table — `Heuristic | Finding (located) | Severity | Fix` — then a prioritized fix list (blockers first). Severity: **blocker** = can't complete the task / actively misleading; **major** = slows or confuses; **minor** = polish.
+
+## Relation to the rest of design
+
+- **design-spatial** owns the render-then-critique mechanism + Fitts/transit + overflow gate; this skill applies that lens to *usability* specifically and adds the heuristic scorecard.
+- **design-thinking** owns the UX *principles* (goals/tasks, IA, feedback, accessibility, progressive disclosure); this skill turns them into a *scored audit + fix loop*.
+- Run a usability audit **before** declaring an interactive UI "done" — alongside the visual critique, not instead of it.
+
+## Limitations
+
+- Use this skill only when the task clearly matches its upstream source and local project context.
+- Verify commands, generated code, dependencies, credentials, and external service behavior before applying changes.
+- Do not treat examples as a substitute for environment-specific tests, security review, or user approval for destructive or costly actions.

package/bundled-skills/dev-to-hashnode/README.md

@@ -0,0 +1,62 @@
+# dev-to-hashnode
+
+**Content platform skill** — Publish on developer blogging platforms effectively.
+
+## What It Does
+
+Guides you through publishing on Dev.to and Hashnode: platform differences, cross-posting strategy, canonical URLs, tagging, formatting, and building followers.
+
+## When to Use
+
+- Publishing technical content on Dev.to or Hashnode
+- Setting up cross-posting workflow
+- Optimizing for platform-specific audiences
+- When you say "Dev.to," "Hashnode," "cross-posting," or "canonical URL"
+
+## Quick Start
+
+```
+/dev-to-hashnode
+
+I have a tutorial on my blog and want to cross-post it
+to Dev.to and Hashnode. What's the best strategy to
+maximize reach without hurting my SEO?
+```
+
+## Key Sections
+
+1. **Platform Comparison** — Dev.to vs Hashnode differences
+2. **Cross-Posting Strategy** — Canonical URL decisions
+3. **Dev.to Optimization** — Frontmatter, tags, what performs
+4. **Hashnode Optimization** — Settings, features, audience
+5. **Content Formatting** — Structure that works on both
+6. **Building Followers** — Consistency and engagement
+
+## Platform Comparison
+
+| Feature | Dev.to | Hashnode |
+|---------|--------|----------|
+| Monthly visitors | ~10M+ | ~3M+ |
+| Custom domain | No | Yes (free) |
+| Newsletter | No | Built-in |
+| Audience | Broader, beginners | More senior |
+| Best for | Maximum reach | Building your brand |
+
+## Cross-Posting Order
+
+1. Publish on your blog first (canonical)
+2. Wait 1-2 days for Google indexing
+3. Cross-post to Dev.to with canonical URL
+4. Cross-post to Hashnode with canonical URL
+
+## Tools
+
+- **[Octolens](https://octolens.com)** — Monitor platforms for trends and mentions
+- **Carbon** — Beautiful code screenshots
+- **Canva** — Cover image design
+
+## Related Skills
+
+- `developer-audience-context` — Know who you're writing for
+- `hacker-news-strategy` — Drive traffic from HN
+- `x-devs` — Promote posts on Twitter/X