Skills

Coordinate multiple coding agents in shared repos with task packets, worktree or branch isolation, path ownership, verification loops, and PR or CI follow-through. Use when supervising ticket-driven multi-agent implementation or conflict-safe execution. Do not use for abstract LLM task splitting without repo state; use orchestrator-workers instead.

Analyze a list of open questions and suggest up to three answers for each. Use when the user wants options, recommendations, or help resolving multiple unanswered questions.

Review software architecture before editing. Use when asked to assess module boundaries, interfaces, layering, ownership, seams, adapters, locality, coupling, shallow modules, or refactor candidates. Produces ranked architecture candidates and waits for explicit approval before changing code. For normal code review use code-reviewer; for approved behavior-preserving edits use refactoring.

Map value creation, delivery, and capture with the Business Model Canvas. Use when evaluating startups, pivots, product strategy, revenue streams, cost structure, partners, channels, or business-model coherence; avoid for deep customer-job research, roadmap breakdowns, or macro-environment scans.

Choose Tailwind CSS v4 component styling patterns. Use when building Tailwind components, buttons, cards, variants, slots, state styles, or design tokens; choosing utilities vs CVA vs tailwind-variants; avoiding @apply; or migrating v3 component patterns. For project-level Tailwind installation, PostCSS/Vite setup, @source, plugins, or browser support, use tailwind-v4-configuration instead.

Decide whether to abstract, duplicate, inline, or split code. Use when creating shared utilities, components, facades, hooks, service wrappers, or DRY/WET refactors; reviewing parameter-heavy helpers, option flags, shallow facades, or premature abstractions. For broad behavior-preserving restructuring use refactoring; for component extraction use decompose.

Review code for concrete defects and ranked risk. Use when asked to review diffs, pull requests, changed files, snippets, or implementation plans for bugs, security, performance, UX, API contracts, tests, concurrency, error handling, state/data hazards, accessibility, dependencies, or observability. Produces findings first with file:line evidence. For factual diff explanation use explain-diff; for architecture-only review use architecture-review.

Simplify recently changed code without changing behavior. Use after implementation when working code has excess nesting, repetition, indirection, unclear names, redundant branches, or needless abstraction. Scope stays near touched code and favors guard clauses and readability. For larger planned restructuring use refactoring; for extracting component pieces use decompose.

Detect sloppy-code signals with repo-wide search metrics and sampled evidence. Use when asked to audit codebase quality, "vibe coding", `isRecord`, broad `Record<string, unknown>` guards, fallback usage, excessive null guards, non-null assertions, unsafe type assertions, `node:*` imports in browser/shared code, swallowed errors, TODO debt, or code smell hotspots before refactoring.

Identify cognitive biases shaping product decisions and user behavior. Use when auditing decision points, conversion flows, pricing, framing, defaults, or research interpretation; avoid when a narrower bias skill such as loss aversion, status quo bias, halo effect, social proof, or Hick's Law directly fits.

Improve clarity by making content and interfaces easier to process. Use when auditing readability, hierarchy, labels, landing-page copy, onboarding text, or trust created by simplicity; avoid when the main issue is task complexity, choice overload, or staged information reveal.

Reduce unnecessary mental effort with Cognitive Load Theory. Use when complex workflows, onboarding, forms, information architecture, or feature-rich interfaces overwhelm users; separate intrinsic task difficulty from extraneous UI friction and avoid using this only for copy clarity or choice-count problems.

Draft or review Conventional Commits messages with type, optional scope, imperative summary, body, footer, and breaking-change notes. Use when user asks for a commit message, commit title and body, changelog-safe wording, or commit-format review. Do not use for PR descriptions; use summarize-branch.

Apply CSS container queries for parent-size responsive components. Use when cards, widgets, panels, sidebars, forms, or component-library elements must adapt to their container width with @container, container-type, container-name, or Tailwind @container variants. Use media queries instead for page-level viewport layout, global breakpoints, or full-page composition.

Create ethical information gaps that earn attention and resolve with real payoff. Use when writing headlines, notifications, teasers, onboarding reveals, or feature-discovery prompts; avoid fake urgency, vague clickbait, or habit-loop work better handled by Hooked or self-initiated triggers.

Split an oversized component into focused helpers, hooks, and sub-components. Use when React/UI code mixes rendering, state, effects, handlers, data shaping, and repeated sections, or when a file is hard to scan. Preserve behavior and avoid generic abstractions. For general code restructuring use refactoring; for abstraction decisions beyond one component use code-architecture-wrong-abstraction.

