expo-design-system-scaffolder
Scaffolds Expo / React Native design system components that obey the expo-design-system rules by construction — a variant-driven pressable primitive, a slot-based card surface, a typed text primitive, a labeled form field, a FlashList entity screen, a theme token group, and a Storybook variant catalog. Generated code uses Unistyles v3 variants instead of style props, ref-as-prop, design tokens, built-in accessibility, and web/iOS parity (`_web` hover/focus/cursor on interactive primitives), so it follows expo-design-system without rework. Output is TSX/TS using react-native-unistyles. Trigger whenever the user wants to create, add, generate, or scaffold a new shared UI component, primitive, design token group, or screen for the clinic mobile app — even if they don't mention the design system.
expo-ios-hig
Expo / React Native iOS interface conforming to Apple Human Interface Guidelines (iOS 26) — native navigation (Expo Router native stack and tabs), platform controls (Alert, ActionSheetIOS, SF Symbols via expo-symbols), safe areas, dark mode, Dynamic Type, haptics, Liquid Glass, accessibility, and 60fps motion. Covers architecture and styling decisions made in React Native/TypeScript; for the @expo/ui SwiftUI component API use the expo-ui skill, and for native Swift use ios-hig. Trigger when building, reviewing, or refactoring such an app — even when the user does not say "HIG" or "native feel" but is writing TSX screens, navigation, lists, forms, or styling for iOS in Expo.
expo-ios-hig-verify
Static scan of an Expo / React Native iOS app for non-native patterns — Material component kits, JS navigators instead of native stack/tabs, PanResponder, disabled font scaling, hardcoded hex colors, unvirtualized lists — reports each violation with file:line and a link to the rule. Trigger when the user asks to check, lint, audit, or review an Expo iOS app for HIG compliance or "native feel," or before shipping/merging Expo iOS UI. Pairs with the expo-ios-hig rules skill (it checks what that skill teaches) and the expo-ios-screen-scaffolder.
expo-ios-screen-scaffolder
Scaffolds Expo (React Native) iOS screens that follow Apple Human Interface Guidelines by construction — list, detail, form, modal sheet, native tabs layout, and settings screens, each wired with native navigation, FlashList, safe-area insets, semantic colors, SF Symbols, haptics, and empty/loading states. Generated code follows the expo-ios-hig rules so it passes expo-ios-hig-verify without rework. Each screen is TSX for Expo Router, not Swift. Trigger whenever the user wants to create, add, generate, or scaffold a new Expo screen, route, tab layout, or form for iOS — even if they don't mention HIG.
expo-ui
Library reference for @expo/ui SwiftUI components on iOS — covers Host boundaries, modifier composition, iOS 26 Liquid Glass and Human Interface Guidelines composition rules, layout/input/navigation/display catalogues, and ObservableState patterns. Use this skill whenever writing or reviewing React Native code that imports from @expo/ui/swift-ui or @expo/ui/swift-ui/modifiers — including new Expo apps adopting native SwiftUI views, migrations from React Native primitives to expo-ui, and code targeting iOS 26 features (Liquid Glass, GlassEffectContainer, sheet detents). Trigger even if the user does not explicitly mention "expo-ui" but is writing iOS-targeted Expo UI code that should bridge to SwiftUI.
feature-arch-gate
Adversarial pass/fail review gate that enforces the feature-arch skill's React feature-based architecture rules. Use when a diff, branch, PR, or src/ tree must be judged for architecture conformance before merge — feature folder structure, import boundaries, cross-feature isolation, data-fetching, state, testing, and naming rules. A single blind reviewer renders per-rule PASS/FAIL verdicts with cited evidence, and the reviewer's structured output is the verdict fail-closed. Use the feature-arch skill itself to design or migrate an architecture; use this gate to judge whether work conforms to it.
fog-of-war-js-ts
Fog of war, field of view, line of sight, and tile visibility in JavaScript or TypeScript games — roguelikes, RTS, top-down, or strategy maps. Covers efficient FOV algorithms (recursive and symmetric shadowcasting, DDA raycasting, 2D visibility polygons), update scheduling and multi-viewer reference counting, typed-array and bitset state, canvas and WebGL fog rendering, memory and large-map scaling, hot-loop geometry math, and visibility correctness. Trigger when implementing, reviewing, or optimizing such code — even when the user only says "fog of war", "reveal the map", "what can this unit see", "shadowcasting", or "visibility grid" without mentioning performance — the naive raycast-per-cell-every-frame approach is usually what needs replacing. Prefer these patterns when writing new visibility code or refactoring slow or buggy fog.
geohash-spatial-code-maps
Geohash encoding/decoding in TypeScript or Rust — bit interleaving, the base32 alphabet, precision and cell geometry, neighbour/adjacency computation, proximity and bounding-box queries, and geohash-backed spatial indexing. Also covers the "codebase as a navigable 2D map" pattern — projecting a codebase into a coordinate plane, geohashing it so prefixes become business-domain regions, and navigating it like Google Maps (zoom, tiles, level-of-detail, clustering, deep links). Trigger when implementing, reviewing, or debugging geohash work — even when the user does not say "geohash" but the work involves spatial hashing, Morton/Z-order codes, proximity search on lat/lon, or mapping and visualising code structure spatially. Contains 42 impact-ordered rules with TypeScript and Rust examples.
go-process-cli
Write Go CLIs that manage processes and workloads — daemons, supervisors, job runners, deploy tools, anything that spawns or controls other processes. Use when writing, reviewing, or refactoring Go that handles OS signals, runs children via os/exec, fans out concurrent work, threads context for cancellation, returns exit codes, or builds a flag/cobra command surface. Covers the footguns the standard library makes easy to hit — SIGTERM vs Ctrl-C, SIGKILL-by-default children, orphaned process groups, pipe deadlocks, goroutine leaks, zombie reaping, and os.FindProcess lying about liveness. Triggers whenever the task touches process lifecycle, graceful shutdown, subprocess control, or concurrent workload supervision in Go — even if not named.
human-copywrite
User-facing copy — UI strings, documentation, marketing, release notes, error messages, onboarding flows, blog posts, or anything that a person will read. Distilled from the Apple Style Guide (June 2025): voice and tone (active voice, present tense, second person, no jargon), punctuation, capitalization, hyphenation rules for compound modifiers, when to spell out numbers, units of measure, UI vocabulary (button vs control vs sheet vs popover), Apple product and feature naming, technical notation for developer docs, and international style for localization. Trigger when writing, editing, or reviewing copy — even if the user doesn't explicitly mention \"style guide\" or \"copywriting,\" any time the deliverable is human-readable text the rules here apply. Especially valuable when the user is writing instructions, naming UI elements, or deciding how to format a number, date, or unit.
implementation-design-patterns
Implementation guide for the 22 Gang of Four design patterns in TypeScript, distilled from refactoring.guru. Use this skill when writing, refactoring, or reviewing TypeScript that exhibits a pattern-shaped problem — class-explosion from inheritance, conditionals switching on type, tight coupling to concrete classes, tree-shaped models, runtime algorithm selection, undo/redo, snapshot-and-restore, state-dependent behavior, subscriber notification, or hiding subsystem complexity. Each pattern entry includes intent, problem, solution, applicability (when to use AND when NOT to use), a runnable TypeScript example, implementation steps, pros/cons, and relations to sibling patterns. Trigger even when no pattern is named — cues like "class getting unwieldy," "giant switch," "swap implementations at runtime," "combinatorial subclasses," "need undo," or "traverse a tree" are pattern-shaped. Covers all 5 Creational, 7 Structural, and 10 Behavioral GoF patterns.
implementation-design-patterns-python
Implementation guide for the 22 Gang of Four design patterns in idiomatic modern Python (3.10+), distilled from refactoring.guru. Use when writing, refactoring, or reviewing Python with a pattern-shaped problem — class-explosion from inheritance, conditionals switching on type, tight coupling to concrete classes, tree-shaped models, runtime algorithm selection, undo/redo, state-dependent behavior, or hiding subsystem complexity. Each entry leads with the Pythonic form (functions, dataclasses, Protocol, singledispatch, match, generators, copy/replace) and falls back to the class-based GoF structure only when identity, state, or dispatch require it. Includes intent, applicability (when to use AND when NOT to), a runnable example, steps, pros/cons, and relations. Trigger even when no pattern is named — cues like "too many constructor params," "giant if/elif," "swap behavior at runtime," "need undo," or "walk a tree" are pattern-shaped. Covers all 5 Creational, 7 Structural, and 10 Behavioral GoF patterns.
implementation-functional-patterns
TypeScript's functional answers to the 22 Gang of Four classes — factory functions (Factory Method, Abstract Factory, Prototype, Memento), module-scope singletons, fluent immutable builders, wrapper functions (Adapter, Facade), native Proxy, WeakMap caches (Flyweight), discriminated unions with exhaustive match (State, Visitor, Composite), event emitters and signals (Mediator, Observer), pipelines and composition (CoR, Decorator), stream methods (Iterator), closures-as-commands, higher-order strategies, lambda placement. Use when reviewing TypeScript that has a class-shaped problem the GoF catalog solves with a hierarchy but where idiomatic TS reaches for a function, a tagged union, or a data structure. Each rule names the GoF pattern(s) it replaces and when the class form still wins. Trigger on "factory class", "singleton getInstance", "state machine class", "observer pattern", "AST visitor", "where do I put this lambda". Sibling to implementation-design-patterns.
inngest-nextjs-patterns
Inngest event-driven functions in a Next.js (App Router) project — creating the client, the /api/inngest route handler, typed events with Zod schemas, durable event-triggered functions, scheduled cron functions, or fan-out orchestrators. Trigger when scaffolding Inngest patterns — and even if the user just says "add a background job", "process this async", "schedule X every hour", or "send an event when Y happens" in a Next.js codebase. Also trigger when reviewing existing Inngest code to enforce event-naming, function-id stability, and step-idempotency conventions.
io-bound-data-processing
Processing, transforming, or moving datasets that may exceed RAM on a single low-compute box — covers memory discipline (streaming, generators, dtype shrinkage), I/O access patterns (sequential vs random, mmap, async), data formats (Parquet vs CSV vs JSON, predicate pushdown), chunking & batching, spill-to-disk (external merge sort, DuckDB/Polars), pipelining (bounded queues, backpressure, checkpointing), codec selection (zstd/lz4/gzip), concurrency for I/O-bound workloads (asyncio, threads, prefetch), and observability (iowait vs CPU%, rows/sec, py-spy/strace). Trigger on "process a large file", "stream this", "out-of-core", "OOM kill", "this is slow", or code with `pd.read_csv` of multi-GB files, `requests.get(...).content` on big bodies, `BytesIO` on unbounded inputs, per-row INSERTs, sequential `requests.get` loops, falling `tqdm` rates — even if I/O or memory isn't mentioned. Complement to computer-science-algorithms.
language-spec-author
Turn a rough idea for a language into a complete, implementable specification — a DSL, query, config/data, template, or protocol language — by interviewing the author dimension by dimension until another developer could build a conforming implementation from the document alone. It grills for the decisions authors skip: lexical rules (whitespace, case, comments, literals), grammar with precedence and ambiguity resolution, a semantic/type model, validation rules with counter-examples, execution algorithms and the error model, the output/serialization format, and RFC 2119 conformance. The completeness bar and formal notation (lexical vs syntactic grammar, function-style algorithms) are distilled from the GraphQL specification. Trigger on \"spec out my language\", \"design a DSL / query language\", \"write a language or grammar spec\", \"formalize this syntax\", or when someone has a language idea that needs to become an implementable spec — even if they only say \"spec\" or \"grammar\".
library-reference-distillation
Methodology for starting a new library-reference distillation skill — one that turns an external library (nuqs, zod, framer-motion, msw, react-hook-form, emilkowal-animations) into an idiomatic-usage rule pack — or evolving one against a new upstream release. Distills the conventions empirically shared across shipped library-ref skills in this repo — the source-priority ladder (docs → blog/changelog → issues → types → examples), version pinning that inverts with API velocity, the universal 4-tier category ladder (CRITICAL setup → HIGH isolation → MEDIUM composition → LOW edge cases), the 4-slot When-to-Apply template, the failure-gap exemplar heuristic (privilege production lessons over API restatement), and metadata.references[] as cite-set checksum. Triggers on "I want to write a skill for library X", "refresh against new upstream", "where should I source rules from", "what categories should this skill have", and on /dev-skill:new for a library-reference distillation.
linguistic-semantic-algorithms
Mapping out an unfamiliar codebase via NLP and graph algorithms — 40 algorithms across topic modelling, semantic embeddings, code graphs, repository mining, clone detection, IR-based bug localization, identifier linguistics, and complexity metrics. Trigger when hunting bugs across many files, scoping a new feature, identifying domain entities, or analyzing commit history — even if the user doesn't explicitly mention algorithms — apply when they ask "where does X live in this codebase?", "what is this codebase about?", "find duplicated logic", "what changed recently?", "who owns this code?", or "is this function risky?".
marketplace-personalisation
Personalisation and recommendation systems for a two-sided trust marketplace built on AWS Personalize — event tracking, dataset and schema design, two-sided matching, cold start, feedback loops, bias control, recipe selection, serving-time re-ranking, observability, and a diagnostic playbook for existing systems. Trigger when designing, building, debugging, reviewing, or improving such a system — and even when the user does not explicitly mention "AWS Personalize" but is working on recommendations, ranking, search, homepage personalisation, or anything that matches seekers and providers across a trust-based catalog.
marketplace-pre-member-personalisation
Pre-member journey of a two-sided trust marketplace — from anonymous landing through onboarding, registration, and the paid-membership paywall. Covers anonymous signal inference, what pet owners specifically need to validate before paying (safety, availability, competence, effort, local cost comparison), what pet sitters specifically need to validate (opportunity, first-stay path, daily commitment, hidden costs), information-asymmetry closure, progressive profile building, social proof, conversion psychology, onboarding intent capture, identity stitching, and pre-member measurement. Triggers on tasks involving visitor-to-member conversion, anonymous personalisation, onboarding flow design, paywall timing, pre-member ranking, or any question about what a pet owner or pet sitter needs to see before paying. Use this skill BEFORE marketplace-personalisation and marketplace-search-recsys-planning.
marketplace-recsys-feature-engineering
Feature engineering for marketplace recommenders — what to extract from raw marketplace assets (listing photos, owner-entered listing metadata, sitter wizard responses) to power item-to-item (similar listings), user-to-item (homefeed ranking), or user-to-user (mutual-fit matching) recommenders. Covers asset auditing, first-principles feature decomposition, vision-feature extraction (CLIP, room-type, amenities, aesthetics), listing text and metadata encoding, sitter wizard design, derived-composition patterns for i2i / u2i / u2u (ANN shelves, two-tower, mutual-fit), feature quality governance (training-serving parity, drift, PII), and incremental value proof (ablation A/B, kill reviews, feature-free baseline). Trigger even when the user does not explicitly say "feature engineering" but is asking how to get more signal out of listing photos, listing metadata, or the sitter onboarding wizard, or how to improve i2i / u2i / u2u quality without blindly ingesting a new model.
marketplace-search-recsys-planning
Search and recommendation system planning for a two-sided trust marketplace built on OpenSearch — user-intent framing, product-surface architecture, index design, query understanding, retrieval strategy, ranking, search-plus-recs blending, measurement, and a dashboard-and-alerting layer for ongoing decision making. Triggers on tasks involving marketplace search, homefeeds, ranking, relevance tuning, OpenSearch query DSL, analyzers, synonyms, golden sets, NDCG, A/B testing, or diagnosing an existing retrieval system. Use this skill BEFORE marketplace-personalisation when planning new work; hand off when the diagnosed bottleneck is personalisation-specific.
metric-validation-harness
Empirically validates a software metric before trusting or optimizing it — point it at any candidate metric (a command that takes a path and prints one number) plus a corpus, and it runs experiments that try to falsify each property a good metric must have. Checks determinism (same input, same number across runs and hash seeds), invariance to cosmetic edits (also an anti-gaming probe), monotonicity under construct-increasing edits, discrimination, robustness on edge inputs, near-linear tractability, and construct validity (convergent, discriminant vs LOC, predictive AUC, lift over a baseline). Trigger whenever someone proposes, reviews, tunes, or ships a metric, score, or index, asks "is this metric any good", suspects a score tracks LOC or jumps between runs, or builds a deterministic optimization target. It is the empirical companion to the deterministic-metric-design skill and is read-only.
migrate-js-to-modern-typescript
Migrating a JavaScript codebase to TypeScript — converting .js files to .ts, adding types to existing JS, or tightening a loosely-typed TS project toward strict mode. Covers tsconfig and allowJs strategy, incremental strict-flag ratcheting (noImplicitAny, strictNullChecks, noUncheckedIndexedAccess), typing public surfaces, replacing `any` and unsafe casts with `unknown` and narrowing, validating runtime boundaries (JSON, env, API responses), converting CommonJS to ESM and prototypes to classes, and the build/CI changes a migration needs. Trigger even when the user only says "add types", "turn on strict mode", or "convert this file to TypeScript", and especially on a mixed JS/TS repo. Distinct from general TypeScript refactoring — this is the migration act itself, performed file by file while keeping the build green.
mlflow-3
MLflow 3 (open-source, pinned to 3.15) for classic-ML MLOps — logging and registering models, promoting versions across dev/staging/prod, standing up a tracking server, evaluating with gates, and serving. Corrects the MLflow 2-era defaults a model reaches for (artifact_path, registry stages and get_latest_versions, top-level mlflow.evaluate with baseline_model, runs-URI registration, pickle serialization, mlruns file stores, MLServer serving) with the MLflow 3 idioms that replaced them (named LoggedModels, aliases and copy_model_version, models.evaluate plus validate_evaluation_results, skops/torch.export defaults, database backends, the FastAPI scoring server). Use when writing, reviewing, or migrating Python code that touches MLflow tracking, the model registry, evaluation, or serving.
mlflow-mlops-migration
Guided workflow for taking any ML codebase — including one with no experiment tracking at all, or one full of MLflow 2-era idioms — to a production-grade open-source MLflow 3 setup with dev/staging/prod environments, registry-based promotion, and served models. Walks seven phases with a developer who may have zero MLflow 3 experience — assess the codebase (scripted read-only audit), model the registry domain (per-environment model names, aliases, gates), stand up tracking per environment, restructure training code to MLflow 3 idioms, wire evaluation-gated promotion, serve and smoke-test, then run the ongoing MLOps loop. Use when asked to set up MLflow, migrate to MLflow 3, productionize model training and serving, or design a dev/staging/prod MLOps cycle. Pairs with the sibling mlflow-3 rule pack for every API decision.
nextjs-bundle-optimizer
Next.js 16 bundle-size and build-time optimization — runs a data-driven iteration loop: measure baseline → analyze top offenders → apply ONE recipe → re-measure → verify nothing broke (build + types + tests + no regression) → commit or revert. Built for Next.js 16 with Turbopack default, and falls back to webpack-mode tooling when the project hasn't migrated yet. Triggers on phrases like \"First Load JS is huge\", \"bundle size\", \"build takes too long\", \"page is slow to TTI\", \"reduce bundle\", \"tree-shake\", or when the user shares output from `next experimental-analyze` / `@next/bundle-analyzer` — even if the user doesn't say \"optimize\" explicitly.
nextjs-ppr-patterns
Next.js 16 App Router pages mixing static and dynamic content — Partial Prerendering (PPR) under the Cache Components model. Covers enabling it with cacheComponents (the removed experimental.ppr / experimental_ppr flags), the dynamic-by-default rendering inversion, the Suspense static-shell/dynamic-hole boundary, the 'use cache' directive (automatic keys, cacheLife/cacheTag, children/action pass-through, runtime values as props, serverless durability), async runtime APIs and connection() for non-determinism, page composition from a single hole to parallel dashboards to streaming a Promise into a Client Component with use(), and forms/wizards with updateTag read-your-writes and Activity state preservation. Triggers on PPR, cacheComponents, 'use cache', Suspense streaming, partial prerendering, or static-shell work even when not named explicitly.
nuqs-codemod-runner
Migrates a nuqs codebase off pre-v2.5 patterns — deprecated `throttleMs`, hand-rolled setTimeout/useState debounce around `useQueryState`, unchecked `parseAsJson` casts, unversioned `nuqs/adapters/react-router` imports, or `ParserBuilder<T>` type references. Scans the repo, produces a dry-run report, asks for confirmation, applies AST codemods, then runs `tsc --noEmit` + the user's lint as a gate. Trigger even if the user only mentions "upgrade nuqs" or "migrate to nuqs v2.5+" without naming the specific patterns — they almost always exist in pre-v2.5 codebases.
nuqs-scaffolder
Scaffolds URL-state filters for a Next.js page — typed `searchParams.ts` parser map and a `<Filters />` client component backed by `useQueryStates`. From a single JSON spec, generates four files in lockstep — client parser map, server loader/cache/serializer, client component, and Vitest test — all sharing the same parser definitions per the nuqs Standard Schema pattern. Trigger even when the user only says "add filters to /search" or "I need a typed query string for this page" — both are exactly this skill's job.
openai-codex-rust-patterns
OpenAI Codex Rust coding patterns distilled from the codex-rs workspace. Use this skill whenever writing, reviewing, or refactoring Rust code — especially for async agents, CLI tools, sandboxing, secret handling, Ratatui TUIs, JSON-RPC protocols, tokio-based services, or any codebase that needs defensive panic discipline. Trigger even when the user does not explicitly mention Codex, because the patterns generalize to any production Rust workspace. Covers async cancellation, error enum design, process sandboxing, DNS-rebinding defense, credential hardening (zeroize/mlock/ctor), Cargo workspace architecture, wiremock-based fakes, insta snapshot testing, OpenTelemetry tracing, and Ratatui rendering.
opencode-ts
Write and refactor TypeScript code in repos that use Effect-TS services, Effect Schema, event-sourced persistence, and barrel-module architecture. Use this skill when implementing features, fixing bugs, writing tests, or refactoring in opencode or any TypeScript codebase built on the same stack (Effect DI via Context.Service, Drizzle ORM, Hono routes, Bun runtime). Triggers on tasks involving Effect services, Context.Service / Layer modules, Effect Schema definitions, SyncEvent patterns, tool implementations, test writing, or code review in Effect-based TypeScript projects.
opensearch-function-scoring-algorithms
Search relevance and ranking on OpenSearch/Elasticsearch for a two-sided marketplace — candidate retrieval (hybrid BM25 + kNN, RRF, two-tower EBR), base relevance (BM25F, multi_match, LambdaMART), quality signals (Wilson lower bound, Bayesian average, rank_feature saturation/sigmoid), personalization (listing/user/session embeddings), spatial/temporal decay (gauss/exp), marketplace balance (conversion-weighted ranking, supply fairness, Pareto multi-objective), bias correction (IPS, click models, Thompson sampling), empirical evaluation (judgment sets, NDCG, ablation, A/B sizing, CUPED, regression suites), and diversity (MMR, DPP, max-per-host). Triggers on function_score, rank_feature, script_score, kNN, hybrid query, learning-to-rank, two-sided ranking, exposure fairness, NDCG, A/B testing, judgment set construction, ranking ablation, or "why is my OpenSearch ranking bad". Applies to Elasticsearch too — same APIs.
opensearch-personalize-caching-strategies
Caching strategies in front of AWS OpenSearch (Elasticsearch) or AWS Personalize — search, recommenders, multi-recommender pages, anon vs logged-in traffic. Covers ROI decision (TPS/minProvisionedTPS, Zipf, amplification), key design (canonicalisation, cohort vs user, solution-version pinning, bucketing), personalisation boundary (anon/logged split, fan-out coalescing), strategies (cache-aside, refresh-ahead, write-through, batch precompute, L1+L2), TTL (volatility, soft/hard, jitter, event-driven invalidation), stampede protection (single-flight, XFetch, stale-while-revalidate, circuit breaker), observability (hit-rate, cost-per-1k, cardinality drift, log-replay), defensive caching (negative, Bloom filter), and tier composition (LRU, ElastiCache Redis, CloudFront, OpenSearch request/filter cache). Triggers on cache hit rate, Personalize throttling, stampede, single-flight, L1/L2, ElastiCache sizing. Complements opensearch-function-scoring-algorithms.
opinionated-nextjs-patterns
Opinionated, backend-agnostic Next.js 16 (App Router) architecture — authorization at the data layer, server-side loading with cache()+Promise.all, mutations through next-safe-action + typed route handlers, client/server boundaries ('use client' at leaves + TanStack Query), forms with RHF + Zod, UI via shadcn/ui + Tailwind + Base UI + next-intl, request handling in proxy.ts (Next.js 16's renamed middleware), and a Turbo monorepo of @app/* packages confining the backend behind one data-access package. Examples use Supabase but every rule states the transferable principle. Use when writing, reviewing, or refactoring Next.js 16 code. Trigger on server actions, route handlers, RSC vs 'use client' placement, TanStack Query, RHF/Zod, proxy.ts, or monorepo package layout — even when the user doesn't say 'patterns' or 'best practices'.
pt-irs-runbook
Portuguese personal income tax (IRS / Código do IRS) and Modelo 3 filing — determining tax residency (Art. 16), classifying income by category (rental/Anexo F, capital gains/Anexo G, employment/Anexo A, self-employment/Anexo B, pensions, foreign income/Anexo J), choosing the right annexes, applying current Art. 72 autonomous rates, and meeting Portal das Finanças deadlines. Covers residents and non-residents, including landlords with Portuguese-source rental income and double-taxation relief. Portugal-specific; not a substitute for a contabilista certificado.
python-pep-author
Drafting Python Enhancement Proposals (PEPs) — proposing a Python language feature, a standard library change, an interoperability standard, or an informational/process document for the Python community. Covers all three PEP types (Standards Track, Informational, Process): choosing the right type, scaffolding a valid reStructuredText pep-NNNN file, filling each required section to the acceptance bar, linting the headers, and navigating the sponsor / submission / Steering Council review process. Trigger on \"write a PEP\", \"draft a PEP\", \"propose a Python feature\", \"create a Python Enhancement Proposal\", \"PEP template\", or when someone is preparing a proposal for the Python Discourse or python-dev. Use it even if the user only says \"PEP\" or doesn't mention reStructuredText — the headers, sections, and process are exactly what trips PEP authors up.
radical-simplification
Cognitive moves for collapsing complexity — reframe, clarify, reduce, decompose, invert, constrain, transfer, generalize, audit — distilled from the working method of mathematicians, physicists, and software engineers known for turning hard problems into simple solutions (Pólya, Feynman, Hamming, Brooks, Knuth, Dijkstra, Lamport, Tao, Grothendieck, Munger, Hofstadter). Use when stuck on a complex problem, when a proposed design feels overengineered, when reviewing code that has accreted accidental complexity, or when the user wants an elegant solution to a hard engineering or product problem. Triggers on phrases like "this feels too complicated", "we are going in circles", "there must be a simpler way", "interview me about this plan", "find the underlying problem", and on stuck-state moments where forward search has run out and the agent needs a different angle.
ray
Production Ray (open-source, pinned to 2.57) for classic-ML workloads from training to serving — Ray Train, Tune, Data, Serve, Core, and cluster deployment on KubeRay. Corrects the older-corpus defaults a model reaches for (ray.air session reporting, Trainer-inside-Tuner, tune.run, map_batches concurrency=, DatasetPipeline/to_torch, max_concurrent_queries, RayServeHandle + ray.get, Deployment.deploy, ray.state, ray.get-in-a-loop) with the 2.57 idioms that replaced them (Train V2 defaults, driver-function tuning, compute strategies, streaming datasets, DeploymentHandle/DeploymentResponse, serve build/deploy, ray.util.state, KubeRay CRDs and Jobs API). Use when writing, reviewing, or productionizing Python code that touches Ray distributed training, data pipelines, hyperparameter tuning, model serving, or Ray cluster operations. LLM serving/batch-inference on Ray lives in the sibling ray-llm skill.
ray-llm
LLM workloads on open-source Ray (pinned to 2.57) — OpenAI-compatible serving with ray.serve.llm (vLLM-backed LLMConfig + build_openai_app) and batch inference with ray.data.llm (build_processor). Corrects the stale defaults a model produces — the archived ray-llm repo and its YAML configs, hand-rolled vLLM engines inside plain Serve deployments, the removed build_llm_processor name, deprecated boolean stage flags, top-level LLMServer/LLMRouter imports, free-form accelerator strings, one-deployment-per-LoRA-adapter designs — with the 2.57 idioms (stage configs, placement_group_config over hand-rolled PGs, deployment_config autoscaling, dynamic LoRA multiplexing, prefix-cache-affinity routing, the full OpenAI endpoint surface). Use when writing, reviewing, or productionizing LLM serving or batch inference on Ray. Classic-ML Ray (Train/Tune/Data/Serve/clusters) lives in the sibling ray skill.
react-19-component-scaffolder
Scaffolds React 19 / React 19.2 code in TypeScript — components, Server Component pages, client islands, form actions with useActionState, context providers, custom hooks, reducers, or document metadata + resource hints. Generates production-grade code that follows React 19 idioms (ref-as-prop, <Context value={...}>, useActionState, inline metadata, useSyncExternalStore) and refuses deprecated React 18 patterns (forwardRef, <Context.Provider>, useFormState, react-dom/test-utils). Trigger even when the user says "create a component", "new page", "add a form", "new hook", or "scaffold X" without explicitly mentioning React 19.
react-fetch-cache-patterns
React data-fetching patterns at scale — recommender carousels, infinite feeds, pages with many parallel fetches, dashboards. Covers request orchestration (parallelism, batching, deduplication), cache strategy (keys, normalization, staleTime, SWR), backend protection (concurrency caps, debounce/throttle, jittered retries, circuit breakers), prefetching (route loaders, hover/intent, idle, server hydration), failure resilience (AbortController, timeouts, error boundaries, stale fallback, idempotent mutations), and feed/carousel patterns (virtualization, cursor pagination, summary/detail split). Includes 5 ready-to-use scaffolding templates (resource query hook, carousel data loader, infinite feed, hover-prefetch link, request collapser). Trigger when building, reviewing, or refactoring React components that fetch data — even if the user doesn't explicitly mention "performance" or "scale".
react-hook-form-audit
Audits a Next.js (App Router, 14/15+) codebase for React Hook Form anti-patterns — watch() at form root, Controller inlined in parent, async submit without try/catch, missing setError on server failures, RHF in non-"use client" files, RHF mixed with useActionState, schemas defined inside components, useFieldArray without field.id keys, register({ disabled }) for visual disabling, useFieldArray({ disabled }) that silently no-ops mutations, useEffect+reset(data) instead of the values prop. Read-only; emits a markdown report with file:line citations linking back to the companion `react-hook-form` distillation skill. Trigger when the user asks to audit/review/lint RHF usage, find form anti-patterns, or run a quality check on forms — even if they don't say "react-hook-form" by name; if they mention auditing forms in a Next.js project, use this skill.
relational-database-design
Distills a logical relational-database design methodology into rules an agent applies while designing or reviewing a schema. Covers the design sequence (mission → tables → fields → keys → relationships → business rules → views → integrity review), one-subject-per-table decomposition, atomic single-valued fields, candidate/primary/foreign keys, relationship types with deletion rules and participation, the four levels of data integrity, database-vs-application business rules, validation tables, views for derived data, and the flat-file / spreadsheet / RDBMS-driven antipatterns to avoid. The structure is logical and RDBMS-agnostic, and normalized by construction. Use when designing a new relational schema, reviewing or refactoring an existing one, resolving redundant or repeating data, choosing keys, modeling relationships, or deciding where a constraint belongs.
relational-data-modeling
Corrects the wrong defaults a model has when designing a relational schema — the DDL decisions an experienced engineer makes differently. Use when creating or reviewing tables, migrations, ER models, or ORM schema definitions. Covers identity and keys (surrogate vs natural, identity vs serial, uuidv7, composite keys that make cross-tenant references impossible), relationships (polymorphic foreign keys the database cannot enforce, referential actions, unindexed FK columns, disjoint subtypes), invariants the engine can prove instead of application code (EXCLUDE, partial unique indexes, CHECK limits, deferrable cycles, NOT VALID), types (timestamptz, exact money, range types, enum vs lookup table), derived and encoded data (generated columns, JSONB as an escape hatch), and time (events vs in-place updates, soft-delete flags that silently disable constraints, temporal keys). NOT for query tuning, index selection for read paths, or connection pooling.
same-results-less-code
Same behaviour in fewer, clearer lines — covers the judgment gaps that linters cannot catch (reinvention, wrong frame, hidden duplication, derived state, procedural rebuilds, speculative generality, defensive excess, type-system underuse). Trigger when reviewing, refactoring, or simplifying code — and even when the user doesn't explicitly ask for "simplification" but is reviewing code, refactoring, or asking "is there a shorter way to write this?". Complements knip/eslint/ruff/tsc by focusing on the conceptual modelling layer those tools cannot see.
web-taste
>
vault-search
Semantic search and Dataview-style queries across the Obsidian vault. Use when searching for notes by meaning, finding related content, querying frontmatter metadata, or answering questions about vault contents. Trigger phrases include "search vault", "find notes about", "what do I have on", "related notes", "list tasks", "show positions".
character-design
>
cinematography
>
Page 467 of 1693 · 84608 results
