Skills
Skills own reusable workflows and behavioural contracts. They are exposed via ~/.agents/skills/ and published to opencode-config.
Skills
Section titled “Skills”| Skill | Description |
|---|---|
branch-context-consumer | Consume BranchContextPlugin injections in commands. Use when a command depends on an injected |
check-skill-updates | Check imported skills for upstream changes and apply updates. Use when reviewing whether externally imported skills have new upstream content, or when dot skill-updates reports available changes. |
cleanup-unnecessary-variables | Safe removal of unnecessary variables during code review and refactoring. Use when simplifying code, inlining temporary or single-use variables, or removing redundant aliases, while preserving runtime behaviour, evaluation order, and variables kept for readability or debugging. |
code-review | Review code changes along two axes - Standards (does it follow the repo’s conventions, plus a Fowler code-smell baseline?) and Spec (does it implement what the originating issue or spec asked for?). Use when reviewing a pull request, a branch, work-in-progress changes, or a diff. |
dotfiles-stow | REQUIRED when changing configs managed by ~/.config/dotfiles or ~/.config/dotfiles-private. Enforces editing stow source paths (not ad-hoc live paths) and using the dot command for stow/update/validation workflows. |
fallow-coexistence | Guidance for using Fallow alongside code-quality and framework skills without conflict. Use when running Fallow or acting on its findings — applying fix/suppress suggestions, interpreting dead-code or complexity output, or analysing Effect, Lit, or Home Assistant code — to decide what to apply, what to verify first, and how to configure Fallow. |
git-commit | Commit workflow using the dot git-commit gateway in the maintainer’s concise one-line style. Use only after the user explicitly requests a commit or push, including /commit or /commit-push. Never infer repeat authorisation from an earlier commit or push; never run raw git commit. |
git-context | Patterns for working with git branches, remotes, diffs against the default branch, and rebases. Use when resolving rebase conflicts, continuing interactive rebases, amending commits, or any git operation that would open an interactive editor. |
handoff | Compact the current conversation into a handoff document for another agent to pick up. |
home-assistant-frontend | Home Assistant frontend development with Lit Web Components and TypeScript. Use when working in the Home Assistant frontend repo, editing ha-* components, reviewing HA PRs, or applying HA-specific conventions (localization, theming, dialogs, panels, cards). |
home-assistant-lazy-context | Home Assistant frontend lazy-context, memoization, and hass removal guidance. Use when migrating Lit components from hass!: HomeAssistant, .hass=${...}, or broad hass access to context slices. |
home-assistant-list-components | Home Assistant list component migration and usage guidance. Use when editing ha-list, ha-list-item, ha-md-list, or migrating to ha-list-nav, ha-list-selectable, ha-list-item-button, ha-list-item-option, or ha-list-item-base. |
home-assistant-lit-rendering | Home Assistant Lit rendering extensions for HA components and context-aware picker callback shape. |
import-external-skill | Import skills from external repos into the local dotfiles skill library. Use when pulling in a skill from a public repo, reviewing an external skill set for useful additions, or adapting external skill content into existing local skills. |
lit-rendering | Lit rendering and picker callback-shape guidance for editing and reviewing Lit components. |
maintain-docs | Keep documentation current and accurate with recent code changes, across in-code docs (docstrings, annotations, comments), in-repo docs sites, and external docs repositories. Use when asked to update docs, check docs accuracy, keep documentation current, document recent changes, refresh docstrings or annotations, or catch documentation up with the codebase. Matches the codebase’s existing documentation density and stops before commit. |
pitchfork-dev-servers | Manage long-running local dev servers by precedence - the project’s own AGENTS.md workflow first, framework-native background mode next, then pitchfork as the fallback. Use when starting, stopping, restarting, checking, or tailing development servers, background servers, pitchfork.toml, pitchfork MCP tools, or local AGENTS/mise tasks that mention pitchfork. |
pkexec-root | Use pkexec first for commands that need root directly or indirectly. |
remove-single-use-functions | Safe inlining and removal of single-use functions during code review and refactoring. Use when a local, non-exported helper has exactly one real call site and inlining preserves behaviour and readability. |
research | Investigate a topic against primary sources and return cited findings, comparing credible maintainer and contributor perspectives when judgement is involved. Use when the user wants a topic researched, docs, API, or spec facts gathered, an external library or GitHub behaviour verified, competing views compared, or reading legwork delegated to a background agent. |
safe-process-signals | Safe process killing and signal handling for agent/subprocess contexts. Use when running pkill, killall, kill, or any process termination command from a shell subprocess, automated script, or coding agent. |
shared-workflows | Use, configure, maintain, or create reusable GitHub Actions workflows for personal and organisation repositories. Use when a task mentions shared workflows, reusable workflows, workflow_call, cross-repository workflow uses:, or the personal workflows repository; do not use for repository-specific or proof-of-concept CI unless evaluating whether it should be shared. |
staged-implementation | Execute broad changes one coherent, independently verifiable stage at a time. Use when work spans multiple independently reviewable changes, or when contracts, producer-consumer migrations, generated artefacts, or release packaging create an ordered multi-stage rollout; skip small single-purpose changes. |
types-enforce-ts | TypeScript type-safety guidance for editing and reviewing .ts, .tsx, .mts, and .cts files. |
writing-dot-skills | Craft for authoring skills that select reliably and stay lean - writing the description for correct auto-selection, matching instruction freedom to task fragility, deciding when to split into references or add scripts, and running quality and anti-pattern checks. Use when creating or revising a skill’s content or structure. For the file schema, frontmatter fields, and placement, use customize-opencode. |
writing-style | Write commit messages, PR and issue text, docs (README), code comments, and user-facing strings (notifications, UI labels, toasts, error messages) in the project owner’s voice: concise, human, UK English, no em-dashes, no robotic or marketing tone. Use when authoring or editing any of these. Defer to a repo’s established house style when it has one; otherwise this sets the default voice. |
Imported Skills
Section titled “Imported Skills”These skills were imported from other repos and tracked with an # origin: marker. Some are used as-is; others are adapted for local workflows.
| Skill | Description | Origin |
|---|---|---|
ask-questions-if-underspecified | Ask minimal clarifying questions only when ambiguity materially changes implementation. Use for routine underspecification; do not use for user-requested light or full grilling, plan stress-testing, or broad design interviews. | trailofbits/skills |
codebase-design | Shared vocabulary for designing deep modules. Use when the user wants to design or improve a module’s interface, find deepening opportunities, decide where a seam goes, make code more testable or AI-navigable, or when another skill needs the deep-module vocabulary. | mattpocock/skills |
css-motion-systems | CSS motion design and implementation for web interfaces. Use when designing or building transitions, animations, linear() easing, transform strategy, View Transitions API patterns, motion tokens, or reviewing motion quality and accessibility. | stolinski/s-stack |
ctx-agent-history-search | Use ctx to search local coding-agent history before acting. Use when prior agent sessions may contain relevant insights, decisions, attempts, or transcript context. | ctxrs/ctx |
diagnose | Disciplined workflow for diagnosing bugs - hard bugs, regressions, flaky behavior, and performance issues. Use when behavior is broken, failing, intermittent, or slower than expected and the agent needs a reproducible feedback loop before fixing. | mattpocock/skills |
domain-modeling | Build and sharpen a project’s domain model. Use when the user wants to pin down domain terminology or a ubiquitous language, challenge or record a design decision, or when another skill needs to maintain the domain model. | mattpocock/skills |
effect | Opinionated guide for building production TypeScript applications with Effect v4. Use when implementing Effect workflows, services, layers, schemas, configuration, schedules, caches, streams, HTTP clients, or tests. | kitlangton/skills |
fallow | Codebase intelligence for JavaScript and TypeScript. Free static layer finds unused code (files, exports, types, dependencies), code duplication, circular dependencies, complexity hotspots, architecture boundary violations, and feature flag patterns. Runtime coverage merges production execution data into the same health report for hot-path review, cold-path deletion confidence, and stale-flag evidence - a single local capture is free, while continuous/cloud runtime monitoring is paid. 94 framework plugins, zero configuration, sub-second static analysis. Use when asked to analyze code health, find unused code, detect duplicates, check circular dependencies, audit complexity, check architecture boundaries, detect feature flags, clean up the codebase, auto-fix issues, merge runtime coverage, or run fallow. | fallow-rs/fallow-skills |
grill-questions | Stress-test a plan or proposed change through focused one-question-at-a-time grilling, with light and full intensity. Use when the user says grill, grill me, grill me lightly, ask me a couple of questions, stress-test this plan, or wants question-led scrutiny before planning. | mattpocock/skills |
herdr | Control herdr from inside it. Manage workspaces and tabs, split panes, spawn agents, read output, and wait for state changes — all via CLI commands that talk to the running herdr instance over a local unix socket. Use when running inside herdr (HERDR_ENV=1). | ogulcancelik/herdr |
html | Writes and reviews semantic, accessible HTML and template markup that stays readable and low-noise. Use when creating or refactoring HTML or Svelte templates, cleaning up div soup, choosing better elements, improving form markup, fixing heading or landmark structure, or replacing custom controls with native HTML. | stolinski/s-stack |
hunk-review | Interacts with live Hunk diff review sessions via CLI. Inspects review focus, navigates files and hunks, reloads session contents, and adds inline review comments. Use when the user has a Hunk session running or wants to review diffs interactively. | modem-dev/hunk |
improve-codebase-architecture | Scan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick. | mattpocock/skills |
motion-choreography-patterns | Use when orchestrating multi-element UI motion, stagger systems, list reorder/insert/remove flows, modal and overlay stacks, gesture-driven transitions, and route-level choreography that preserves hierarchy and attention. | stolinski/s-stack |
opentui | Build terminal UIs with OpenTUI. Covers the core API, native audio, keymaps, React and Solid bindings, components, layout, keyboard input, plugins, and testing. | anomalyco/opentui |
prototype | Build a throwaway prototype to answer a design question. Use when the user wants to sanity-check whether a state model or logic feels right, or explore what a UI should look like. | mattpocock/skills |
vercel-cli | Vercel CLI expert guidance. Use when deploying, managing environment variables, linking projects, viewing logs, querying metrics, managing domains, or interacting with the Vercel platform from the command line. | vercel/vercel-plugin |
vercel-deployments-cicd | Vercel deployment and CI/CD expert guidance. Use when deploying, promoting, rolling back, inspecting deployments, building with —prebuilt, or configuring CI workflow files for Vercel. | vercel/vercel-plugin |
vercel-env-vars | Vercel environment variable expert guidance. Use when working with .env files, vercel env commands, OIDC tokens, or managing environment-specific configuration. | vercel/vercel-plugin |