Analyze ambiguous problems, hard decisions, root causes, product strategy, or tradeoffs with useful frameworks, assumptions, validation, and next actions. Use when user needs structured thinking before choosing a path.

Design focused practice loops for skill improvement. Use when learning a skill, breaking a plateau, creating training routines, onboarding practitioners, or choosing feedback and challenge levels; avoid for generic productivity, knowledge organization, or project delivery planning.

Build shared understanding before action by interviewing the user about ambiguous implementation, product, planning, or design tasks. Use when goal, scope, constraints, risks, success criteria, done state, or next action are unclear; when user wants a thinking partner; or when user needs a handoff-ready task prompt. Do not write PRDs; use to-prd for product requirements.

Collect project context and documented best practices for clear framework, library, SDK, language, and tool tasks. Use before acting on external APIs or conventions. Stop when directive or target is unclear.

Dogfood a web app or local URL with exploratory QA, bug hunt, UX review, console checks, screenshots, videos, repro steps, and severity report. Use when user asks to test, QA, find issues, review quality, or explore site/app behavior. Do not inspect source code during testing.

Estimate engineering effort from scope, risk, unknowns, and verification cost. Use when sizing features, splitting work, planning sprints, comparing implementation options, or deciding whether a task is XS through XL; avoid for product value, requirements quality, or business-case analysis.

Automate or test Electron desktop apps through agent-browser and Chrome DevTools Protocol, including Slack, VS Code, Discord, Figma, Notion, Spotify, and similar apps. Use when user asks to control, connect to, inspect, click, fill, screenshot, or interact with a native Electron app UI. Do not use for normal web URLs.

Run an evaluator-optimizer loop by generating candidate outputs, scoring against a rubric or tests, revising, and stopping on pass, budget, or plateau. Use when quality criteria are explicit and iterative refinement is cheaper than failure. Do not use when no reliable eval signal exists.

Explain code diffs in Markdown, one changed file at a time. Use when user asks to explain unstaged changes, staged changes, a commit, commit range, branch diff, PR diff, or pasted diff. Ask for diff source when missing.

Explain changes made yesterday as a simple list. Use when user asks what changed yesterday, what was implemented yesterday, or needs a non-technical change summary from recent git work.

Trace a specific problem to systemic root causes with Five Whys. Use when investigating incidents, recurring bugs, churn, process failures, delays, or unexplained outcomes; require evidence at each step and avoid broad strategy analysis or blame-focused retrospectives.

Diagnose behavior change with B=MAP motivation, ability, and prompt. Use when users do not take a target action, onboarding stalls, conversion drops, feature adoption lags, or prompts fire at the wrong moment; avoid for full habit-loop design better handled by Hooked.

Shape long-running autonomous work into one durable goal with stop condition, validation loop, checkpoints, progress format, and pause rules. Use when user wants an agent to keep making scoped progress across migrations, refactors, prototypes, evals, retry loops, or prompt optimization until verifiably done. Do not use for loose backlog lists or one-shot answers.

Use Tit for Tat to manage repeated interactions with reciprocity, cooperation, and boundaries. Use when navigating workplace dynamics, partnerships, negotiations, conflicts, vendor relationships, or product systems with reciprocal behavior; avoid for one-shot decisions or zero-sum framing.

Pressure-test, reduce, and rewrite prompts for GPT-5.5. Use when the user asks to grill, audit, critique, harden, improve, optimize, simplify, de-noise, or rewrite a prompt, system prompt, developer instruction, agent playbook, or tool-use workflow specifically for GPT-5.5; especially when it may contain no-op instructions, contradictions, vague rules, missing success criteria, missing output rules, missing validation, unsupported claims, or unclear stop rules.

Model complex systems as nodes, edges, flows, and dependencies. Use when mapping stakeholder networks, causal loops, product ecosystems, architecture dependencies, knowledge graphs, or non-linear strategy problems; avoid when a simple hierarchy, roadmap, or checklist is enough.

Use halo-effect analysis for first impressions and perception spillover. Use when brand polish, visual quality, flagship features, reviews, or spokesperson credibility may shape trust in unrelated product areas; avoid for general trust, social proof, or readability problems.

Reduce decision time by managing choice count and choice structure with Hick's Law. Use when designing menus, navigation, plans, filters, onboarding paths, settings, or feature sets with too many options; avoid for complex-task load, staged disclosure, or CTA visibility issues.

Design habit-forming product loops with trigger, action, variable reward, and investment. Use when improving retention, engagement loops, repeat use, notifications, or products meant to become routines; avoid for single-action conversion diagnosis better handled by Fogg B=MAP.

Break ambiguous questions into mutually useful hypotheses and tests. Use when validating product ideas, debugging uncertain causes, planning research, prioritizing experiments, or turning strategy questions into evidence plans; avoid for root-cause chains needing Five Whys.

Reframe product strategy around customer progress with Jobs to Be Done. Use when researching motivations, switching behavior, competitive alternatives, unmet needs, feature framing, or value propositions; avoid for backlog story syntax, delivery hierarchy, or business-model economics.

Improve processes through small continuous changes, waste reduction, and PDCA cycles. Use when optimizing workflows, retrospectives, team operations, quality problems, or incremental product-delivery improvements; avoid for visualizing flow only, root-cause analysis only, or large strategic redesign.

Visualize and improve delivery flow with Kanban. Use when managing work-in-progress, bottlenecks, queues, service classes, cycle time, or team workflow policies; avoid for broader continuous-improvement culture, root-cause analysis, or product hierarchy planning.

Prioritize product features with the Kano model of customer satisfaction. Use when sorting feature ideas, roadmap items, requirements, or service attributes into must-haves, performance drivers, delighters, low-value work, and reverse effects; use to decide what to protect, improve, add, defer, remove, or validate.

Extract one reusable skill pattern from current session, such as a recurring error fix, debugging tactic, tool combo, project convention, or workflow worth saving. Use when user asks to learn, remember, capture, or turn session knowledge into a skill. Ask before writing new skill files; skip one-off fixes.

Create a letter-from-future planning artifact for startup, product, roadmap, pivot, project kickoff, quarterly planning, or stakeholder alignment. Use when user needs to describe a desired future, backcast milestones, connect vision to customer value, and surface risks, metrics, and next actions. Do not use for formal PRDs; use to-prd.

Use loss-aversion analysis when perceived losses outweigh equivalent gains. Use for pricing, trials, cancellations, migration risk, retention, warnings, plan limits, or messaging about what users may lose; avoid fake fear tactics and prefer status-quo-bias skill for resistance to change itself.

Make structured product decisions with explicit goals, options, tradeoffs, evidence, and decision records. Use when stakeholders disagree, multiple valid paths exist, scope is contested, or choices need rationale; avoid for requirements cleanup, roadmap hierarchy, or effort sizing alone.

Name code identifiers clearly and consistently. Use when naming or reviewing variables, functions, booleans, classes, files, modules, React hooks, event handlers, props callbacks, error values, and domain concepts; reducing ambiguity, duplicated context, contractions, or misleading singular/plural names. For larger code-quality review use code-reviewer.

Implement Next.js image art direction with getImageProps(), picture, source, and img. Use when mobile, tablet, or desktop need different image assets, crops, focal points, compositions, or carousel media while keeping Next.js image optimization. Do not use for simple responsive sizing of the same image; use normal next/image sizes for that.

List completed OpenCode skill calls ranked by usage count. Use when users ask for most-used skills, skill usage counts, skill statistics, or a ranked skill usage table.

Plan and run dynamic worker decomposition with a central orchestrator, narrow worker jobs, output schemas, replanning rounds, and synthesized results. Use when task shape is unknown upfront and subtasks must be assigned at runtime. Do not use for fixed sequences; use prompt-chaining. Do not use for independent known branches; use parallelization.

Organize information into Projects, Areas, Resources, and Archives. Use when setting up notes, files, knowledge bases, personal systems, or migrations from messy folders; avoid for product backlog hierarchy, workflow Kanban, or strategic portfolio planning.

Split independent LLM work into concurrent branches, then merge, vote, rank, or compare outputs with a simple schema. Use when subtasks are isolated by item, source, section, test, or judge and latency or judgment quality matters. Do not use when one branch depends on another; use prompt-chaining.

Analyze macro-environment forces with PEST political, economic, social, and technological factors. Use when assessing markets, expansion, regulation, industry change, strategic risks, or external business context; avoid for internal business-model design or user motivation research.

Write, review, or fix Playwright accessibility tests with @axe-core/playwright. Use for axe scans, WCAG A/AA tags, ARIA names, roles, labels, keyboard/focus checks, accessibility audit failures, exclusions, and critical page or flow a11y coverage. For general Playwright locator, assertion, fixture, or flake guidance use playwright-best-practices.

Write, review, or fix resilient Playwright tests around user-visible behavior. Use for locators, web-first assertions, auto-waiting, fixtures, isolation, test data, mocks, projects, trace debugging, and flaky browser tests. For axe, WCAG, ARIA, keyboard, or accessibility-specific scans use playwright-accessibility-testing.

Deliver a PRD through orchestrated task decomposition, implementation agents, and independent QA. Use when every acceptance criterion must be verified before completion.

Drive PRD implementation through a durable /goal, scoped parallel implementation agents, independent QA ownership, acceptance evidence, and persona-based test instructions. Use when a PRD must be delivered end-to-end and every acceptance criterion must be verified before marking the goal complete.

Estimate line additions and deletions from a PRD or spec by reading the requirements and inspecting the target repo. Use when the user asks for changed LOC, additions, deletions, diff size, PR size, or implementation size before building.

Reveal complexity in stages so users see what they need when they need it. Use for onboarding, forms, settings, advanced options, dashboards, or dense interfaces; avoid when problem is simply too many choices, weak copy clarity, or overall task complexity.

Organize React, Next.js, or TypeScript projects with feature-based architecture. Use when starting or reorganizing an app, deciding where files belong, separating app/features/shared layers, preventing cross-feature imports, designing module boundaries, or applying Bulletproof React-style structure. For high-level architecture tradeoffs use architecture-review; for single-component splitting use decompose.

Break known LLM work into fixed sequential steps with handoff schemas, validation checks, retries, and final formatting. Use when later steps depend on earlier outputs or staged review reduces errors. Do not use for independent branches; use parallelization. Do not use when tasks must be discovered at runtime; use orchestrator-workers.

Simplify prompts, system instructions, workflows, rules, and agent playbooks while preserving behavior. Use when logic has too many branches, nested conditions, contradictions, repeated rules, vague failure paths, or inconsistent outputs. Do not rewrite product requirements; use to-prd for PRD conversion.

Build or refactor React forms with React Hook Form. Use when working with useForm, register, handleSubmit, formState errors, defaultValues, validation rules, Controller, useController, FormProvider, useFieldArray, Zod or other resolvers, server submissions, and TypeScript form values. For simple local input state without React Hook Form use react-use-state.

Choose correct React key props for lists and remounts. Use when mapping arrays, rendering dynamic lists, sorting/filtering/reordering items, debugging list state bugs, avoiding index keys, or intentionally resetting component state with a key. For general local state updates use react-use-state; for effect-based resets use react-useeffect-avoid.

Handle expected Next.js Server Action errors with TanStack React Query mutations. Use when server actions, mutationFn, useMutation, onError toasts, throwOnError, QueryBoundary, ActionResult discriminated unions, translated error codes, or production-safe client error messages are involved. Do not use for generic React Query data fetching or unrelated form validation.

Decide when to use React useCallback. Use when callback identity affects memoized children, dependency arrays, custom hooks, event handlers passed through props, or unnecessary re-renders. Avoid defaulting to useCallback for every function. For state update correctness use react-use-state; for effect dependency alternatives use react-useeffect-avoid.

Place React and Next.js "use client" boundaries correctly. Use when adding client components, hooks, event handlers, browser APIs, client-only libraries, or fixing Server Component errors about hooks, async clients, or event handlers. Keep data fetching on server when possible and remove redundant directives. For generic React state or effects use their dedicated skills.

Use React useState for simple local component state. Use when adding UI state, inputs, counters, selected IDs, active tabs, local arrays or objects, updater functions, initializer functions, or debugging stale reads and mutation bugs. Prefer derived values, useRef, useReducer, context, or server-state libraries when state should not live in useState.

Avoid unnecessary React useEffect and choose better alternatives. Use when reviewing effects, derived state, prop-to-state copies, event handling, form resets, extra renders, stale synchronization, or async/server data patterns. Keep useEffect for external systems like subscriptions, timers, browser APIs, third-party widgets, analytics, or document title. For callback identity use react-use-callback.

Plan and apply behavior-preserving code refactors. Use when restructuring target files, reducing complexity, improving maintainability, applying framework or language best practices, improving type models, or reorganizing code while preserving public behavior and contracts. For quick cleanup of recent edits use code-simplifier; for review-only architecture candidates use architecture-review.

Analyze feature requirements for clarity, scope, risk, assumptions, and testability before implementation. Use when specs are vague, acceptance criteria are missing, edge cases are unclear, or work needs splitting; avoid for writing full user stories or estimating effort only.

Classify inputs into specialized prompts, tools, models, agents, or workflows using route labels, confidence, fallback, and misroute review. Use when clear request categories need different handling for cost, latency, safety, quality, or domain. Do not use for sequential steps; use prompt-chaining. Do not use for dynamic decomposition; use orchestrator-workers.

Build internal triggers that make users return from their own needs, emotions, or routines. Use when reducing notification dependence, strengthening retention, mapping return moments, or moving from external prompts to self-initiated use; avoid for full habit-loop design or one-time CTA conversion.

Use credible evidence from relevant others to reduce uncertainty. Use when selecting testimonials, reviews, customer logos, usage stats, expert endorsements, or peer proof near decisions; avoid generic trust work, fake popularity, or halo effects from brand polish alone.

Design for user resistance to change and preference for the current state. Use when planning migrations, defaults, switching paths, feature adoption, workflow replacement, or rollout risk; distinguish from loss aversion by focusing on change friction, reversibility, and transition design.

Write a concise PR description from branch commit messages, using `fixes` for fix commits and `implements` otherwise. Use when user needs pull request text, branch summary, or review-ready description from git history. Do not draft commit messages; use conventional-commit.

Configure Tailwind CSS v4 with the CSS-first setup. Use when installing Tailwind v4, migrating from v3, setting up Vite, PostCSS, CLI, or framework integration, defining @theme tokens, using @source, configuring plugins, debugging content detection, or checking browser support. For component-level utilities, variants, CVA, or tailwind-variants use code-architecture-tailwind-v4-best-practices.

Structure product work from strategic themes to epics, stories, and tasks. Use when organizing backlogs, roadmaps, releases, stakeholder communication, or large initiatives into outcome-linked delivery units; avoid for writing one story only, requirements analysis, or effort estimates.

Convert conversation notes, raw ideas, feature requests, or planning discussion into concise PRD requirements with goals, users, problem, requirements, non-goals, constraints, acceptance criteria, and open questions. Use when user asks for PRD, spec, requirements doc, or product brief. Do not interview first unless key decisions are missing; use discuss-task for clarification.

Add trust signals that reduce perceived risk before important user actions. Use for signup, checkout, onboarding, landing pages, pricing, guarantees, security, support, and cancellation reassurance; distinguish from social proof, halo effect, and cognitive fluency by focusing on risk.

Design readable advanced TypeScript types. Use when creating reusable type utilities, generics, conditional types, mapped types, template literal types, infer helpers, branded types, type guards, assertion functions, typed libraries, API clients, configs, or state helpers. Prefer simple types until complexity pays off. For broad code-quality typing guidance use typescript-best-practices.

Improve TypeScript safety, readability, and maintainability. Use when reviewing TypeScript code, choosing typing strategy, configuring strictness, handling async errors, replacing any with unknown, narrowing external data, modeling state with unions, placing runtime validation, or organizing types. For complex reusable type utilities use typescript-advanced-types; for interface vs type decisions use typescript-interface-vs-type.

Choose TypeScript interface vs type aliases. Use when defining object shapes, class contracts, unions, tuples, function aliases, mapped or conditional types, extension patterns, intersections, declaration merging, or reviewing type style. Prefer interface for object shapes and extends; prefer type for unions and advanced aliases. For broad typing strategy use typescript-best-practices.

Choose TypeScript satisfies, type annotations, as const, or assertions. Use when validating config objects, route maps, locale maps, feature flags, status labels, design tokens, or handler maps while preserving literal types; fixing widened types; or requiring exhaustive Record keys. For general interface/type choice use typescript-interface-vs-type; for broader typing strategy use typescript-best-practices.

Write clear user stories with user, capability, benefit, and testable acceptance criteria. Use when creating or improving backlog items, Given/When/Then criteria, INVEST checks, and user-centered requirements; avoid for roadmap hierarchy, broad requirement audits, or effort sizing.

Check whether users can discover, understand, believe, and experience product value. Use when evaluating concepts, activation, onboarding, adoption, messaging, time-to-value, or unclear product direction; avoid for business-model economics, JTBD motivation research, or CTA-level optimization.

Guide attention toward the next valuable action with CTA hierarchy, visual cues, and gaze patterns. Use when improving button placement, copy, contrast, page scanning, attention flow, or conversion areas; avoid for broad trust, proof selection, or behavior-change diagnosis.

Identify product-management anti-patterns and replace them with better practices. Use when reviewing PM behavior, stakeholder chaos, vague requirements, output-focused roadmaps, weak discovery, team dysfunction, or PM onboarding; avoid personal critique without concrete behavior and impact.