Skill Index

---
name: skill-index
description: Look up any skill in the marketplace by name or topic, including a disabled one, and get its exact re-enable command. Reach for this when you suspect a skill exists for the current task but it is not in your listing.
allowed-tools: Read
---

<!-- GENERATED by scripts/generate-skill-index.py — do not edit by hand.
     Run: python3 scripts/generate-skill-index.py
     The --check freshness gate fails CI on drift. -->

# Skill: skill-index

A complete, always-current index of every skill shipped by every RavenClaude plugin — including one whose plugin is currently disabled and therefore does not appear in your own skill listing this turn.

## Why this exists

A skill whose plugin is disabled is invisible to you: no error, no denial, just silence. If you suspect a skill exists for the task at hand but don't see it listed, invoke this skill and search the table below by name, plugin, or keyword before concluding no such skill exists.

## Re-enabling a disabled skill

Every entry below names its owning plugin. To bring a disabled plugin's skills back:

```
/plugin enable <plugin>@ravenclaude
/reload-plugins
```

## Index (958 skills across 184 plugins)

| Skill | Plugin | Description |
|---|---|---|
| `design-accessible-pattern` | `accessibility-engineering` | Design an accessible-by-default component pattern, semantic HTML first and ARIA only where needed. Reach for this on a design-system or component question. |
| `prioritize-remediation` | `accessibility-engineering` | Rank audit issues by user-impact and effort into a sequenced remediation plan with owners. Reach for this when there are more fixes than time. |
| `run-wcag-audit` | `accessibility-engineering` | Audit a page set against a named WCAG version and level, classify issues by severity/level, and compute a weighted conformance score. Reach for this on a conformance question. |
| `test-assistive-tech` | `accessibility-engineering` | Verify keyboard operability and screen-reader parity hands-on with the assistive technology real users use. Reach for this on a parity question. |
| `verify-contrast` | `accessibility-engineering` | Compute the WCAG contrast ratio from hex foreground/background values and check AA/AAA for normal and large text. Reach for this on any color question. |
| `audit-controls` | `accounting-bookkeeping` | Audit segregation of duties and chart-of-accounts hygiene before trusting the books. Reach for this on a controls or data-quality question. |
| `estimate-bad-debt` | `accounting-bookkeeping` | Estimate bad-debt from AR aging buckets weighted by loss rate. Reach for this on a receivables-risk question. |
| `read-working-capital` | `accounting-bookkeeping` | Read the cash conversion cycle (DSO + DIO − DPO) and locate trapped or surrendered cash. Reach for this on a cash question. |
| `reconcile-accounts` | `accounting-bookkeeping` | Reconcile bank and balance-sheet accounts to source before any statement ships. Reach for this first on any reporting question. |
| `run-close` | `accounting-bookkeeping` | Run the period-end close on a cadence: critical-path checklist, days-to-close, bottleneck. Reach for this on a close question. |
| `design-agent-tools-and-context` | `ai-agent-engineering` | Design the tools/functions an agent calls and the context/memory strategy that keeps it coherent — unambiguous tool names, typed parameters, examples-in-description, errors that teach recovery, a small-enough tool count, plus a context plan (what stays in-window, what gets summarized, what moves to external memory) and short-term-vs-long-term memory design under a per-turn token budget. Reach for this when the user says 'the agent keeps calling tools wrong', 'the context overflows', or 'the agent loses track on long runs'. Used by `agent-implementation-engineer` (primary). |
| `evaluate-and-harden-agent` | `ai-agent-engineering` | Evaluate an agent and harden its failure modes before it touches real traffic — an offline eval harness scored on task-completion, trajectory, and tool-use correctness against a fixed task set, plus loop hardening (step/tool-call caps, timeouts + retries, stop conditions, human-in-the-loop on irreversible actions) and tracing so every step/tool-call/token-cost is observable, with cost and latency reported alongside quality. Reach for this when the user asks 'how do I know this agent works?', 'set up agent evals', or 'the agent loops / does something dangerous'. Used by `agent-implementation-engineer` (primary). |
| `triage-agentic-approach` | `ai-agent-engineering` | Decide whether a task should be an agent at all — and if so, single-agent vs multi-agent, the orchestration topology, and the framework — by traversing the agentic decision tree (agent-vs-workflow gate → single-vs-multi → topology → framework), returning a go/no-go verdict that defaults to 'a fixed workflow or a single LLM call wins' unless the control flow is genuinely unknowable in advance. Reach for this when the user asks 'should we build an agent for this?', 'do we need multiple agents?', 'LangGraph or CrewAI or the OpenAI/Claude Agents SDK?', or 'is this an agent or just a workflow?'. Used by `agentic-systems-architect` (primary). |
| `codex-reasoning-level-calibration` | `ai-coding-model-guidance` | Calibrate the OpenAI Codex reasoning-level dial before recommending a model upgrade. Maps task type, failure mode, and budget to the right reasoning effort level — ensuring developers exhaust the reasoning dial on the current model before paying for a bigger SKU. Domain-specific to the Codex reasoning API. |
| `coding-agent-task-scoping` | `ai-coding-model-guidance` | Scope an autonomous AI coding agent task so it is well-bounded, recoverable, and matched to the right model tier before it runs. Reach for this skill before any long, unsupervised, or multi-step agentic run — a poorly scoped task on a frontier model is both expensive and hard to debug. |
| `context-window-planning` | `ai-coding-model-guidance` | Estimate a coding task's context demand and match it to a model tier whose window is sufficient, without quoting specific token counts that churn monthly. Reach for this skill when the task involves large codebases, long conversation histories, or multi-file agentic runs where context overflow would produce silent truncation errors. |
| `copilot-surface-audit` | `ai-coding-model-guidance` | Audit a developer's GitHub Copilot configuration across all surfaces (completions, chat IDE, coding agent, cloud agent, mobile) to identify model gaps, plan mismatches, and org-policy constraints. Reach for this skill before recommending a Copilot model — surface and plan scope the answer, not just the model name. |
| `grok-model-retirement-check` | `ai-coding-model-guidance` | Check whether a Grok model ID in active use has been retired or silently redirected, with special attention to billing consequences. Reach for this skill before any Grok recommendation and whenever a developer mentions a specific Grok model ID — retirement redirects can incur unexpected charges at the new model's pricing. |
| `lineup-freshness-sweep` | `ai-coding-model-guidance` | Check the ai-coding-model-guidance knowledge bank for stale entries and produce a prioritized refresh list. Reach for this skill when the knowledge bank's retrieval date is more than 4 weeks old, when a consumer reports a model discrepancy, or on the monthly researcher-reminder cadence. |
| `multi-tool-model-comparison` | `ai-coding-model-guidance` | Compare model options across GitHub Copilot, OpenAI Codex, and xAI Grok for a single task when the developer has not committed to one ecosystem. Produces a structured side-by-side that surfaces availability, tier mapping, and key tradeoffs without naming specific volatile numbers. |
| `org-policy-model-rules-audit` | `ai-coding-model-guidance` | Audit an organization's AI coding tool model-access policies across GitHub Copilot Business/Enterprise, OpenAI org-level controls, and xAI API governance. Reach for this skill when an enterprise team reports unexpected model access, when a compliance review requires documenting which models the org has allowed or blocked, or before rolling out a new model to a large org. |
| `quota-exhaustion-failover` | `ai-coding-model-guidance` | Hard gate when a coding agent/surface returns quota, rate-limit, weekly/monthly cap, spend-limit, or tokens-exhausted. Never silent-fail or blind-retry — try param/effort/scope levers before vendor failover, then traverse the vendor-neutral tier tree before naming a substitute SKU. Deep layer: coding-agent-levers-playbook. |
| `budget-tokens` | `ai-rag-engineering` | Compute cost per request and right-size the context to fewest-high-precision chunks. Reach for this on a cost/context question. |
| `build-rag-eval` | `ai-rag-engineering` | Build a judgment set and measure recall@k, precision@k, faithfulness, and answer-relevance with a baseline. Reach for this before shipping any change. |
| `diagnose-retrieval` | `ai-rag-engineering` | Separate retrieval failure from generation failure by measuring recall@k before touching the model. Reach for this first on wrong answers. |
| `ground-and-guardrail` | `ai-rag-engineering` | Add citations, refuse-on-empty-retrieval, and context-constraint to cut hallucination. Reach for this on a faithfulness question. |
| `tune-chunking` | `ai-rag-engineering` | Tune chunk size, overlap, and structure-awareness against the eval and the context budget. Reach for this on a chunking question. |
| `design-ai-redteam-plan` | `ai-red-teaming` | Scope an AI red-team engagement by threat-modeling the system (assets, attackers, trust boundaries), splitting safety from security, traversing the attack-taxonomy decision tree to a prioritized OWASP LLM Top 10 / MITRE ATLAS attack list, and setting the rules of engagement plus likelihood×impact success and severity criteria. Reach for this when the user asks "how should we red-team this LLM feature?", "what should we attack first?", "is this a safety or a security problem?", or "what are the rules of engagement?". Used by `ai-redteam-lead` (primary). |
| `harden-and-remediate-ai-system` | `ai-red-teaming` | Triage red-team findings by likelihood×impact and drive defense-in-depth remediation — layered input/output guardrails, injection-resistant prompt structure, least-privilege tool scoping, allow-lists, human-in-the-loop on high-impact actions, output-handling hygiene, and rate/cost limits — then retest each fix with the exact attack that found it and bake it into the regression harness. Reach for this when the user asks "we have a pile of red-team findings — what do we fix and how?", "harden our LLM against prompt injection", or "how do we stop the agent from being tricked into tool calls?". Used by `adversarial-testing-engineer` (primary). |
| `run-adversarial-attacks-and-jailbreaks` | `ai-red-teaming` | Execute the prioritized attacks against an AI system within the rules of engagement — direct and indirect prompt injection, jailbreaks (roleplay, encoding, many-shot, crescendo), training-data extraction and data exfiltration, agentic tool-abuse / excessive agency, and multimodal attacks — capturing each as a reproducible payload plus transcript, then automating what repeats into a PyRIT / Garak / Promptfoo red-team / Giskard harness with a scorer and a CI regression gate. Reach for this when the user asks "run the jailbreak and injection attacks", "build an automated red-team suite", or "can our agent be tricked into calling tools it shouldn't?". Used by `adversarial-testing-engineer` (primary). |
| `data-quality-testing` | `analytics-engineering` | Keep the warehouse trustworthy: dbt tests (not_null/unique/accepted_values/relationships) gating the build in CI, source-freshness checks, model contracts at consumer boundaries, singular tests for business invariants, and anomaly detection beyond schema tests. |
| `dbt-ci-governance` | `analytics-engineering` | Design a dbt CI pipeline that gates every pull request: compile, run, test, and check source freshness in an isolated developer schema; enforce model contracts on published marts; run slim CI on changed models only using dbt state comparison; and block merges on test failures or contract violations. |
| `dbt-modeling` | `analytics-engineering` | Model in dbt across staging -> intermediate -> marts layers, choose materialization (view/table/incremental) by the trade, write correct incremental models (reliable unique key, is_incremental filter, late-data strategy), and keep it DRY with refs/sources/macros. |
| `incremental-model-patterns` | `analytics-engineering` | Build reliable incremental dbt models: choose the right unique_key and strategy (append, merge, delete+insert), handle late-arriving data and out-of-order events, write a safe is_incremental filter, and design the full-refresh fallback — so the model is idempotent from day one. |
| `semantic-metrics-layer` | `analytics-engineering` | Build a governed semantic/metrics layer: define each metric once as metrics-as-code (dbt Semantic Layer/MetricFlow) with explicit grain and filters, model entities/dimensions to prevent fan-out, and expose one contract every BI tool consumes — ending metric drift. |
| `api-deprecation-rollout` | `api-engineering` | Step-by-step playbook for deprecating and sunsetting an API version — header strategy, consumer communication timeline, traffic monitoring gates, and the SDKs/portal update checklist. |
| `cursor-pagination-design` | `api-engineering` | Playbook for designing cursor (keyset) pagination on list endpoints: cursor encoding, response envelope, query parameter contract, and the migration path away from offset pagination. |
| `idempotency-key-design` | `api-engineering` | Playbook for designing safe-to-retry POST and PATCH operations using Idempotency-Key — covers key format, dedup window, stored-response replay, conflict handling, and OpenAPI declaration. |
| `openapi-contract-authoring` | `api-engineering` | Step-by-step playbook for writing a contract-first OpenAPI 3.1 document — from info block to path items, component reuse, and Spectral pre-flight. Covers resource modeling, status codes, error schema, and pagination shape. |
| `problem-details-error-design` | `api-engineering` | Playbook for designing a consistent RFC 9457 Problem Details error model — type URIs, extension members, status code mapping, and a catalog template. Prevents per-endpoint bespoke error shapes. |
| `spectral-ruleset-authoring` | `api-engineering` | Playbook for writing and wiring a Spectral ruleset that enforces an API style guide in CI — covers rule anatomy, severity levels, custom functions, and the recommended core-rules baseline. |
| `choose-statistical-test` | `applied-statistics` | Pick the right hypothesis test for a described scenario by traversing the test-selection decision tree (data type → #groups → paired? → assumption gate → test), then return the recommended test, its assumption checks, its nonparametric fallback, and a ≤10-line runnable snippet. Reach for this when the user asks "which test do I use?" or hands over two-or-more groups/variables to compare. Used by `applied-statistician` (primary). |
| `experiment-analysis` | `applied-statistics` | Analyze a completed A/B test or experiment defensibly — check it against the pre-registered plan, run the primary-metric test, report effect size + CI (not just p), check guardrail metrics, apply a multiple-comparison correction across metrics/segments, and screen for the peeking/p-hacking pitfalls before declaring a winner. Used by `applied-statistician` (primary). |
| `power-and-sample-size` | `applied-statistics` | Compute or advise the sample size an experiment needs BEFORE it launches — from α (0.05), power (0.80), and a minimum detectable effect (MDE) — or compute the power/MDE a fixed sample can achieve. Prevents the underpowered-study pitfall and is the prerequisite to any A/B test. Returns the n, the assumptions behind it, and a runnable snippet. Used by `applied-statistician` (primary). |
| `regression-and-forecasting-review` | `applied-statistics` | Review or design a regression model or a time-series forecast so it's defensible — pick the model family (OLS / logistic / Poisson GLM; ARIMA / SARIMAX / ETS), check the assumptions that matter for that family, report honest prediction/confidence intervals, and screen for overfitting, data leakage, and "coefficient = cause" overreach. Used by `applied-statistician` (primary). |
| `statistical-qa-of-metrics` | `applied-statistics` | Decide whether a dashboard metric movement, comparison, or trend is signal or noise — and annotate it honestly (significance, confidence interval, "not enough data yet"). The interop seam with data-platform — invoked by `data-platform/dashboard-builder` when a widget shows a comparison/trend that needs a statistical-validity annotation. data-platform answers "is this number correct?"; this skill answers "is it real?". Used by `applied-statistician` (primary) + `data-platform/dashboard-builder`. |
| `comfort-safety-and-accessibility` | `ar-vr-xr-engineering` | Treat XR comfort, physical safety, and accessibility as requirements: hold a sustained framerate, choose comfortable locomotion, design for the tracking volume / guardian / play-space and passthrough so users don't hit walls, and ship accessibility options (seated mode, one-handed paths, snap turn, captions, adjustable text) as defaults. Comfort research verify-at-use. |
| `spatial-rendering-and-performance` | `ar-vr-xr-engineering` | Hold the XR frame budget: derive the per-eye ms target from the device refresh rate, profile on device to find the CPU-vs-GPU-vs-thermal bound, cut draw calls / overdraw / fill rate in order, and use foveated rendering and reprojection as headroom not a crutch — budgeting for the thermal-sustained clock, not peak. Device numbers verify-at-use. |
| `xr-interaction-and-locomotion` | `ar-vr-xr-engineering` | Design and implement XR interaction: hand / controller / gaze input on an OpenXR action abstraction, locomotion chosen for comfort (teleport / dash / snap-turn vs smooth + vignette), reachable and readable 3D UI, and intentional grab/physics — with accessibility built in as a requirement. Input-API specifics verify-at-use. |
| `xr-target-and-engine-selection` | `ar-vr-xr-engineering` | Choose the XR target platform (standalone headset vs PC-VR vs WebXR vs mobile-AR) and engine (Unity / Unreal / native-OpenXR / WebXR) on the use-case, audience device, and distribution channel — then commit to an OpenXR-first architecture and derive the per-eye perf budget the target implies. Device/version specifics verify-at-use. |
| `control-scope-creep` | `architecture-aec` | Distinguish in-scope iteration from additional services and authorize the difference, so unbilled changes don't erode the fee. Reach for this when the design keeps changing. |
| `coordinate-the-set` | `architecture-aec` | Read the drawing set for cross-discipline coordination and constructability, since a coordinated set beats a beautiful one. Reach for this in CD. |
| `phase-load-the-fee` | `architecture-aec` | Build a fee that matches the effort curve across the design phases, not a flat percentage, so the heavy phases aren't underwater. Reach for this on any fee proposal. |
| `read-firm-economics` | `architecture-aec` | Read utilization and net multiplier to separate a busy firm from a profitable one. Reach for this on a practice-health question. |
| `read-rfi-pattern` | `architecture-aec` | Read the RFI and change-order pattern as a coordination signal to improve the next set, not just process this one. Reach for this when RFIs are high. |
| `choose-audio-dsp-architecture` | `audio-dsp-engineering` | Pick the right audio-DSP architecture for a described product by traversing the audio-DSP architecture decision tree (latency tolerance → processing model → time-vs-frequency domain → fixed-vs-float + denormals → platform/plugin format + audio I/O), then return the recommended processing model, latency & buffer-size budget, sample rate/bit depth, numeric strategy, algorithm approach (IIR/FIR/FFT-STFT, oversampling), framework + plugin format + audio backend, and the conditions that would flip the choice. Reach for this when the user asks "block or sample-by-sample?", "what latency/buffer size?", "JUCE + VST3/AU/CLAP or Web Audio?", "fixed-point or float?", or "IIR biquad vs FIR vs FFT for this effect?". Used by `audio-dsp-architect` (primary). |
| `design-signal-processing-chain` | `audio-dsp-engineering` | From an effect or product goal and its architecture, derive the signal-processing chain — the block diagram (stage order), the per-stage algorithm (IIR biquad / FIR / FFT-STFT / delay / dynamics), the per-stage and total latency, the sample rate and gain-staging/headroom, the oversampling plan for any nonlinearity, and the parameter list with smoothing needs — captured in the DSP design spec. Reach for this when the user asks "design the effect chain for this", "what order should these processors go in?", or "map out the DSP stages and their latency". Used by `dsp-implementation-engineer` and `audio-dsp-architect`. |
| `implement-and-optimize-realtime-audio` | `audio-dsp-engineering` | Implement a DSP stage as real-time-safe code in the audio callback (no locks, no allocation, no syscalls, no unbounded work — everything pre-allocated at prepare time), handle denormals with flush-to-zero, pass parameters lock-free (atomic / SPSC FIFO) with per-sample smoothing, then optimize the profiled hot loop with SIMD (SSE/AVX/NEON/CMSIS-DSP) and verify with objective measurement (null test, THD+N, impulse/frequency response, RT-safety audit). Reach for this when the user asks "write the real-time-safe processBlock", "optimize this hot loop", "pass params without a data race", or "null-test / measure this effect". Used by `dsp-implementation-engineer` (primary). |
| `add-an-auth-provider` | `auth-identity` | Add a login method to an existing Supabase Auth app — Apple, Microsoft, GitHub social SSO, plus magic link, passkeys (WebAuthn), or email+password. The generic enable-provider procedure with each provider's gotchas (especially Apple's expiring ES256 secret + first-login name capture). Generalizes google-sso-setup to the variety pack. |
| `authorization-rbac` | `auth-identity` | RBAC and ABAC in the application layer: defining roles and claims, mapping the authenticated identity to roles, enforcing roles in middleware and UI. The critical seam: row-level data scoping hands off to data-platform RLS via auth.uid(). Authentication proves identity; authorization controls access. |
| `gate-the-dashboard` | `auth-identity` | Put the analytics dashboard and embedded BI behind login: app-shell login gate + session check + the handoff to data-platform's embed-JWT and RLS for per-user data isolation. The clearest expression of the auth-identity → data-platform seam. |
| `google-sso-setup` | `auth-identity` | Wire Sign in with Google end-to-end: Google Cloud OAuth client + consent screen + redirect URIs + scopes, then via Supabase Auth's Google provider (and a note on the Auth.js / direct path). Step-by-step with verification checkpoints. |
| `oauth-oidc-flow-design` | `auth-identity` | Pick and implement the right OAuth 2.0 / OIDC flow by client type: Authorization Code + PKCE for SPA and native apps, confidential-client code flow for server-side apps, client-credentials for M2M. ID-token vs access-token vs refresh-token handling. Deprecated Implicit flow is never recommended. |
| `protect-spa-and-api` | `auth-identity` | Protect a React/Next.js SPA with route guards and middleware, and protect an API with token-verification middleware (signature + iss + aud + exp). Covers CORS configuration and CSRF defense. Applies to both the web-app and the API/backend targets. |
| `session-and-token-management` | `auth-identity` | Session vs JWT trade-offs; HttpOnly+Secure+SameSite cookie storage; refresh-token rotation; logout and revocation; storage anti-patterns (no tokens in localStorage or sessionStorage). The post-sign-in half of the auth lifecycle. |
| `effective-labor-rate-and-gross-profit` | `auto-repair-shop-operations` | Read a repair shop's two profit engines separately: labor GP (effective labor rate x billed hours minus tech cost) and parts GP (the matrix over cost). Measure effective labor rate as posted rate minus discounts, warranty, comebacks, and unapplied time. Benchmarks verify-at-use; no PII. |
| `estimate-and-dvi-workflow` | `auto-repair-shop-operations` | Turn a write-up and a digital vehicle inspection (DVI) into a sold, defensible estimate: verified complaint, diagnostic authorization, DVI evidence per line, labor-guide hours x shop rate, parts at matrix, sell-now vs sell-later triage, and declined-work follow-up. Labor times/rates verify-at-use; no PII. |
| `ro-lifecycle-and-comeback-control` | `auto-repair-shop-operations` | Run the repair order from open to closed and stop comebacks at the root cause: WIP/RO aging triage (waiting on approval vs parts vs tech), parts staging before dispatch, and comeback grouping by cause (misdiagnosis, workmanship, part quality, incomplete, no-fault). Rework labor is billed at zero. No PII. |
| `technician-productivity-and-efficiency` | `auto-repair-shop-operations` | Diagnose a repair shop's labor throughput with the three distinct dials: productivity (clocked/available), efficiency (billed/clocked), and proficiency (billed/actual). Match dispatch to skill, read them separately, and fix the right one. Benchmarks verify-at-use; no PII. |
| `compute-absorption` | `automotive-dealership` | Compute the service absorption rate against total fixed overhead — the survival metric. Reach for this on a fixed-ops question. |
| `compute-total-gross` | `automotive-dealership` | Compute total gross per unit as front plus F&I back, with penetration. Reach for this on a deal-profitability question. |
| `diagnose-sales-funnel` | `automotive-dealership` | Diagnose the lead-to-sold funnel by conversion step — a volume gap is usually a conversion gap. Reach for this on a sales-volume question. |
| `frame-fi-penetration` | `automotive-dealership` | Frame F&I product penetration and PVR back-end gross inside the compliance boundary. Reach for this on an F&I question. |
| `read-days-supply` | `automotive-dealership` | Read inventory days-supply against a target and quantify floorplan carrying cost. Reach for this on an inventory question. |
| `aws-account-strategy` | `aws-cloud` | Design a multi-account AWS landing zone: separate accounts by blast radius (prod/non-prod/security/shared-services) under Organizations, SCP guardrails as ceilings, region/AZ resilience, and the Control-Tower-or-not decision. |
| `aws-compute-selection` | `aws-cloud` | Choose AWS compute by workload shape and operational burden: Lambda (event/spiky), Fargate/ECS Express Mode (containers, no cluster ops), EKS (k8s/portability), EC2 (legacy/specific); design event-driven integration with idempotency and DLQs. |
| `aws-finops` | `aws-cloud` | Control AWS cost: cost allocation tags from day one, budgets + anomaly detection, rightsize before committing to Savings Plans/RIs, tested backups, and continuous zombie-resource cleanup. |
| `aws-least-privilege-iam` | `aws-cloud` | Write least-privilege AWS IAM: scope actions and resource ARNs to exactly what's needed, attach to roles (not users/keys), prefer federation (IRSA/OIDC) and Identity Center, and cap with permission boundaries + SCPs. |
| `aws-observability-and-alerting` | `aws-cloud` | Step-by-step playbook for wiring CloudWatch metrics, alarms, dashboards, and X-Ray distributed tracing into an AWS workload — from log groups and metric filters to composite alarms and anomaly detection. |
| `vpc-network-design` | `aws-cloud` | Step-by-step playbook for designing an AWS VPC — CIDR allocation, subnet layout, routing, security groups vs NACLs, egress control, and PrivateLink/VPC endpoint placement. Covers single-VPC through multi-account Transit Gateway topologies. |
| `azure-cost-rightsizing` | `azure-cloud` | FinOps playbook for diagnosing Azure overspend and rightsizing resources — covers Cost Management query patterns, compute/storage/Log Analytics levers, reservation vs savings plan decisions, and the budget-alert setup checklist. |
| `bicep-module-authoring` | `azure-cloud` | Playbook for writing production-ready Bicep modules — parameter hygiene, AVM alignment, what-if verification, output contracts, and the CI/CD integration checklist. Covers both standalone and AVM-wrapper patterns. |
| `compute-host-selection` | `azure-cloud` | Decision playbook for choosing the right Azure compute service — App Service, Container Apps, Azure Functions, Static Web Apps, or AKS — based on workload shape, ops burden, and scaling requirements. |
| `private-endpoint-wiring` | `azure-cloud` | Step-by-step playbook for locking down Azure PaaS services (Key Vault, Storage, SQL, Cosmos) behind Private Endpoints with Private DNS — covers DNS zone setup, NSG rules, and the disable-public-access checklist. |
| `workload-identity-federation` | `azure-cloud` | Playbook for configuring passwordless CI/CD using Workload Identity Federation — covers app registration, federated credential setup for GitHub Actions and Azure DevOps, RBAC assignment, and the OIDC token exchange flow. |
| `api-contract-testing` | `backend-engineering` | Playbook for implementing consumer-driven contract tests (Pact) between backend services so API contract breaks surface in CI before they reach integration environments. |
| `backend-implementation` | `backend-engineering` | Implement business logic cleanly: keep the framework at the edges with logic in testable use-cases, model errors explicitly (expected vs bug), validate inputs into domain types at the boundary, add idempotency keys for retried operations, and use the outbox for write-then-publish. |
| `backend-resilience` | `backend-engineering` | Make the backend survive its dependencies: timeout every outbound call, retry idempotent-only with exponential backoff + jitter, add circuit breakers and bulkheads, define a graceful-degradation mode, and design idempotent background workers with DLQs and backpressure. |
| `caching-and-data-access` | `backend-engineering` | Own the data-access layer: queries behind a repository, short explicit transaction boundaries (never across HTTP), kill ORM N+1 by eager-loading/batching, and cache-aside with a defined invalidation trigger plus stampede (single-flight) protection. |
| `error-handling-and-result-modeling` | `backend-engineering` | Playbook for modeling and propagating errors in backend services — typed result/error envelopes, failure classification, HTTP status mapping, error translation at layer boundaries, and client-safe vs internal error separation. Prevents exception-driven spaghetti and accidental information leakage. |
| `service-boundary-design` | `backend-engineering` | Decide backend structure: default to a modular monolith, split into services only for a concrete need (scaling, team autonomy, deploy/runtime isolation), draw boundaries by bounded context (each owning its data), and choose sync vs async per seam. |
| `audit-documentation-billing` | `behavioral-health-practice` | Read note timeliness and medical-necessity completeness as one revenue-and-compliance control — operationally, never as a clinical judgment. Reach for this on a denial or audit-readiness question. |
| `manage-no-show-flow` | `behavioral-health-practice` | Quantify no-show/late-cancel as a flow — lost slots, lost revenue, and the recovery a reminder program delivers. Reach for this on a no-show question. |
| `model-payer-mix` | `behavioral-health-practice` | Read reimbursement net of variable cost by payer, compute blended margin, and model a mix shift — flagging parity for counsel. Reach for this on a payer or margin question. |
| `shorten-access-time` | `behavioral-health-practice` | Read intake-to-first-appointment access time as the conversion lever and find where the delay loses referrals. Reach for this on an access or conversion question. |
| `size-caseload` | `behavioral-health-practice` | Size clinician caseload capacity against measured demand and the no-show-adjusted fill rate, not a guessed ratio. Reach for this on a staffing or utilization question. |
| `choose-bioinformatics-pipeline-and-stack` | `bioinformatics-engineering` | Pick the right genomics workflow engine, reference build, tool chain, compute strategy, and reproducibility approach for a described analysis by traversing the bioinformatics pipeline decision tree (assay/question → curated community pipeline exists? → portability/team fluency → HPC vs cloud → reference build), then return the recommended engine (Nextflow/nf-core / Snakemake / WDL+Cromwell / CWL), the reference (GRCh38 vs T2T-CHM13) with the build hazards, the aligner/variant-caller chain, the compute plan (Slurm vs cloud Batch/spot + cost shape), the reproducibility approach, the validation truth set, and the conditions that would flip the choice. Reach for this when the user asks "Nextflow vs Snakemake vs WDL?", "GRCh38 or T2T-CHM13?", "HPC or cloud for this pipeline?", or "how do we make this reproducible?". Used by `bioinformatics-workflow-architect` (primary). |
| `design-genomics-analysis-workflow` | `bioinformatics-engineering` | From a scientific question, an assay, and a sample design, derive the concrete genomics analysis workflow — the per-sample step graph (QC, trimming, alignment, dedup, BQSR-or-not, variant calling or quantification), the cohort/joint step (joint genotyping or differential-expression model), the reference build and its matching accessory files, and the validation truth set — captured as an analysis plan. Reach for this when the user asks "design the WGS germline workflow", "what steps does this RNA-seq analysis need?", or "how do we structure the per-sample and cohort steps?". Used by `genomics-pipeline-engineer` and `bioinformatics-workflow-architect`. |
| `implement-and-scale-bioinformatics-pipeline` | `bioinformatics-engineering` | Implement a designed genomics workflow in the chosen engine, containerize and pin every tool for reproducibility, scale it with scatter/gather on HPC Slurm or cloud Batch (spot on the fault-tolerant steps), and validate it against a GIAB/GA4GH hap.py truth set — then produce a pipeline-validation report. Reach for this when the user asks "build this pipeline in Nextflow/Snakemake/WDL", "containerize and pin it for reproducibility", "scale/cost-optimize this on Slurm or cloud", or "benchmark our variant calls against GIAB". Used by `genomics-pipeline-engineer` (primary). |
| `audit-before-deploy` | `blockchain-web3-engineering` | Gate deploy on a security audit and invariant tests across the top vuln classes — deploy is irreversible. Reach for this before any mainnet go-live. |
| `model-staking-yield` | `blockchain-web3-engineering` | Model an illustrative net staking APR and annual reward — clearly NOT financial advice. Reach for this on a yield or reward question. |
| `optimize-gas` | `blockchain-web3-engineering` | Profile gas and cut the dominant costs — storage writes and loops — then estimate the user-facing cost. Reach for this on a cost or UX-cost question. |
| `split-on-off-chain` | `blockchain-web3-engineering` | Decide deliberately what lives on-chain vs off-chain on cost and privacy grounds. Reach for this on any data-placement question. |
| `threat-model-protocol` | `blockchain-web3-engineering` | Build the threat model beyond code — oracle, flash-loan, and MEV economic surface. Reach for this on a 'can we be drained?' question. |
| `brand-book-assembly` | `brand-identity-studio` | Compile the finished brand system into a dynamic brand-book hub (logo rules, color tokens, type, voice, imagery, usage do/don'ts), DELEGATE the token build to web-design:design-tokens-scaffolding, spec the favicon/OG asset set, and enforce the legal-sign-off precondition (can't mark client-ready without the curation + authorship log and every IP/font claim routed to security-reviewer). Hands the finished system to web-design:visual-designer. |
| `brand-legal-and-licensing` | `brand-identity-studio` | State the load-bearing brand-IP facts (AI-logo copyright ≠ trademark; documented human authorship; font web-license class OFL/Adobe/Monotype; provider indemnity) and route EVERY client-facing IP / registrability / font-license claim to ravenclaude-core:security-reviewer and counsel. Not legal advice — states facts, never conclusions; recommends a TM clearance search before promising trademarkability. |
| `brand-strategy-and-naming` | `brand-identity-studio` | Author the brand strategy substrate BEFORE any visual generation — a discovery questionnaire → positioning statement, value proposition, target audience, and archetype — then bulk-draft business/product names + taglines and hand a human-curated shortlist. Owns the strategy-before-visuals gate artifact. Naming availability + trademark collisions route to security-reviewer; not legal advice. |
| `brand-voice-and-messaging` | `brand-identity-studio` | Build the verbal identity — a voice platform (3–5 attributes, tone-shift rules by context, do-say/don't-say pairs, a term glossary) and a messaging hierarchy (tagline, elevator, value pillars). The half of the brand book a logo tool skips; authored from the strategy brief, applicable by someone who isn't the author. |
| `logo-and-visual-system-direction` | `brand-identity-studio` | Direct the visual identity: author the anti-slop creative brief for generative-web-media (setting indemnity_required), run the human-curation + documented-human-authorship gates, and spec the logo suite (lockups/clear-space/min-size/mono/B&W), color roles with WCAG-AA pairs, and type with web-license class. Refuses without a strategy brief. The curated vector is the deliverable — never regenerated in Firefly. |
| `build-browser-extension` | `browser-extension-engineering` | End-to-end workflow to build a Manifest V3 browser extension: decide which context owns each piece of logic (content script vs MV3 service worker vs injected page script vs popup/options), wire messaging between contexts, request the narrowest permissions (activeTab -> optional -> host -> all_urls), and pass Chrome/Edge/Firefox store review. Complements the manifest-permissions-audit and store-submission-readiness skills. The popup/options UI seams to frontend-engineering. |
| `manifest-permissions-audit` | `browser-extension-engineering` | Audit a browser extension's manifest.json against the least-privilege bar and Manifest V3 conformance: every permission and host match justified, activeTab/optional-permission opportunities, no remotely-hosted code, scoped web_accessible_resources, and the store-review risk each entry carries. Reach for this before a store submission, after a permissions rejection, or when reviewing an inherited extension. |
| `store-submission-readiness` | `browser-extension-engineering` | A pre-submission readiness checklist for shipping a browser extension to the Chrome Web Store, Edge Add-ons, and Firefox AMO: required listing metadata, the privacy + permissions justification, single-purpose conformance, data-disclosure forms, and the common rejection reasons to pre-empt. Reach for this before a first submission, after a rejection, or when adding a new store target. Store-policy specifics are volatile — verify against current store docs. |
| `frame-280e-cogs` | `cannabis-operations` | Build a defensible COGS-allocation framework under 280E, as decision-support for the CPA, so only properly-capitalized cost reduces taxable income. Reach for this on any tax-burden question. |
| `manage-the-state-patchwork` | `cannabis-operations` | Anchor every compliance answer to the specific state and date, since track-and-trace, testing, potency, and tax all vary. Reach for this on any compliance claim. |
| `read-inventory-turns` | `cannabis-operations` | Read inventory turns as both a cash and a compliance metric, flagging aged and perishable product. Reach for this on a cash or expiry question. |
| `reconcile-seed-to-sale` | `cannabis-operations` | Reconcile physical inventory to the state track-and-trace system and resolve discrepancies as compliance events, not bookkeeping. Reach for this on any traceability question. |
| `run-dispensary-retail` | `cannabis-operations` | Read category margin, basket, and turns and lift store profit without discount-driven traffic. Reach for this on a store-margin question. |
| `design-resilience-patterns` | `chaos-engineering-resilience` | Pick and place the right resilience patterns for a given failure mode — the timeout / retry+backoff+jitter+budget / circuit-breaker / bulkhead / load-shedding / graceful-degradation / fallback / idempotency / backpressure decision. Start from an FMEA, choose the pattern that defends the NAMED failure, and defend the pattern's OWN failure mode. Reach for this when the user asks 'what do we add so a slow/failing dependency doesn't take us down?', 'is a naked retry safe here?', or 'where are our single points of failure?'. Used by `resilience-architect` (primary). |
| `plan-game-day` | `chaos-engineering-resilience` | Facilitate a game day end to end — the scenario, the roles (facilitator / operators / observers / scribe), the comms plan, the abort criteria, a scoring rubric, and the follow-up remediation backlog. Game days test PEOPLE and RUNBOOKS under a controlled failure, not just systems — the cheapest way to find the org's real failure modes. Reach for this when the user asks 'run us a game day for X', 'how do we do a failure drill', or 'test our on-call/runbooks against an outage'. Driven by `chaos-experiment-engineer`; the `resilience-architect` is consulted on prerequisites + remediation. |
| `run-chaos-experiment` | `chaos-engineering-resilience` | Run the full chaos-experiment loop safely — steady-state definition → falsifiable hypothesis → the smallest disproving blast radius → inject a fault from the taxonomy → observe (metrics correlated to the injection window, under load) → abort-or-learn → remediate. Gate on the maturity check first (no steady-state observability = no experiment) and never inject without an automatic abort condition. Reach for this when the user asks 'design/run a chaos experiment for X', 'which fault do we inject first?', or 'did the resilience pattern actually hold?'. Used by `chaos-experiment-engineer` (primary). |
| `enrollment-and-waitlist-management` | `childcare-early-education` | Run the childcare enrollment funnel and waitlist: inquiry -> tour -> application -> start, with a tour follow-up cadence, waitlist worked by age band, and the waitlist converted before tuition is discounted. Enrollment fills seats; retention keeps them. |
| `ratios-and-licensing-compliance` | `childcare-early-education` | Keep every room legal continuously: child:staff ratio AND group-size cap by age (two separate limits), who counts toward ratio by qualification, and the licensing domains (staff files, health & safety, records) maintained daily. State-specific and verify-at-use. |
| `staffing-to-ratio-scheduling` | `childcare-early-education` | Schedule staff to the required ratio at a cost the tuition covers: model labor as a step function that jumps a whole teacher at each ratio boundary, cover open/close and breaks in ratio, and read the ratio-driven labor cost per room against its revenue. State-specific ratios verify-at-use. |
| `tuition-and-subsidy-billing` | `childcare-early-education` | Route and collect childcare tuition on the right rail: private-pay vs CCDF/state subsidy vs blended, the parent-fee/co-pay split, authorization and attendance rules that drive subsidy payment, and reconciliation as receivables. State-specific subsidy rules are verify-at-use. |
| `build-cash-and-wellness-plan-model` | `chiropractic-practice` | Price a compliant cash / membership / wellness-plan model for a chiropractic practice: a supportive-care membership priced to the clinical cadence and above delivery cost, the covered-active-care vs cash-maintenance boundary drawn cleanly, and the ABN/discount-compliance guardrails so a plan isn't an illegal inducement or a way to bill maintenance as active. Reach for it when designing memberships or a cash model. Used by `chiropractic-practice-lead` (primary). |
| `code-and-document-the-visit` | `chiropractic-practice` | Pick the CMT/E&M code for a chiropractic visit and structure the medical-necessity note: CMT by number of spinal regions treated, an E&M only when separately identifiable (with the correct modifier), and a PART-exam-based note (region + functional goal + progress) that supports the code and survives an audit. Reach for it per visit / when coding is unclear. Used by `chiro-billing-compliance-specialist` (primary). Not a coding certification — verify payer policy. |
| `design-care-plan-and-cadence` | `chiropractic-practice` | Build a defensible, phased chiropractic care plan: an acute/corrective/supportive phase structure with a visit cadence, re-exam checkpoints that re-justify continued care, functional goals, and a plan-completion target — with the insurance-vs-cash boundary drawn so covered active care and cash maintenance care don't blur. Reach for it when structuring a new patient's care. Used by `chiropractic-practice-lead` (primary). |
| `agent-sdk-hook-design` | `claude-app-engineering` | Playbook for designing Claude Agent SDK hooks (PreToolUse, PostToolUse, SessionStart, Stop) — selecting the right event, writing the handler contract, deciding advisory vs blocking behaviour, and avoiding the four common hook anti-patterns. Owned by agent-sdk-engineer. |
| `context-budget-planner` | `claude-app-engineering` | Playbook for allocating a Claude context window across system prompt, retrieved documents, conversation history, and tool results — with token-budget formulas, the retrieve-vs-hold decision, and the compaction triggers that prevent context overflow. Owned by prompt-and-context-engineer. |
| `eval-golden-set-builder` | `claude-app-engineering` | Playbook for constructing a high-signal golden evaluation set: sampling strategy, input diversity, reference-answer authoring, grader pairing, and the minimum-viable size thresholds that make a delta meaningful. Owned by eval-engineer. |
| `llm-routing-ladder` | `claude-app-engineering` | Playbook for designing a cost-optimised model routing ladder: classifying request complexity, wiring the triage→escalate flow, measuring cost-per-resolved-task, and avoiding the common over-provisioning traps. Owned by claude-app-ops-engineer and claude-solution-architect. |
| `mcp-server-authoring-checklist` | `claude-app-engineering` | Gate-by-gate checklist for shipping a production MCP server: transport selection, tool-schema quality, auth wiring, error-response contract, and the security hand-off items that must escalate to core/security-reviewer. Owned by mcp-and-server-tools-engineer. |
| `prompt-caching-audit` | `claude-app-engineering` | Step-by-step playbook for diagnosing a low cache hit rate, finding the breakpoint placement errors that cause it, and correcting them. Covers TTL tradeoffs, pre-warming, tool-definition stability, and the per-model minimum-token floors. |
| `tool-schema-design` | `claude-app-engineering` | Playbook for designing Claude tool definitions (name, description, JSON Schema input_schema) that maximise correct invocation, minimise hallucinated arguments, and produce clean structured output. Covers naming conventions, description prompting, schema constraints, required vs optional fields, and the forced-tool-call pattern. |
| `cli-design-and-arg-parsing` | `cli-tooling-engineering` | Design a CLI's command/subcommand surface, flags vs positionals, and config precedence (flags > env > file > default), then pick the idiomatic parser for the language. Use when starting a CLI or reworking a messy one. |
| `cli-distribution-and-packaging` | `cli-tooling-engineering` | Plan how a CLI ships and updates — single static binary vs runtime package, cross-compilation, install channels (Homebrew/Scoop/winget/npm/pipx), a build-stamped --version, and a safe installer. Use when making a tool installable and keeping it current. |
| `output-and-exit-code-contract` | `cli-tooling-engineering` | Define a CLI's output contract — human by default, --json on demand, data to stdout, diagnostics to stderr — and an exit-code map treated as a public API. Use when a tool must serve both humans and scripts, or CI keeps passing on real failures. |
| `shell-completions-and-config` | `cli-tooling-engineering` | Generate shell completions (bash/zsh/fish/PowerShell) from the parser and design config-file discovery + env-var conventions (XDG, TOOL_* prefixes). Use when adding tab completion or a config/env layer to a CLI. |
| `tui-design` | `cli-tooling-engineering` | Decide whether a full-screen TUI is warranted (vs a scriptable CLI), pick the framework (Ink / Bubble Tea / Textual / ratatui), and design the render-loop + non-TTY fallback. Use for interactive terminal dashboards, pickers, and wizards. |
| `accelerate-site-activation` | `clinical-trials` | Sequence site selection, contracting, and start-up as the schedule's critical path to cut the activation delay. Reach for this when sites are slow. |
| `design-for-retention` | `clinical-trials` | Build retention into visit burden, schedule, and engagement to lower the ~30% dropout, instead of re-recruiting. Reach for this when dropout threatens the timeline. |
| `plan-recruitment-funnel` | `clinical-trials` | Plan recruitment as a costed funnel with a cost per stage, against the per-patient economics, instead of a hope. Reach for this on any enrollment plan. |
| `read-submission-readiness` | `clinical-trials` | Read documentation completeness, data quality, and eCTD structure throughout the trial so the filing isn't a final-month scramble. Reach for this before a milestone. |
| `stress-test-feasibility` | `clinical-trials` | Stress-test eligibility criteria against the addressable population and site capacity before the protocol locks, since restrictive criteria are the biggest enrollment killer. Reach for this at design. |
| `cluster-upgrade-and-capacity` | `cloud-native-kubernetes` | Playbook for planning and executing a safe Kubernetes control-plane and node-pool upgrade, covering version-skew rules, pre-flight checks, node drain sequencing, and capacity planning for node pools. Prevents the most common upgrade-day outages. |
| `container-hardening-k8s` | `cloud-native-kubernetes` | Build a small, safe container for Kubernetes: multi-stage with a distroless/minimal base, non-root UID, digest-pinned base, dropped Linux capabilities, and a read-only root filesystem. |
| `helm-chart-authoring` | `cloud-native-kubernetes` | Step-by-step guide for authoring a production-grade Helm chart from scratch — directory layout, values design, template hygiene, helpers, chart tests, and lint/security gates — so workloads are packaged reproducibly and safely promoted across environments. |
| `ingress-and-mesh` | `cloud-native-kubernetes` | Design cluster networking: Gateway API ingress for north-south, and a service mesh ONLY when it earns its complexity (mTLS-everywhere, traffic-splitting, per-call resilience). Wire mTLS, weighted canary routing, and resilience deliberately. |
| `k8s-platform-ops` | `cloud-native-kubernetes` | Operate a safe multi-tenant cluster: namespace-per-tenant with scoped RBAC (no workload cluster-admin), default-deny NetworkPolicies, resource quotas/LimitRanges, policy admission control, and tested PDB-respecting upgrades. |
| `k8s-workload-design` | `cloud-native-kubernetes` | Design a Kubernetes workload: choose the workload kind by statefulness, set the three probe types correctly, requests/limits with the resulting QoS class, HPA/VPA on a load-tracking signal, and a PodDisruptionBudget. |
| `build-the-asset-plan` | `commercial-real-estate` | Sequence lease rollovers, recovery improvements, and capex against a quarterly NOI target so a held asset tracks (or beats) its acquisition underwriting. Reach for this once an asset is owned. |
| `decompose-net-effective-rent` | `commercial-real-estate` | Convert a face rent to net effective by netting TI, free rent, and leasing commissions, so comps and underwriting use the rent the landlord actually earns. Reach for this on any rent comp. |
| `price-the-cap-rate-spread` | `commercial-real-estate` | Frame a cap rate as a risk premium over the 10-yr Treasury, not an absolute level, so a 'compression' is read correctly. Reach for this whenever a cap rate enters a memo. |
| `stress-the-debt-and-refi` | `commercial-real-estate` | Size the debt, schedule DSCR through the hold, and surface the refinance year and the rate at which the deal breaks. Reach for this before any levered return is quoted. |
| `underwrite-to-in-place-noi` | `commercial-real-estate` | Build a CRE base case on contractual in-place income before any pro-forma step-up — separating real income from assumed growth so the return rests on something sourced. Reach for this when a deal is being sold on stabilized rents. |
| `cv-model-training-and-evaluation` | `computer-vision-engineering` | Curate and augment the dataset, choose and fine-tune the model (YOLO / DETR / SAM / CLIP / EfficientNet / ViT) on the task and target budget, design the loss and metric to match the cost, spend the annotation budget with active learning, handle class imbalance, and build an eval harness you can trust with per-slice metrics and drift detection. Model/checkpoint specifics verify-at-use; no PII. |
| `cv-task-and-data-strategy` | `computer-vision-engineering` | Frame the computer-vision task (classification / detection / segmentation / OCR / pose / tracking / VLM) on the decision the system must make, choose the metric that mirrors the business cost, decide build-vs-fine-tune-vs-API jointly with the deployment target, and design the data & annotation strategy. Model/metric specifics verify-at-use; no PII, no image data stored. |
| `video-pipeline-and-edge-deployment` | `computer-vision-engineering` | Design streaming-video pipelines that hold the frame budget — frame sampling / keyframe strategy, ROI cropping, tracking-by-detection so the detector doesn't run every frame, and batching where latency allows — and deploy to edge/embedded targets (Jetson, mobile NPU, Coral) with the camera/sensor capture and pre-processing counted inside the budget. Device numbers verify-at-use; no PII. |
| `vision-inference-optimization` | `computer-vision-engineering` | Make a trained vision model fit and run on its target: budget latency on the real device, optimize in order of leverage (quantization INT8/FP16 with calibration, then pruning, then distillation), export to the runtime the target uses (ONNX / TensorRT / CoreML / TFLite / OpenVINO), and re-check accuracy against the operating point after every step. Device/runtime numbers verify-at-use; no PII. |
| `cpm-scheduling` | `construction-general-contractor` | Build and maintain a CPM schedule: activity list, durations, logic ties (FS/SS/FF), critical-path calculation, float analysis, baseline establishment, weekly updates, look-ahead schedules, delay analysis (as-planned vs. as-built, TIA), and recovery scheduling. Tool-agnostic; notes P6 and MS Project specifics. |
| `estimating-and-bidding` | `construction-general-contractor` | Run a complete GC estimate and bid assembly: quantity takeoff from drawings, unit pricing (labor/material/equipment), markup vs. margin conversion, subcontractor scope review, general conditions budget, overhead and profit, contingency, and bid-letter qualification. Covers original bids and change-order re-estimates. |
| `submittals-rfis-change-orders` | `construction-general-contractor` | Manage the GC's submittal register (identify required submittals, set lead-time-driven due dates, track review status), draft and track RFIs (structured question format, response tracking, overdue escalation), and document change orders (CO pricing coordination, package assembly, CO log maintenance). The three processes are connected: RFIs clarify design, submittals confirm procurement, and COs pay for scope changes. |
| `dialog-management-and-tool-calling` | `conversational-ai-voice-engineering` | Design the dialog layer of a voice agent: explicit dialog-state modeling, LLM orchestration, context/window management over a long call, and mid-call function/tool calling that hides latency with natural fillers and treats tool failure as a first-class branch. Design the unhappy path (silence, misrecognition, tool failure, confusion) before the happy path. Provider/SDK specifics verify-at-use. |
| `speech-recognition-and-synthesis` | `conversational-ai-voice-engineering` | Engineer the ASR and TTS layer of a voice agent: choose STT/TTS providers on the channel (narrowband telephony vs wideband web), languages, streaming support, WER, and cost; stream transcription and synthesis to cut latency; tune VAD/endpointing; handle diarization, prosody/SSML, codecs & sample rates, and noise robustness; and measure WER on real audio. Provider/version specifics verify-at-use. |
| `telephony-and-call-flow-integration` | `conversational-ai-voice-engineering` | Integrate a voice agent with real telephony and validate it: SIP/PSTN trunking and media handling, WebRTC for web/app, DTMF capture (in-band vs RFC 2833/SIP INFO), IVR-vs-conversational per step, call routing and warm/cold human transfer with context, and a voice-agent eval harness scoring task success, WER, end-to-end latency, and interruption handling on representative recorded calls. Protocol/provider specifics verify-at-use. |
| `voice-agent-architecture-and-latency` | `conversational-ai-voice-engineering` | Choose the voice-agent pipeline shape (cascade STT->LLM->TTS vs speech-to-speech), the channel (telephony / web / SDK), and the build-vs-platform bet (Twilio / Vapi / Retell / LiveKit / Pipecat), then allocate the end-to-end latency budget per hop and design the turn-taking / barge-in / fallback model. Model/platform/latency specifics verify-at-use. |
| `frame-a-deal-thesis` | `corporate-development-ma` | State the deal thesis — why this target, why now, how value is created — in one sentence before any model is built. Reach for this at the very start of any acquisition, before valuation. |
| `plan-post-merger-integration` | `corporate-development-ma` | Turn synergies into an owner/date/cost-to-achieve register and a 100-day plan, and price integration cost back into the valuation — so the deal isn't underwritten on flawless integration. Reach for this before signing, not after close. |
| `run-a-diligence-plan` | `corporate-development-ma` | Build a confirm-or-kill diligence plan where every workstream tests a named thesis assumption and every finding is mapped to thesis or price impact — not a data-room checklist. Reach for this once a thesis exists and a deal is live. |
| `triangulate-a-valuation` | `corporate-development-ma` | Cross DCF, trading comparables, and precedent transactions into a valuation range where the divergence between methods is itself the finding. Reach for this whenever a price needs defending — one method is an opinion. |
| `club-membership-and-dtc-revenue` | `craft-beverage-operations` | Build the recurring-revenue engine: design club/membership tiers on member lifetime value (shipment value/frequency, benefits), read and reduce churn by cohort, and manage DTC e-commerce. A club member is worth more than a case sold — but churn quietly eats the club. |
| `production-planning-and-cogs` | `craft-beverage-operations` | Cost a craft-beverage unit and plan production against real capacity: decompose COGS per unit (raw material, yield loss, packaging, overhead absorption), read tank/barrel/time capacity and turns, and plan batches against the demand-by-channel plan. You can't price what you can't cost. |
| `tasting-room-throughput-and-conversion` | `craft-beverage-operations` | Read and lift the tasting-room funnel: visits -> tasting -> purchase -> club sign-up. Find where conversion leaks, tie it to the experience and the club offer rather than raw foot traffic, and weigh tasting room vs e-commerce vs events on contribution. DTC keeps the margin wholesale gives away. |
| `three-tier-and-self-distribution-economics` | `craft-beverage-operations` | Model the go-to-market structure: self-distribution (margin kept, sales/logistics cost, eligibility limits) vs a distributor (reach and depletion, margin given away, franchise-law lock-in), plus the channel margin math (DTC net vs wholesale net after distributor/retailer take). Every TTB/state-licensing/excise specific is jurisdiction-specific — flag and route it. |
| `choose-monetization-mix` | `creator-economy-operations` | Decide which revenue lines a creator should run and in what order — grounded in audience size × engagement × buying-intent, weighted toward recurring revenue and away from single-platform/single-sponsor concentration. Reach for this at the START of monetizing an audience, or when income is volatile/over-concentrated. Driven by creator-business-strategist. |
| `plan-content-and-audience-growth` | `creator-economy-operations` | Plan a creator's content strategy, sustainable cadence, platform growth, and owned-audience funnel: content pillars, a capacity-matched schedule, repurposing one core piece into platform-native cuts, and converting rented reach into an email list/community — measured by engagement + owned conversion, not vanity reach. Driven by content-and-audience-manager. |
| `price-a-brand-deal` | `creator-economy-operations` | Value a sponsorship and build a creator rate card on VALUE, not a flat CPM: audience value + deliverable + usage/exclusivity rights as separate line items + a walk-away number, with rate benchmarks dated + verify-at-use and clear disclosure. Reach for this when a brand makes an offer, or to set standard rates. Driven by creator-business-strategist. |
| `account-expansion-signal-design` | `customer-success-analytics` | Design the signal set and mart model for an account expansion-readiness view alongside the churn-risk tier — identifying which signals predict expansion, how to surface them without confusing the CS team, and what mart additions are needed. Reach for this skill when a CS team wants both a churn-risk view and an expansion-opportunity view from the same health mart. |
| `churn-signal-backtest` | `customer-success-analytics` | Back-test a candidate churn signal or the full tier rule set against historical renewal outcomes to validate predictive strength before the signal enters the production health tier. Reach for this skill when a new signal is proposed, when the tier is misfiring, or after the first full renewal cycle to tune thresholds. |
| `cs-metric-audit` | `customer-success-analytics` | Audit the metrics published on a CS-health dashboard against the mart layer to identify inconsistencies, stale definitions, missing signals, and metrics that bypass the mart. Reach for this skill before a CS analytics rebuild, during a QBR preparation review, or when a CS leader reports that the numbers don't match what they expect. |
| `health-tier-design` | `customer-success-analytics` | Design a transparent, explainable rule-based customer-success health tier (Green/Yellow/Red) from multi-source signals: signal selection, weighting, thresholds, per-signal evidence display, and tuning against actual past churn. Reach for this skill when designing a new health tier, refreshing one that has stopped predicting outcomes, or deciding how a Red account should explain itself. Domain-neutral — generalized from the EdTech partner-health-scoring pattern; no vertical assumptions. |
| `renewal-workflow-design` | `customer-success-analytics` | Design the renewal-risk workflow and save-play triggers from a health tier plus renewal proximity: the risk = proximity × engagement rule, the renewal watchlist surface, the trigger-to-play mapping, the expand/maintain/recover decision, and the who-do-I-call-today actionability bar. Reach for this skill when designing how at-risk renewals surface and what fires when, or when a renewal that should be safe shows no movement. Domain-neutral — generalized from the EdTech renewal-play-design pattern; no vertical assumptions. |
| `design-qa-program` | `customer-support-cx-operations` | Design a statistically meaningful QA sampling program and a tier/escalation model. Reach for this on a quality or routing question. |
| `model-deflection` | `customer-support-cx-operations` | Model self-service/KB deflection and the cost avoided before sizing headcount. Reach for this first on a cost-to-serve question. |
| `project-backlog` | `customer-support-cx-operations` | Read SLA and backlog as arrivals against resolution capacity — project the days-to-clear. Reach for this on a backlog question. |
| `read-satisfaction` | `customer-support-cx-operations` | Read CSAT/NPS segmented by channel/tier/issue-type and tie it to FCR — never a blended score. Reach for this on a satisfaction question. |
| `size-staffing` | `customer-support-cx-operations` | Size agents from workload and a target occupancy band — not a fixed agent:ticket ratio. Reach for this on a staffing question. |
| `evidence-and-audit-readiness` | `cybersecurity-grc` | Set the control-testing cadence, build evidence collection and continuous control monitoring, decide Type I vs Type II readiness, run a gap assessment and manage the auditor PBC list, and own third-party risk — vendor tiering, SIG/CAIQ, shared-responsibility, and ongoing monitoring — so evidence is a system and the audit holds no surprises. |
| `framework-selection-and-control-mapping` | `cybersecurity-grc` | Choose the right security-compliance framework for the org's size/risk/customer demand, scope the audit boundary, crosswalk controls across SOC 2 TSC / ISO 27001 Annex A / NIST CSF 2.0 / 800-53 so one evidenced control attests many, and author a Statement of Applicability whose every exclusion is justified against the risk register. |
| `risk-register-and-assessment` | `cybersecurity-grc` | Build a risk register (assets, threats, likelihood x impact scoring), drive control selection from risk rather than from a framework checklist, choose a treatment per risk (mitigate / accept / transfer / avoid), and track residual risk with a named owner — so every control traces to a risk and every top risk has a control. |
| `access-governance` | `data-governance-privacy` | Design and operate data access governance: define role-based access tiers from the classification scheme, implement column-level masking and row-level security, build an access request and review workflow, and produce an access audit report that proves least-privilege is enforced. |
| `catalog-and-lineage` | `data-governance-privacy` | Build a maintained data catalog: automated sensitive-data/PII discovery and column-level tagging, end-to-end lineage captured from pipeline/dbt metadata, a business glossary tying terms to tables, and surfaced access for governance. |
| `data-classification` | `data-governance-privacy` | Design and apply a usable data classification scheme: a small set of levels (public/internal/confidential/restricted) plus a PII/sensitive flag, handling rules per level, and a mapping to enforceable controls — governing the highest-risk data first. |
| `privacy-mechanics` | `data-governance-privacy` | Engineer privacy: build executable data-subject-rights pipelines (access/erasure/portability) that locate data via the catalog, track lawful basis + granular revocable consent, minimize collection, automate retention/deletion, and distinguish pseudonymization from anonymization. |
| `retention-and-deletion` | `data-governance-privacy` | Design and operate a data retention and deletion programme: classify data by retention period, build automated purge pipelines, verify deletion propagates to all copies including derived and replicated data, and produce evidence for audit — so data does not persist beyond its legal or business justification. |
| `choose-orchestrator` | `data-orchestration` | Pick the right data-pipeline orchestrator for a described workload by traversing the orchestrator-selection decision tree (workload shape → latency → asset-centric vs task-centric → team/ops capacity → cloud lock-in → engine), then return the recommended engine, its scheduling model, its executor/runtime, the trade-offs, and the conditions that would flip the choice. Reach for this when the user asks "Airflow vs Dagster vs Prefect?", "self-host or managed (MWAA/Composer/ADF)?", or "what should run our pipelines?". Used by `orchestration-architect` (primary). |
| `design-dag-and-dependencies` | `data-orchestration` | Design a correct, minimal DAG or software-defined-asset graph for a pipeline — derive the real upstream→downstream edges, pick the partition grain, choose the scheduling/triggering model (cron / sensor-deferrable / data-aware-asset), and decide catchup behavior — then capture it in the DAG design doc. Reach for this when the user says "design the DAG/assets for <pipeline>", "what should depend on what?", or "how should these jobs trigger?". Used by `pipeline-orchestration-engineer` (primary). |
| `handle-backfills-and-retries` | `data-orchestration` | Make pipeline tasks safe to re-run and plan backfills that don't corrupt state — prove idempotency (deterministic partition keys, overwrite-by-partition), then add bounded retries with exponential backoff + jitter, and run a controlled backfill (partition strategy, catchup config, concurrency caps, monitoring, rollback). Reach for this when the user says "our pipeline isn't safe to re-run", "add retries", or "we need to backfill <range>". Used by `pipeline-orchestration-engineer` (primary). |
| `airbyte-cdk-authoring` | `data-platform` | Author a custom Airbyte connector (low-code manifest.yaml vs Python CDK) — monotonic server-set cursor, checkpointed state, bounded-window backfill, Retry-After backoff, idempotent destination write, maintenance posture at design time. Used by connector-developer. NOT for configuring a vendor-shipped Airbyte/Fivetran connector (that's connector-configuration). |
| `cloud-database-comparison` | `data-platform` | Compare cloud databases (Supabase, Neon, RDS, Azure SQL, Fabric, DuckDB, MotherDuck, Snowflake, Databricks, Turso) for an SMB consulting engagement — pricing tables with retrieval dates, setup-complexity matrix, when-to-pick guidance. Used by `database-setup-guide` to recommend a DB choice for a new engagement. |
| `connector-configuration` | `data-platform` | Connector-specific configuration patterns for ELT pipelines — QuickBooks OAuth + rate-limit handling, Stripe webhook + batch hybrid, Salesforce Bulk API 2.0, HubSpot API v3, GA4 BigQuery export, Shopify GraphQL Admin API. Used by `etl-pipeline-engineer` when configuring an Airbyte / Fivetran / n8n connector against a real source. |
| `cross-system-identity-resolution` | `data-platform` | Use when stitching the same real-world entity — a customer account — across multiple source systems into one conformed spine; e.g. Salesforce + Planhat + Intercom + Slack. Operationalizes the deterministic-keys-before-fuzzy best practice: inventory candidate keys, build the precedence ladder, construct bridge_account_xref with confidence + match_method, quarantine unresolved records, run resolution_audit, and gate on stewardship review for low-confidence matches. K-12 LEAID confidence-tier ladder + district-name normalization rules added 2026-06-04. |
| `cube-schema-scaffolding` | `data-platform` | Scaffold Cube semantic-layer schemas with mandatory `securityContext` baked in for multi-tenant customer-facing dashboards. Includes measure/dimension patterns, pre-aggregation hints, view-level partner-facing query surface, and the cross-boundary denial test. Used by `dashboard-builder` on Case-C productized-SaaS engagements. |
| `dashboard-architecture-audit` | `data-platform` | Systematically walk a dashboard page by page and judge whether its structure makes sense, whether it tells a coherent story, and whether it guides the user toward action — for a new build's final gate and for hardening/upgrading an existing dashboard. Invoked by `dashboard-builder` (primary) and directly for a standalone hardening request. |
| `dashboard-performance-tuning` | `data-platform` | Tune interactive-dashboard performance against a per-widget-class budget — Cube pre-aggregation design, Postgres / DuckDB materialized views, cache layers (Cube + Redis + browser TanStack Query), the per-widget profile loop (measure → identify the slow stage → fix at the lowest-cost layer). Reach for this skill when a dashboard exceeds the 1-2s widget target, or proactively before adding a heavy widget. Used by `dashboard-builder` (primary). |
| `data-quality-tests` | `data-platform` | Design data-quality tests that catch real bugs — uniqueness / not-null / referential integrity / freshness / row-count drift / value-range / cross-source reconciliation. dbt-test mechanics for each, severity tiers (error vs warn), the runbook-entry-per-failing-test discipline, and when to escalate to Great Expectations or Monte Carlo / Bigeye. Reach for this skill when launching a new pipeline OR after a "the numbers were wrong" incident. Used by `etl-pipeline-engineer` (primary). |
| `dbt-project-scaffolding` | `data-platform` | Scaffold a dbt project that ships — sources → staging → intermediate → marts → metrics layer discipline, generic + custom tests, doc-blocks for every model, exposure tracking, RLS-safe role separation (build-role vs query-role), CI shape (`dbt build` on PR), and a dev/prod env-promotion shape. Reach for this skill at engagement start (greenfield warehouse) or when a dbt project has decayed into ungoverned models. Used by `etl-pipeline-engineer` (primary) + `dashboard-builder`. |
| `embed-csp-and-iframe-sandboxing` | `data-platform` | Configure CSP `frame-ancestors`, iframe `sandbox` attributes, postMessage origin checks, and web-component shadow-DOM boundaries for embedded dashboards. Invoked by `ravenclaude-core/security-reviewer` when a diff touches embed-auth flow; generated alongside dashboard code by `dashboard-builder`. |
| `jwt-embed-issuance` | `data-platform` | Canonical 2026 JWT-embed flow for dashboard embedding — required claims (`sub`, `tenant_id`, `iat`, `exp`, `iss`, `aud`, `nonce`), tool-specific verification (Superset guest tokens, Metabase JWT URLs, Cube Authorization Bearer, Power BI MSAL-via-AAD), 5-15 min expiration policy, cross-boundary denial test contract. Invoked by `ravenclaude-core/security-reviewer` for any embed-auth review. |
| `multi-tenant-migration` | `data-platform` | Migrate a single-tenant database / dashboard stack to multi-tenant — `tenant_id` column propagation + backfill, RLS / semantic-layer scope rules introduced post-hoc, JWT-claim shape migration, embed-token cutover plan with parallel + backout window, and the mandatory cross-boundary denial test before flipping the switch. Reach for this skill when an engagement shifts from one-client deliverable to productized SaaS. Used by `database-setup-guide` (primary) + `dashboard-builder`. |
| `rls-policy-authoring` | `data-platform` | Author Postgres Row Level Security policies (force-on, CI-deployed, denial-tested) for multi-tenant dashboards. Encodes the closeness-to-data invariant — tenant isolation at the closest-to-data layer the viewer's token cannot influence. Covers Postgres RLS + semantic-layer enforcement (Cube `securityContext`, Power BI DAX roles, Fabric, Snowflake row-access). Invoked by `ravenclaude-core/security-reviewer`. |
| `stack-selection` | `data-platform` | Select a dashboard-engagement stack via the Case A/B/C/D Mermaid decision tree (Portfolio / Per-client / Productized SaaS / Pipes-only) — surfaces the per-viewer-pricing-trap heuristic, recognizes the EdTech LMS connector-gap, returns a populated `stack-decision-record.md`. Invoked by `ravenclaude-core/architect` via inline prior. |
| `support-ticket-normalization` | `data-platform` | Take vendor-specific raw support-ticket tables in the warehouse (Zendesk, Freshdesk, Intercom Conversations + Tickets, SFDC Case, JSM, HubSpot, Help Scout, Front) and produce conformed `fct_ticket` + `fct_conversation_event` models with SFDC Account / Planhat Company bridge resolution. Includes the per-vendor field-mapping table, status / priority / channel conformance maps, escalation-flag derivation rules, SLA-breach derivation, the connector-method decision tree, and the dbt-test shape that guards the join spine. |
| `choose-data-quality-approach` | `data-quality-observability` | Pick the right data-quality approach and tooling for a described stack by traversing the data-quality tooling decision tree (already-on-dbt? → check shape, known-rule vs unknown-over-time → build vs buy → where checks run → tool), then return the recommended contracts/tests/monitors mix, the tool (dbt tests / dbt-expectations / Great Expectations / Soda / Elementary / a managed platform / warehouse-native), where each check runs, the block-vs-warn policy, the SLAs, and the conditions that would flip the choice. Reach for this when the user asks "dbt tests vs Great Expectations vs Soda vs Monte Carlo?", "contracts vs tests vs monitors?", "where should checks run?", or "build vs buy observability?". Used by `data-quality-architect` (primary). |
| `design-data-contracts-and-tests` | `data-quality-observability` | From a dataset and its consumers, derive the producer-boundary data contract (schema, semantics, freshness and volume expectations, ownership) and the concrete validation test suite (not-null, unique, accepted-values, referential integrity, distribution/value-range), each test carrying a severity. Reach for this when the user asks "write the data contract for this table", "what tests should this dataset have?", or "define the guarantees this producer owes its consumers". Used by `data-quality-architect` and `data-quality-engineer`. |
| `set-up-data-observability-monitors` | `data-quality-observability` | Stand up the observability monitors that watch for the unknown over time — freshness, volume, schema-drift, and distribution/anomaly monitors — each anchored to a baseline and a tolerance (not a hard-coded magic number), then wire owner-routed alerting and link a data-incident runbook. Reach for this when the user asks "set up freshness/volume monitors", "alert us before a stakeholder notices bad data", or "detect schema drift and distribution anomalies". Used by `data-quality-engineer` (primary). |
| `eda-workflow` | `data-science-research` | Run a disciplined exploratory pass before anyone models: profile the data (shape, types, missingness, cardinality, distributions), make and document cleaning decisions, visualize distributions and relationships, spot leakage candidates and target-definition problems, generate hypotheses, and communicate findings with their uncertainty. |
| `feature-engineering-and-modeling` | `data-science-research` | Engineer features and fit, select, and honestly evaluate classical models on tabular data: build leakage-aware features, set a baseline, choose between regression / trees / gradient boosting, build a leakage-safe cross-validation harness with every transform fit inside the fold, and pick the metric from the decision and its cost structure. |
| `reproducible-research` | `data-science-research` | Make an analysis re-runnable by anyone: enforce notebook hygiene (top-to-bottom-clean, no out-of-order state), pin environments and dependencies in a lockfile, set and thread random seeds, version data and artifacts, track experiments (params + metrics + code/data version per run), and convert a run-once notebook into a scripted, deterministic pipeline. |
| `cdc-pipeline-setup` | `data-streaming-engineering` | Step-by-step playbook for standing up a Change Data Capture pipeline with Debezium — source connector configuration, slot management, snapshot strategy, and handling common failure modes. |
| `consumer-lag-triage` | `data-streaming-engineering` | Structured triage procedure for diagnosing and resolving Kafka consumer group lag — distinguishes slow consumer, under-partitioned topic, rebalance storm, and broker-side causes. |
| `kafka-platform` | `data-streaming-engineering` | Run the streaming platform reliably: partition for the ordering you need (order is per-partition; the key is the guarantee), govern schemas with a registry + compatibility rules, configure producer durability (acks/idempotence) and consumer offsets/idempotency, and ingest via CDC not dual-writes. |
| `schema-evolution-playbook` | `data-streaming-engineering` | Step-by-step playbook for evolving Avro/Protobuf/JSON Schema event schemas without breaking consumers, covering compatibility modes, migration patterns, and registry operations. |
| `schema-registry-evolution` | `data-streaming-engineering` | Playbook for managing Avro/Protobuf/JSON Schema schemas in a registry — choosing a compatibility mode, executing safe schema changes, and handling breaking changes without consumer downtime. |
| `stream-processing` | `data-streaming-engineering` | Process streams correctly: aggregate on event-time with watermarks (not processing-time), window deliberately (tumbling/sliding/session), handle late data explicitly, checkpoint and TTL-bound state, join with aligned time, and design for backpressure. |
| `streaming-vs-batch` | `data-streaming-engineering` | Decide streaming vs batch honestly by the real latency need (sub-minute reaction -> streaming; hourly/daily -> batch via data-platform), then design the topology, platform choice, and delivery semantics if streaming is justified. |
| `connection-pool-tuning` | `database-engineering` | Playbook for sizing and configuring a database connection pool (PgBouncer or application-level) — calculating the right pool size, choosing the pooling mode, diagnosing pool exhaustion, and avoiding the common over-provisioning trap. |
| `db-reliability` | `database-engineering` | Operate the database reliably: pool connections with sane limits, choose the isolation level deliberately (knowing its anomalies), keep transactions short, route replica reads carefully, and test restores — a backup is only real if you've restored it. |
| `query-and-index-tuning` | `database-engineering` | Tune queries with evidence: read EXPLAIN (ANALYZE, BUFFERS) first, choose the right index type and column order (B-tree/partial/composite/covering/GIN), rewrite to be sargable, kill N+1 at the SQL level, and keep statistics fresh. |
| `relational-schema-design` | `database-engineering` | Design a correct relational schema: normalize to 3NF, denormalize only with measured evidence and a named consistency cost, push constraints (PK/FK/UNIQUE/CHECK/NOT NULL) into the database, and choose precise data types. |
| `safe-schema-migrations` | `database-engineering` | Evolve schemas without downtime: expand/contract (add -> backfill in batches -> switch -> drop) across separate deploys, lock-aware DDL (create indexes CONCURRENTLY, nullable-add-then-validate), reversibility, and ordered versioned migrations. |
| `backup-and-restore-verification` | `database-reliability-engineering` | Design a backup + point-in-time-recovery strategy from RPO/RTO and — critically — the restore-verification that proves it works: cadence, retention, failure-domain isolation, and a scheduled test restore measuring actual restore time. Reach for this when backups are unproven, when setting RPO/RTO, after a near-miss, or before relying on recovery. Pairs with ha-topology-and-failover. |
| `db-incident-triage` | `database-reliability-engineering` | Triage and mitigate a live production database incident — classify latency vs errors vs saturation, rank the suspects (lock contention, replication lag, connection storm, runaway query, disk-full, failover), run the per-mode diagnostic, and apply the least-blast-radius reversible mitigation first. Reach for this when a DB is slow/erroring in prod now. Pairs with zero-downtime-migration when a change caused it. |
| `ha-topology-and-failover` | `database-reliability-engineering` | Design a production database's high-availability topology from its RPO/RTO targets — replica type (sync/async/quorum), failure-domain spread (multi-AZ/region), and the failover mechanism with a split-brain guard. Reach for this when a DB needs to survive an AZ/region outage, when failover has never been designed, or when 'we have a replica' is mistaken for HA. Pairs with backup-and-restore-verification. |
| `zero-downtime-migration` | `database-reliability-engineering` | Plan a schema change on a live production database with no downtime using expand-contract — additive expand, dual-write, batched/throttled backfill, cutover, then contract — with lock duration and replication lag managed. Reach for this before any non-additive change to a hot table (NOT NULL, rename, type change, drop) or a large backfill. Pairs with db-incident-triage if a migration goes wrong. |
| `design-medallion-lakehouse` | `databricks-lakehouse-engineering` | Design a Databricks lakehouse from the query and freshness SLO backward: the medallion layering (what earns bronze/silver/gold), the Delta table & partitioning strategy per layer (low-cardinality partition vs liquid clustering, OPTIMIZE/Z-ORDER/VACUUM cadence, MERGE/CDC vs append/overwrite write pattern), the batch-vs-streaming call (scheduled batch is the default; Auto Loader / Structured Streaming / DLT only for a real sub-hour SLO), the Unity Catalog governance layout (catalog/schema, managed vs external, grants to groups, PII tagging), and the compute + DBU cost envelope. Reach for this when the ask is 'how should we structure this on Databricks?', 'bronze/silver/gold + table layout', 'batch or streaming?', or 'Unity Catalog setup'. Used by `lakehouse-architect` (primary). |
| `tune-spark-and-costs` | `databricks-lakehouse-engineering` | Diagnose a slow or failing Databricks/Spark job from the EVIDENCE (the Spark UI stages/task-skew/shuffle-spill/GC and the query plan) rather than guessing, then apply the fix the evidence points to — AQE skew-join or key salting for a hot key, broadcast for a small-dim join, repartition/coalesce for partition sizing, OPTIMIZE/compaction for the small-file problem, and writing-instead-of-collecting for driver OOM — and bring the DBU cost down (auto-termination, jobs-vs-all-purpose compute, right-sized warehouses, Photon where it pays). Reach for this when the ask is 'this job is slow/spilling/OOMing', 'why is this taking hours?', or 'our Databricks bill is too high'. Used by `databricks-platform-engineer` (primary). |
| `benchmark-overhead` | `dental-practice` | Read overhead as a % of collections against the ~62% median before cutting any single cost, so the diagnosis targets the real driver. Reach for this on a margin problem. |
| `lift-case-acceptance` | `dental-practice` | Raise treatment-plan acceptance through presentation and sequencing rather than discounting. Reach for this when big plans don't close. |
| `manage-the-payer-mix` | `dental-practice` | Read the effective fee by plan and manage PPO write-offs as a deliberate strategy, not an accident. Reach for this when adjustments erode margin. |
| `protect-the-collection-ratio` | `dental-practice` | Read banked-vs-produced dollars and recover the collection ratio toward 98%+, so production becomes income. Reach for this when collections slip. |
| `read-production-per-hour` | `dental-practice` | Read doctor and hygiene production per hour, not per day, to expose the real capacity story. Reach for this on a production question. |
| `component-api-and-library-build` | `design-systems-engineering` | Design and build an accessible, composable library component with a contract-grade public API — deciding composition vs configuration and controlled vs uncontrolled, baking in roles/focus/keyboard from v1, and shipping a story and usage docs. Traverses the component-API branch of the design-systems decision tree. Reach for this when the user asks 'compose or props for this component?', 'build an accessible Menu/Dialog/Combobox', 'controlled or uncontrolled?', or 'what should this component's public API be?'. Used by design-systems-architect (API shape) and design-tokens-and-component-engineer (implementation). |
| `design-system-versioning-and-adoption` | `design-systems-engineering` | Version a component library like the public contract it is (semver + changesets), ship breaking changes with codemods and loud deprecation, and drive adoption with metrics. Traverses the versioning branch of the design-systems decision tree: semver mapping → changesets/release flow → breaking-change/codemod policy → deprecation → adoption metrics. Reach for this when the user asks 'how do we version the library?', 'set up changesets', 'how do we ship this breaking change?', or 'how do we drive adoption / measure it?'. Used by design-systems-architect (policy) and design-tokens-and-component-engineer (release pipeline). |
| `design-token-architecture` | `design-systems-engineering` | Structure design tokens across the primitive → semantic → component tiers, with theming/dark-mode and multi-brand solved as a semantic-tier value swap, then emit the platform outputs consumers use. Traverses the token branch of the design-systems decision tree: source of truth → tier structure → naming → theming → platform outputs. Reach for this when the user asks 'how should our tokens be structured?', 'set up design tokens', 'how do we do dark mode / multi-brand?', or 'primitive vs semantic tokens?'. Used by design-systems-architect (structure) and design-tokens-and-component-engineer (pipeline). |
| `desktop-framework-choice` | `desktop-app-engineering` | Decide Electron vs Tauri vs native vs PWA by the app's real needs (bundle size, native-API depth, team skills, security surface, update needs), then set the process/security model and the renderer/backend boundary. |
| `electron-security-hardening` | `desktop-app-engineering` | Harden an Electron app to the secure baseline — contextIsolation on, nodeIntegration off, sandbox on, a strict CSP, no remote module — and bridge to the OS through a narrow typed contextBridge backed by validated ipcMain handlers. |
| `native-os-integration` | `desktop-app-engineering` | Wire native OS integration the way each platform expects — tray/menu-bar, application menus, notifications, file associations, custom-scheme deep links routed through a single-instance lock, and secrets in the OS credential store. |
| `packaging-signing-and-updates` | `desktop-app-engineering` | Package, code-sign, and notarize a desktop app for Windows (Authenticode/EV) and macOS (Developer ID + notarytool + staple), and ship a safe signed auto-update (signature verified before apply, channels, staged rollout, rollback, version floor). |
| `tauri-capabilities-and-commands` | `desktop-app-engineering` | Expose native capability in Tauri through #[tauri::command] handlers with validated input, authorized by a least-privilege capabilities/permissions allow-list (v2) scoped to the windows that need it — no wildcard fs/shell scopes. |
| `community-health-review` | `developer-relations` | Diagnose a developer community by the metrics that matter — answered-question rate, time-to-first-response, returning contributors, and sentiment — not member or follower count. Use to assess a forum/Discord/Discussions/Stack Overflow presence and design ops that fix unanswered questions. |
| `conference-talk-and-cfp` | `developer-relations` | Shape a conference talk and write a CFP abstract that gets accepted and lands — lead with the attendee takeaway (what they can DO afterward), state concrete takeaways, match the track, and keep it engineer-to-engineer not a product pitch. Use when proposing or preparing a developer-conference talk. |
| `devrel-content-strategy` | `developer-relations` | Choose content formats and a calendar for an activation goal — format follows the goal (getting-started for first success, sample app for the value path, guide for a concept, talk for reach), not the trendy channel. Use when planning DevRel content tied to the activation funnel. |
| `getting-started-audit` | `developer-relations` | Measure and shorten time-to-first-success — walk the getting-started path from a clean state, time it, rank friction points by where developers drop off, and make a fix-or-document call on each. Use whenever you need to know how good (or bad) onboarding really is. |
| `sample-app-design` | `developer-relations` | Spec a sample app or SDK quickstart that demonstrates the real value path as production-grade, runnable code — it runs from a clean checkout, handles errors, pins versions, and has no hardcoded secrets. Use when designing or reviewing sample code that developers will copy verbatim. |
| `choose-monorepo-tooling` | `developer-tooling` | Pick the right monorepo/build tool and package manager for a described repo by traversing the monorepo-tooling decision tree (language mix → scale → hermeticity need → tool), then return the recommended tool, the package-manager pick, the tradeoffs, and an explicit list of what NOT to adopt yet. Reach for this when the user asks 'which monorepo tool?' or 'should we adopt Nx/Turborepo/Bazel?'. Used by `build-systems-architect` (primary). |
| `manage-dependencies` | `developer-tooling` | Set and enforce dependency & package management across a monorepo: version policy (single-version vs independent), lockfile hygiene (commit + freeze in CI), automated batched upgrades (renovate/dependabot), supply-chain hygiene (SBOM, provenance/SLSA, digest pinning), and staged cross-repo upgrades. Reach for this when the user asks 'how do we manage versions/lockfiles?' or 'upgrade X safely across the monorepo'. Used by `monorepo-engineer` (primary). |
| `optimize-build-and-cache` | `developer-tooling` | Diagnose and fix a slow build by measuring the task graph and cache-hit rate, auditing cache CORRECTNESS (input-hash completeness, hermeticity leaks) before any speed tuning, then applying the highest-leverage fix (affected-only, remote cache, parallelism, splitting the long pole). Reach for this when the user says 'the build is slow' or 'is remote caching worth it / even correct?'. Used by `build-systems-architect` (primary). |
| `ci-pipeline-design` | `devops-cicd` | Design a fast, deterministic CI pipeline: stage ordering by cost, dependency/build caching keyed on the lockfile, build matrices and test sharding, required-check contracts for branch protection, and SHA-pinned third-party actions. |
| `gitops-delivery` | `devops-cicd` | Stand up GitOps continuous delivery with Argo CD or Flux: desired-state-in-Git repo structure (app-of-apps, environment overlays), promotion-by-PR, drift detection/self-heal posture, and secrets without plaintext. |
| `progressive-delivery` | `devops-cicd` | Choose and wire a progressive-delivery strategy — blue-green, canary, rolling, or feature-flagged — by blast radius and reversibility, with a health-gated promotion and an automated, rehearsed rollback. |
| `secrets-rotation-and-management` | `devops-cicd` | Playbook for managing secrets across the CI/CD pipeline — vaulting, injection at runtime, automated rotation, and the emergency response procedure when a secret is compromised — so long-lived credentials never live in pipeline definitions, env files, or Git. |
| `supply-chain-integrity` | `devops-cicd` | Produce trustworthy artifacts: reproducible/deterministic builds, minimal non-root container images, SemVer + immutable digests, build-time SBOM (CycloneDX/SPDX), and SLSA provenance + signing for verifiable supply-chain integrity. |
| `choose-digital-twin-architecture` | `digital-twin-engineering` | Scope and architect a digital twin for a described asset and decision by traversing the digital-twin architecture decision tree (decision it informs → twin type → shadow-vs-bidirectional → descriptive/predictive/prescriptive → modeling approach → fidelity → sync → platform), then return the twin scope/type, the fidelity level (only as much as the decision needs), the modeling approach (physics vs data-driven/surrogate/reduced-order vs hybrid), the platform (DTDL+Azure Digital Twins / AAS / Eclipse Ditto / Omniverse / Unity-Unreal / Bentley-Siemens), the state-sync strategy, and the conditions that would flip the choice. Reach for this when the user asks "we want a twin of <X> — where do we start?", "physics vs data-driven vs hybrid?", "how much fidelity?", "which twin platform?", or "shadow or bidirectional?". Used by `digital-twin-architect` (primary). |
| `design-twin-data-and-sync-model` | `digital-twin-engineering` | From a physical asset and its telemetry, derive the twin's data and synchronization model — the signal list and sampling rates, the transport protocol (MQTT / OPC-UA / Kafka), the edge-vs-cloud split, the sync-latency budget the decision tolerates, the binding of each signal to the twin's model properties (DTDL properties / AAS submodel elements), and the drift-detection + recalibration policy. Reach for this when the user asks "what data does this twin need and how often?", "map our sensor stream to the twin model", or "how fresh must the twin be?". Used by `twin-integration-engineer` and `digital-twin-architect`. |
| `implement-twin-integration-and-simulation` | `digital-twin-engineering` | Build a digital twin end to end — ingest the telemetry (MQTT / OPC-UA / Kafka, edge-vs-cloud) and bind it to the model (DTDL properties / AAS submodels), wire the physics or reduced-order/surrogate model, run simulation and what-if scenarios against live twin state, stand up 3D or dashboard visualization where it earns its keep, and — the step teams skip — validate fidelity against the real asset (predicted-vs-actual SLIs, error bounds, calibration) plus a drift monitor. Reach for this when the user asks "ingest our stream into the twin", "run a what-if simulation", "does the twin match the asset?", or "the twin has drifted". Used by `twin-integration-engineer` (primary). |
| `build-the-retention-engine` | `ecommerce-dtc` | Read cohort retention and the repeat rate and build the second-purchase engine, since retention compounds LTV. Reach for this when growth depends on acquisition alone. |
| `cost-the-returns` | `ecommerce-dtc` | Read return rate and its full cost as a contribution-margin line, so a high-return category isn't mistaken for a winner. Reach for this on a margin question. |
| `diagnose-the-funnel` | `ecommerce-dtc` | Locate a conversion problem by funnel stage — traffic, product page, cart, checkout — instead of reading the headline rate. Reach for this when conversion is low. |
| `manage-cac-by-channel` | `ecommerce-dtc` | Read CAC by channel and cohort and allocate budget to efficiency, instead of a blended number. Reach for this when CAC climbs. |
| `read-ltv-cac` | `ecommerce-dtc` | Read LTV:CAC against the 3:1 line and contribution margin after the real costs, so a profitability problem is diagnosed correctly. Reach for this on any growth/profit question. |
| `adoption-sequencing-k12` | `edtech-partner-success` | Sequence K-12 partner adoption activities by stage (newly-implemented / first-year-sustaining / multi-year-mature / pre-renewal) with school-year-phase overlay. Surface-by-surface rhythm (teacher / admin / student / family-facing). Diagnostic-before-intervention discipline — don't push feature-breadth in stage 1. Used by `learning-analytics-analyst` + `success-playbook-designer`. |
| `advocacy-program-design` | `edtech-partner-success` | Design a structured EdTech advocacy program with 5-tier ladder (logo → quote → case study → speaker → peer call). Health-score eligibility gate (top-quartile only), 2-asks-per-year ceiling, state-by-state anonymization overlay (CA/NY/IL stricter; TX/FL more permissive), FERPA consent for student/parent quotes. Used by `success-playbook-designer` + `ferpa-comms-translator` + `edtech-partner-success-manager`. |
| `cs-platform-integration` | `edtech-partner-success` | The back-end integration contract for a centralized EdTech customer success dashboard sitting on top of Planhat (CS platform) + Salesforce (CRM) + Snowflake (warehouse / product usage) + Zapier (glue) + Granola (AI meeting notes, stubbed). Documents what each system contributes to the dashboard's `bi-report/data.json` shape, the sync-freshness thresholds that drive the source-freshness banner, the identity spine that joins records across systems, and the Granola-into-Planhat flow (currently a documented placeholder). Used by `learning-analytics-analyst` (primary), `edtech-partner-success-manager` (touchpoint and pickup-brief fields), `qbr-composer` (data-pull plan). FERPA / student PII routes through `ravenclaude-core/security-reviewer` (mandatory). |
| `daily-action-queue` | `edtech-partner-success` | Compute "today's top N accounts" for a K-12 EdTech PSM as a ranked list with next-best-action + confidence + rationale. Weighted-signal formula (lifecycle-aware), with RICE / ICE as alternate framings. Every action carries an explicit rationale string naming the dominant signal + the threshold crossed + the prescribed play. Designed so the PSM can answer "why this account today?" in one sentence. |
| `executive-sponsor-mapping` | `edtech-partner-success` | Map the partner's buying committee — economic buyer, champion, technical buyer / IT, user-champion, blocker, executive sponsor — across segments (K-12 / higher-ed / corp L&D). Includes the multi-thread coverage gap visualization, the "ghost sponsor" detection pattern, sponsor-change protocols, and integration with the durable partner profile. Reach for this skill on a new-partner kick-off, before a renewal, when a critical contact leaves, or when QBRs are well-attended but decisions aren't happening. Used by `partner-profile-curator` (primary) + `edtech-partner-success-manager`. |
| `expansion-play-design` | `edtech-partner-success` | Design expansion motions that fire only when the partner has earned value — 3-gate eligibility (top-quartile health + demonstrable adoption + organizational readiness), value-trigger taxonomy, seat / module / department land-and-expand patterns, internal-champion-armament, ROI-storytelling format, and the "don't sell to bottom-quartile" discipline. Segment overlays for K-12 / higher-ed / corp L&D. Reach for this skill when designing the firm's expansion playbook or when the partner-success leader is being pushed to monetize too hard. Used by `success-playbook-designer` (primary). |
| `ferpa-comms-translation` | `edtech-partner-success` | Reshape a partner communication into a FERPA-safe, audience-appropriate message — classify the data bucket, screen the small-cohort residual, reshape per audience, treat each language as a redesign. Used by ferpa-comms-translator and by any PSM drafting parent/admin/leadership copy. NOT advocacy quotes (that's advocacy-program-design) and NOT a legal opinion. |
| `health-report-dashboard` | `edtech-partner-success` | Build a self-contained, Power-BI/Tableau-style HTML portfolio report from partner-health data — KPI cards (NRR/GRR/avg-health/red-count/renewal-risk), a health-band donut, a 12-week trend line, a peer-cohort range chart, score-component drill-downs, red-flag surfacing, and a sortable/filterable per-partner table. Used by `learning-analytics-analyst` (primary) + `edtech-partner-success-manager`. Ships with a ready-to-open demo (sample data) AND regenerates from real data — replace `bi-report/data.json` (same shape) and re-run the generator. Invoke when someone asks for a partner-health dashboard, a "report I can show leadership", a QBR data view, or "how's my whole book doing in one picture". |
| `implementation-90-day-arc` | `edtech-partner-success` | Run the 90-day technical-onboarding arc for a newly-contracted EdTech partner — discovery (weeks 1-2) → integration setup (3-4) → train-the-trainer (5-6) → go-live + Day-30 measurement (7-8) → stabilization + PSM handoff (9-12). Calendar-dead-zone go-live check is the highest-leverage pre-flight. Used by `edtech-partner-success-manager` + `learning-analytics-analyst`. |
| `partner-health-scoring` | `edtech-partner-success` | Design and maintain a partner health score that actually predicts renewal / churn for EdTech partners. Signal selection, weighting, half-life / decay, red-flag triggers, and threshold-to-play mapping. Reach for this skill when designing a new score, refreshing one that's stopped predicting outcomes, or interpreting a score move. |
| `partner-training-program-design` | `edtech-partner-success` | Design partner-facing training programs for EdTech — train-the-trainer is the only model that scales in K-12. K-12 PD modality decision rule (live-in-person / live-virtual / hybrid / async-with-followup), PD-credit alignment with state frameworks, teacher-union overlay in unionized states. Used by `ravenclaude-core/documentarian` + `edtech-partner-success-manager` + `success-playbook-designer`. |
| `psm-dashboard-build` | `edtech-partner-success` | Codex's master roadmap for executing the Partner Success Command Center build. Invoke FIRST when asked to build any tier of the PSM dashboard. Identifies which tier to execute, names the read-list, codifies the anti-pattern catalog from /tmp/research-codex-failure-modes.md, and provides the wall-handling + verification rituals. |
| `qbr-composition` | `edtech-partner-success` | Compose a Quarterly Business Review end-to-end — data pull plan, narrative arc, deck outline, talk track, post-QBR commitment tracker. Reach for this skill 1–2 weeks before a QBR is scheduled, OR after a QBR to convert in-meeting promises into a tracked plan. |
| `recovery-play-design` | `edtech-partner-success` | Design red-flag intervention sequences — root-cause diagnostic before remedy (4 parallel hypotheses), time-bound recovery plan with measurable 30/60/90-day signal targets, escalation criteria (PSM → success leadership → exec sponsor → counsel → churn-prep), the "is this recoverable?" rule, churn-prep workflow when not, and the post-recovery learning capture. Reach for this skill when a partner trips red on the health score, when a renewal is at clear risk, or when a partner has signaled dissatisfaction. Used by `success-playbook-designer` (primary) + `edtech-partner-success-manager`. |
| `renewal-play-design` | `edtech-partner-success` | Design renewal motions that earn the renewal instead of negotiating it — T-180/T-120/T-90/T-60/T-30/T-0 sequence, sponsor-confirmation arc, value-evidence pack, multi-thread the buying committee, decision-memo support, expand/maintain/contract decision rule, and segment-specific overlays (K-12 budget cycle, higher-ed academic calendar, corp L&D fiscal year). Reach for this skill 120-90 days before a renewal date, when a renewal "should be safe" but no movement has happened, or when designing the firm's renewal playbook. Used by `success-playbook-designer` (primary) + `edtech-partner-success-manager`. |
| `rostering-data-quality` | `edtech-partner-success` | Diagnose rostering / SIS / LMS data-sync issues in EdTech contexts — K-12 (Clever, ClassLink, OneRoster), higher-ed (SIS/LMS), corporate L&D (HRIS/LMS). When to escalate to product vs coach the partner's admin. Reach for this skill when a partner says "the data isn't right" or when partner-engagement metrics drop without an obvious user-side cause. |
| `success-plan-authoring` | `edtech-partner-success` | Author a 30/60/90 day or quarterly success plan for an EdTech partner that has measurable success criteria, named owners, and a defensible cadence. Reach for this skill when onboarding a new partner OR when refreshing a quarterly plan after a renewal / midyear review. |
| `bounce-complaint-suppression` | `email-engineering` | Close the email feedback loop — classify hard vs soft bounces and spam complaints, enforce a suppression check before every send, and reconcile the ESP's suppression list with your own so you never re-send to a bad address. Reach for this when the user says "we keep emailing bounced addresses", "handle complaints", or "build a suppression list". Used by `email-sending-engineer` (primary). |
| `deliverability-audit` | `email-engineering` | Diagnose why mail is landing in spam (or pre-flight a domain before a big send) by traversing the deliverability triage tree — authentication, DMARC alignment, reputation/warm-up, list hygiene, content, and bulk-sender compliance — then return the specific failing layer, the fix, and how to confirm it from postmaster/RUA signals. Reach for this when the user says "why are we going to spam?", "audit our deliverability", or "are we Gmail/Yahoo compliant?". Used by `email-deliverability-architect` (primary). |
| `email-authentication-setup` | `email-engineering` | Stand up SPF, DKIM, and DMARC (and optionally BIMI) for a sending domain and reach enforcement safely. Traverse the authentication decision tree (authenticate -> align -> enforce), emit the exact DNS records, and stage a p=none -> quarantine -> reject rollout gated on aggregate-report evidence. Reach for this when the user says "set up SPF/DKIM/DMARC", "get to DMARC enforcement", or "pass Gmail's sender rules". Used by `email-deliverability-architect` (primary). |
| `email-template-engineering` | `email-engineering` | Build responsive HTML email templates that render across clients (Outlook/Word engine, Gmail clipping, Apple Mail dark mode) using MJML or table-based HTML, with a plain-text part, accessible markup, and the client-quirk guards. Reach for this when the user says "build a <type> email", "my email looks broken in Outlook", or "make this email responsive / dark-mode safe". Used by `email-sending-engineer` (primary). |
| `transactional-email-integration` | `email-engineering` | Integrate an Email Service Provider (SES, SendGrid, Postmark, Resend, Mailgun) for transactional sending with idempotent sends, signature-verified and idempotent webhook event handling (delivered/bounce/complaint/open), and retry/rate-limit discipline. Reach for this when the user says "wire up <ESP>", "send receipts/password resets", or "handle delivery webhooks". Used by `email-sending-engineer` (primary). |
| `budget-memory` | `embedded-iot-engineering` | Track flash and RAM (image, static, worst-case stack/heap) against the part's limits. Reach for this on any memory or footprint question. |
| `build-power-budget` | `embedded-iot-engineering` | Build the duty-cycled current profile and compute average current and battery life. Reach for this on any battery-life or energy question. |
| `plan-ota` | `embedded-iot-engineering` | Design a dual-bank OTA scheme with signed images and automatic rollback before fielding. Reach for this before any device ships. |
| `select-protocol` | `embedded-iot-engineering` | Select the radio on the power/range/bandwidth/cost trade — don't default to Wi-Fi. Reach for this on a connectivity question. |
| `verify-real-time` | `embedded-iot-engineering` | Characterize WCET and ISR latency and verify the schedule holds under worst case. Reach for this on any timing or determinism question. |
| `decide-tech-debt` | `engineering-management` | Decide whether to pay down a specific tech-debt by sizing its carrying cost and payback against the roadmap — not all-or-nothing. Reach for this before a 'we must stop and refactor' or 'we never have time' reflex. |
| `design-hiring-loop` | `engineering-management` | Design a structured hiring loop — rubric, consistent questions, evidence-based scoring, a debrief that surfaces dissent — over a vibe-based one. Reach for this before scheduling interviews. |
| `improve-team-flow` | `engineering-management` | Diagnose why delivery is unpredictable using flow + DORA as system signals, find the constraint, and fix it — never by velocity-quota'ing people. Reach for this when dates keep slipping. |
| `run-one-on-one` | `engineering-management` | Run a 1:1 that serves the engineer — agenda from them, growth thread, blockers surfaced — not your status update. Reach for this before defaulting to a status read. |
| `write-performance-review` | `engineering-management` | Draft a performance review from dated, observable behavior with impact — specific, bias-checked, growth-oriented. A draft for a human to own, never a verdict. |
| `disclosure-and-assurance-readiness` | `esg-sustainability-reporting` | Draft the sustainability disclosure with its evidence trail, build the data controls, assess readiness for the target assurance level (limited vs reasonable), run a gap assessment against what an assurer will test, strip greenwashing, and prepare the auditor-liaison pack. |
| `framework-selection-and-materiality` | `esg-sustainability-reporting` | Select the applicable sustainability-reporting framework(s) and scope the disclosure: determine which standards apply (CSRD/ESRS, ISSB IFRS S1/S2, GRI, SEC), run the right materiality test (double vs financial), fix the reporting boundary and governance, and crosswalk overlapping frameworks into one roadmap. |
| `ghg-inventory` | `esg-sustainability-reporting` | Build a GHG Protocol inventory: Scopes 1/2/3 and the 15 Scope-3 categories, activity data and emission-factor sourcing with vintage, location-based vs market-based Scope 2, base-year setting and recalculation, the consolidation boundary, and data-quality tiering — every figure traceable and assurable. |
| `build-run-of-show` | `event-management` | Build a minute-by-minute run-of-show / show-flow: a timed table with a row per segment — time, duration, what happens, the cue, and a named owner/role — plus the contingency plan-Bs for the day-of. |
| `design-event-plan-and-budget` | `event-management` | Design the event plan and budget: goal/KPIs, format (in-person/virtual/hybrid), audience, a budget with a named contingency line, the break-even point in registrations/sponsorship, and the dated go/no-go gate. |
| `post-event-measurement` | `event-management` | Post-event measurement: compute ROI against the goal/KPIs set up front (revenue/pipeline, cost per attendee, sponsor renewal, NPS) — not vanity attendance — and run the debrief while it is fresh so lessons feed the next event. |
| `registration-and-attendee-ops` | `event-management` | Registration and attendee operations: model the funnel (reach -> visit -> register -> confirm -> attend) not a headcount, then run check-in as a throughput operation — lanes, staffing, badge/QR flow sized for peak arrival with a system-down fallback. |
| `sponsorship-and-revenue` | `event-management` | Sponsorship and revenue: define tiers by delivered value, build the prospectus, sell against value not logos, and fulfill every promise (placement, leads, speaking slot) with a checklist and proof of delivery so sponsors renew. |
| `ab-test-plumbing` | `experimentation-growth-engineering` | Build trustworthy A/B-test plumbing: deterministic sticky assignment, exposure logging (who actually saw the variant), Sample-Ratio-Mismatch checks before reading results, pre-registered metric/MDE/duration, and guardrail metrics — leaving significance to applied-statistics. |
| `event-instrumentation` | `experimentation-growth-engineering` | Instrument trustworthy product analytics: a tracking plan first, a consistent typed event/property schema (object_action naming, versioned), identity stitching (anonymous -> known), CDP routing (instrument once), and event-quality validation as code. |
| `feature-flags` | `experimentation-growth-engineering` | Use feature flags safely: match the flag type to its purpose (release/experiment/ops/permission), give every risky change a kill switch, roll out progressively gated by a health signal, evaluate deterministically and fail-safe, and manage the flag lifecycle to prevent debt. |
| `srm-detection` | `experimentation-growth-engineering` | Procedure for detecting and diagnosing Sample-Ratio Mismatch in A/B experiments — covers the chi-squared test, common causes by layer, and the decision rule for whether to trust or discard a result. |
| `tracking-plan-design` | `experimentation-growth-engineering` | Step-by-step guide for designing a product analytics tracking plan — event taxonomy, property schema conventions, identity stitching strategy, and the governance process to keep the plan as the source of truth. |
| `dispatch-and-scheduling` | `field-service-management` | Design and optimize a field-service dispatch board — priority queue logic by SLA tier, skill-match routing, geographic density optimization, emergency vs. planned time-block allocation, and day-of-dispatch escalation protocols. |
| `technician-productivity-and-first-time-fix` | `field-service-management` | Diagnose and improve technician utilization, first-time-fix rate, MTTR, and callback rate — including root-cause segmentation by parts/skill/information/diagnosis, the utilization waterfall, and the coaching framework to address each failure category. |
| `truck-stock-and-parts` | `field-service-management` | Design, rationalize, and optimize truck-stock for field-service technicians — tier the parts list by usage frequency and service-level impact, set reorder points, model the first-time-fix ↔ carrying-cost tradeoff, and analyze parts-delay failures and returns. |
| `build-the-top-sheet` | `film-video-production` | Build the budget bottom-up to a top-sheet with a risk-sized contingency, so the number is defensible. Reach for this on any budget question. |
| `define-the-deliverables` | `film-video-production` | Define the delivery spec (formats, masters, captions, QC) first, since it's the actual product. Reach for this before pricing or finishing. |
| `schedule-the-shoot` | `film-video-production` | Schedule to shoot days, locations, and cast availability with company moves and turnaround, not the calendar. Reach for this on a scheduling question. |
| `sequence-the-post-pipeline` | `film-video-production` | Sequence post as a dependency chain keyed off picture lock, so the delivery date rests on the critical path. Reach for this on a post plan. |
| `track-cost-vs-bid` | `film-video-production` | Track cost against the bid line by line and watch contingency burn, so overage is managed not discovered. Reach for this during production. |
| `author-coa-mapping` | `finance` | Author and validate the per-entity chart-of-accounts → statement-line mapping — the bespoke, judgment-laden asset that makes the close reusable per company and where mis-statements hide. Coverage-checked with statement_engine.py --lint-map. Used by `controller`. |
| `board-pack-composition` | `finance` | Compose narrative-first board / investor / lender reporting packs — section sequencing, KPI selection, executive-summary patterns. Numbers don't ship without commentary. Used by `board-pack-composer` (primary). |
| `close-approval-workflow` | `finance` | The governed review→approve→lock state machine with enforced segregation of duties and an append-only hash-chained audit log. Refuses same-actor approval above threshold and illegal transitions. Runs scripts/close_state.py. Honest tier caveats. Used by `controller` + `audit-prep-specialist`. |
| `close-schedules` | `finance` | Produce the recurring close supporting schedules — fixed-asset depreciation rollforward, prepaid amortization, and deferred-revenue waterfall — from summarized inputs, each self-checking so beginning + movements == ending (and NBV = cost − accumulated depreciation) to the cent. Straight-line, blocks (--strict) on a schedule that does not tie. Runs scripts/schedule_engine.py. Used by `controller`. |
| `consolidate-entities` | `finance` | Roll up N entity trial balances (same period) into a group consolidation — reuses statement_engine per entity, then applies a BALANCED intercompany-elimination journal so IC receivable/payable and IC revenue/COGS net to zero, emits an entity-columns + eliminations + consolidated worksheet, and flags (does not remeasure) non-functional-currency entities for CTA. Runs scripts/consolidate.py. 'Eliminate before you consolidate.' Used by `controller`. |
| `dcf-valuation` | `finance` | Run a defensible discounted-cash-flow valuation — explicit projection period, terminal value (Gordon vs exit-multiple), WACC build, sensitivities, scenario weighting, and the cross-check against trading / precedent multiples. Reach for this skill on any valuation work (pre-investment, 409A, fairness opinion, M&A) where a number has to survive board / counterparty scrutiny. Used by `valuation-analyst` (primary) and `financial-modeler`. |
| `driver-based-forecasting` | `finance` | Build and refresh a driver-based rolling forecast that survives FP&A review — driver tree from revenue volume × price, opex by category-driver, working-capital roll, capex schedule, scenario layer. Reach for this skill when standing up a new forecast model, refreshing the annual plan, or when an executive asks "what would it take to hit X?" Used by `fpa-analyst` (primary), `financial-modeler`, and `board-pack-composer` for the forecast slides. |
| `finance-elt-staging` | `finance` | Normalize a raw accounting-system trial-balance export (QuickBooks Online / NetSuite / Xero / Sage Intacct) into the ONE canonical staging schema — account,description,debit,credit,entity,period,currency — that the close autopilot consumes, via a data-driven per-source column-map. Stamps entity/currency dimensions + a close-period watermark, blocks on an unbalanced export, writes atomically. Runs scripts/tb_stage.py. Used by `controller`. |
| `idp-segregation` | `finance` | IdP-backed segregation of duties for the close. Evolves close_state.py's config-asserted --actor string into an optionally IdP-VERIFIED identity via scripts/close_identity.py: an IdentityAdapter seam, split OIDC claim-validation + signature-verification (HS256 stdlib; RS256/JWKS via optional PyJWT, refuse-loudly if absent; alg:none + alg-confusion rejected per RFC 8725), SoD keyed on sub@iss + role claims, and a fresh step-up token to LOCK. Honest boundary: the plugin enforces the CHECK; the consumer IdP must segregate role assignment and hold key/WORM off-box. Used by `controller` + `audit-prep-specialist`; every token-validation change routes through `security-reviewer`. |
| `kpi-definition` | `finance` | Define KPIs that survive cross-team disagreement — single owner, single formula, single source of truth, decay-tested, documented in a KPI dictionary. Reach for this skill when launching a new metric, when two teams cite different numbers for "the same" KPI, when an exec asks "why doesn't this tie?", or when standing up a KPI pack. Used by `fpa-analyst` (primary) and `board-pack-composer`. |
| `live-connectors` | `finance` | Wire a live GL/accounting-system OAuth2 extractor (QuickBooks Online / NetSuite / Sage Intacct / Xero) that feeds the canonical trial-balance staging seam, using the reference-implementation token client in scripts/connectors/ — atomic persist-then-use rotating refresh, per-entity lock, error-cause routing (401 refresh / 429 backoff / invalid_grant re-auth), Xero 30-min grace — plus drill-through GL lineage that feeds statement_engine --gl-detail unchanged. Reference impl + record/replay harness; NOT live-verified. Used by `controller`. |
| `model-review` | `finance` | 7-pass review of financial models — assumptions, mechanics, integrity (BS balances, CF reconciles), hardcodes, error-checks, scenarios, documentation. Used by `financial-modeler` (primary) and `valuation-analyst` for DCF integrity checks. |
| `month-end-close` | `finance` | Run a clean month-end / quarter-end close — close-calendar mechanics, JE buckets, reconciliation checklist, exception-triage playbook. Reconciliation before commentary; materiality as a design constraint. Used by `controller` (primary). |
| `multi-currency-translation` | `finance` | Translate/remeasure ONE entity's functional-currency trial balance into a presentation-currency (USD) TB before consolidate.py, via scripts/remeasure.py. Current-rate method (A&L @ closing, P&L @ average, equity @ historical; plug = CTA to OCI/equity) or temporal method (monetary @ closing, non-monetary @ historical, P&L @ average except REV_EXP_HIST @ historical; plug = remeasurement G/L to net income). Reuses statement_engine's section-signed presentation + reasoning trail — no new sign logic. Blocks on a missing/invalid rate_class, blocks when the balancing plug fails the analytical CTA self-check, and refuses a highly_inflationary + current_rate combo (ASC 830 vs IAS 29). Decision-support, not an audited remeasurement. Used by `controller`. |
| `netsuite-close` | `finance` | Wire NetSuite as a controller-autopilot source: OAuth2 M2M (cert-signed JWT, no refresh token) or time-boxed TBA fallback, a SuiteQL BS-cumulative/IS-period trial balance, tie-out, changed-after-sign-off drift check. Reference impl. Used by `controller`. |
| `per-entity-dashboard` | `finance` | Render a close-package JSON (controller_cycle.py --out-json) into a self-contained, CSP-safe, theme-aware per-entity dashboard — headline KPIs (revenue, net income, gross margin, current ratio, DSO), IS/BS summaries, reconciliation exceptions, top flux, and close-state + traceability/self-certified badges. Runs scripts/entity_dashboard.py. Used by `controller`. |
| `produce-gaap-statements` | `finance` | Turn a reconciled trial balance + a COA mapping into an income statement, balance sheet, and draft cash flow — classification-tested (blocks on unmapped accounts, catches mis-mapping that a balance-check cannot) with an honest traceability badge. Runs scripts/statement_engine.py. Used by `controller`. |
| `reconciliation-automatch` | `finance` | Auto-match GL journal lines to sub-ledger / bank lines (exact, tolerance, and many-to-one grouped) and AUTO-CERTIFY an account only when its unexplained residual is within materiality — else FLAG for a human. The auto-match engine reconcile_summary.py's static tie-out lacked. Runs scripts/recon_match.py. Used by `controller`. |
| `reconciliation-summary` | `finance` | Balance-sheet tie-out (book vs sub-ledger, review-by-exception at materiality) plus a materiality-suppressed period-over-period flux table. Runs scripts/reconcile_summary.py; narrative 'why' reuses the variance-commentary skill. Used by `controller`. |
| `soc-control-walkthrough` | `finance` | Document a SOC 1 / SOC 2 control walkthrough — control description, test of design vs test of operating effectiveness, evidence-of-control patterns, sampling, exception triage, deficiency severity classification (control deficiency / significant deficiency / material weakness). Reach for this skill during pre-audit prep, when documenting a new control for the next SOC cycle, or when responding to an auditor's walkthrough request. Used by `audit-prep-specialist` (primary). |
| `thirteen-week-cash-forecast` | `finance` | Build and operate a 13-week direct-method cash forecast — receipts by source, disbursements by category, week-by-week roll, variance-to-prior-forecast cadence, covenant headroom view, and the trigger thresholds for management action. Reach for this skill when a business is cash-tight, in workout, lender-monitored, or post-fundraise discipline-building. Used by `treasury-analyst` (primary) and `fpa-analyst` for the longer-range bridge. |
| `variance-commentary` | `finance` | Write variance commentary that tells a story instead of restating a table — templates for revenue, GM, opex, EBITDA, FCF with named drivers + materiality threshold applied. Source-cite every number. Used by `fpa-analyst` (primary) + `board-pack-composer`. |
| `warehouse-dashboard` | `finance` | Turn per-entity close packages into a recurring, warehouse-backed, MULTI-TENANT controller dashboard where one controller sees only their PORTFOLIO of entities. Flattens close packages into fact/dim rows (scripts/close_package_to_rows.py, KPI parity with entity_dashboard.derive_kpis), resolves an allowed_entities[] array claim deny-all-by-default (scripts/entity_rls.py), and ships reference dbt marts + a Cube access_policy + Postgres FORCE-RLS. REUSES data-platform for the security surface. Used by `controller` + `board-pack-composer`. |
| `forecast-and-alert` | `finops-cloud-cost` | Forecast spend and set anomaly thresholds so cost is managed, not a monthly surprise. Reach for this on a budget/anomaly question. |
| `harvest-waste` | `finops-cloud-cost` | Inventory idle/orphaned/oversized/zombie resources and rank the pure-savings wins. Reach for this first on any cost spike. |
| `measure-allocation` | `finops-cloud-cost` | Read allocation coverage as tagged ÷ total, size the ungoverned pile, and design showback. Reach for this on an allocation question. |
| `plan-commitments` | `finops-cloud-cost` | Model RI/Savings-Plan coverage on the rightsized baseline, balancing discount vs utilization risk. Reach for this on a commitment question. |
| `read-unit-economics` | `finops-cloud-cost` | Compute cost per customer/transaction/feature and read the trend, not the gross bill. Reach for this on a scaling-health question. |
| `payment-flow-architecture` | `fintech-payments-engineering` | Architect money-safe payments: represent money as integer minor units + currency (never floats), keep a double-entry append-only ledger as source of truth (the PSP is an integration you reconcile against), design a money-event model, and reconcile continuously. |
| `payment-reconciliation` | `fintech-payments-engineering` | Step-by-step playbook for reconciling your internal double-entry ledger against the PSP's payout and transaction reports — identifying discrepancies, classifying them, and closing the books with confidence. |
| `pci-scope-minimization` | `fintech-payments-engineering` | Minimize PCI-DSS scope (engineering posture): use PSP client-side tokenization so the raw PAN never touches your servers (SAQ-A), reduce scope ruthlessly, log money operations for audit without ever logging card data, and route attestation/regulation/verdict out. |
| `psp-integration` | `fintech-payments-engineering` | Integrate a PSP correctly: idempotency key on every money operation (charge/refund/payout), verify webhook signatures and handle them idempotently + out-of-order, model the charge state machine explicitly, and handle 3DS/SCA and hard-vs-soft declines. |
| `subscription-billing` | `fintech-payments-engineering` | Build subscription/usage billing: model plans and prorate mid-cycle changes correctly, meter usage idempotently, run a reliable recoverable billing-cycle job, recover failed payments with smart dunning, and emit clean revenue events for finance. |
| `ancillary-revenue-mix` | `fitness-studio-gym-operations` | Grow the margin dues can't reach: personal training, small-group/semi-private, retail, and café/juice-bar revenue per member. Read revenue-per-member and contribution margin by line, and sequence ancillary growth on the retained base. Attach and margin benchmarks are verify-at-use. |
| `class-schedule-and-instructor-utilization` | `fitness-studio-gym-operations` | Build and read a fitness class grid: fill rate by slot and class type, the per-class break-even headcount from instructor pay plus room cost, instructor utilization, and the no-show/waitlist mechanics that reclaim held seats. Fill and instructor-pay benchmarks are verify-at-use. |
| `member-onboarding-and-retention` | `fitness-studio-gym-operations` | Build the first-30-days onboarding and the attendance-signal early-warning system that keep members: first-visit-at-signup, an early-frequency target, a check-in cadence, and a churn-save flow that matches the offer to the cancel cause instead of reflex-discounting. Retention benchmarks are verify-at-use. |
| `membership-growth-and-churn` | `fitness-studio-gym-operations` | Read a fitness membership base as a subscription business: net member movement (joins minus churn), the retention/survival curve, member LTV = ARPU / churn, and the leaky-bucket diagnosis that tells you whether to fix acquisition or retention first. Churn/LTV benchmarks are verify-at-use. |
| `build-cost-per-mile` | `fleet-logistics` | Build CPM from fixed and variable components, isolating fuel and the non-fuel marginal, so the cost is visible where it lives. Reach for this on any margin question. |
| `manage-the-operating-ratio` | `fleet-logistics` | Read the operating ratio (expenses ÷ revenue) as the survival headline and decompose it before acting. Reach for this on any profitability question. |
| `quantify-driver-retention` | `fleet-logistics` | Read driver turnover as a quantified unit-economics cost across recruiting, training, and unseated trucks. Reach for this when turnover is high. |
| `reduce-deadhead` | `fleet-logistics` | Read empty miles and truck utilization and build a routing/backhaul plan to lift the loaded-mile ratio. Reach for this when rate-per-mile looks fine but margin doesn't. |
| `run-preventive-maintenance` | `fleet-logistics` | Run a PM program against maintenance CPM and downtime so a deferred PM doesn't become a roadside failure. Reach for this when repair costs rise. |
| `form-intake-and-triage-design` | `forms-engineering` | Design the intake behind a form so triage is deterministic: request taxonomy, the fields each request type actually needs, routing rules, per-type response clocks, self-serve-vs-escalate bright lines, and abandonment read as a process defect stream. Produces a form spec, not a wireframe. |
| `form-telemetry-and-control` | `forms-engineering` | Define a form's measurement contract before instrumenting it: which events, which denominator, what counts as a defect, how per-field drop-off lies, and how to hand an individuals series to statistical process control without manufacturing false signals on a low-volume form. |
| `harden-a-form-submission` | `forms-engineering` | Walk the trust boundary of a form submission on the server: client/server validation parity, honeypot design and its assistive-tech exemption, double-submit and submission idempotency, webhook signature verification, PII minimisation. Cites ravenclaude-core for uploads and challenge widgets; the binding verdict always routes to security-reviewer. |
| `wire-form-substrate` | `forms-engineering` | Make the neutral forms guidance executable on the RavenPower stack: the ordered authority chain for a public write, where the challenge check sits, which fail directions are chosen, and the four honest gaps a reader must re-verify before relying on them. |
| `model-unit-economics` | `franchise-operations` | Build a royalty-loaded unit-economics model for a franchise unit: revenue with royalty + ad-fund + fees taken off the top, then COGS / labor / occupancy / other opex to a unit profit and a break-even, plus total investment and months-to-ramp — so a buy/expand decision rests on bottom-up numbers, not the brand's Item-19 headline. Reach for it before any franchise buy or expansion. Used by `franchise-operations-strategist` (primary). Not investment advice. |
| `read-the-fdd` | `franchise-operations` | A decision-focused read of a Franchise Disclosure Document: what the key Items mean for a buy decision — fees (Items 5-6), total investment (7), restrictions & territory (8/11/12), the Item 19 FPR's scope/cohort/exclusions, and turnover/litigation/bankruptcy (3/4/20) — as franchisee literacy, explicitly NOT legal advice (binding review -> legal-ops-clm). Reach for it when someone hands you an FDD. Used by `franchise-operations-strategist` (primary). |
| `run-brand-standard-audit` | `franchise-operations` | Run a repeatable brand-standard audit across franchise units and turn it into a coaching loop: a weighted checklist tied to the franchise agreement's operating standards, a scored audit per unit, the specific gaps framed as contract risk, and a coach-and-re-audit cadence. Reach for it to keep quality consistent across locations and protect the license. Used by `multi-unit-performance-manager` (primary). |
| `freight-pricing-mechanics` | `freight-forwarding-sales` | Veteran reference for building an accurate all-in freight quote — air chargeable weight (IATA 1:6000 volumetric vs actual), ocean CBM and weight/measure ton, the full ocean + air surcharge stack (BAF, CAF, THC, LSS, GRI, PSS, ISPS, AMS/ENS, DDC), margin methods (on-cost vs on-sell), and validity/volatility handling. Consulted by freight-rate-quoter. |
| `incoterms-2020` | `freight-forwarding-sales` | Veteran reference for Incoterms 2020 in a sales context — all 11 terms, the cost vs risk transfer point of each, the who-pays-what responsibility matrix, the 7 any-mode vs 4 sea-only split, named-place discipline, and the recurring quoting traps (FCA vs FOB for containers, CIP vs CIF insurance, DDP duty/VAT exposure). Consulted by trade-lane-compliance-advisor. |
| `pipeline-forecasting` | `freight-forwarding-sales` | Veteran playbook for freight-sales pipeline and forecast discipline — stage definitions tied to buyer behavior, coverage ratio, sales velocity, weighted vs commit vs best-case forecast, the deal-inspection checklist, single-threaded-risk flags, and the long multi-stakeholder logistics cycle (6 to 18 months). Consulted by pipeline-forecast-coach. |
| `prospect-outreach` | `freight-forwarding-sales` | Veteran playbook for freight new-business prospecting — ICP definition for shippers, trigger-event sourcing, the 8-touch multi-channel sequence (email / call / LinkedIn), the value-first message framework (problem to lane-proof to ask), the low-risk wedge for happy-with-current-forwarder, objection handling, and channel mix. Consulted by prospecting-outreach-strategist. |
| `qbr-account-planning` | `freight-forwarding-sales` | Veteran playbook for freight key-account work — the QBR agenda and deck structure (partnership recap, value delivered, honest assessment, next-quarter goals, joint action plan), the account-plan template (relationship map, whitespace, growth plays, risks), service-recovery, incumbent defense, and the account-health read. Consulted by key-account-manager. |
| `rfq-tender-response` | `freight-forwarding-sales` | Veteran playbook for freight RFQ/RFP/tender response — RFQ vs RFP vs RFI, the qualify-or-decline scorecard, the four operational drivers of quote win-rate (speed, accuracy, optionality, margin consistency), the lane rate-matrix format, the bid-narrative structure, give-get on price, and follow-up cadence. Consulted by rfq-tender-strategist. |
| `accessibility-audit-and-fix` | `frontend-engineering` | Actionable checklist and fix patterns for WCAG 2.1 AA compliance in React apps — automated scanning, keyboard navigation, focus management, ARIA usage, color contrast, and the most common component-level failures. |
| `frontend-performance` | `frontend-engineering` | Make a frontend fast to a budget: analyze and code-split the bundle by route, lazy-load heavy/below-the-fold, optimize images/fonts, minimize hydration (RSC/islands), kill render-blocking and request waterfalls, and tune the Core Web Vitals (LCP/INP/CLS) against field data. |
| `frontend-state-architecture` | `frontend-engineering` | Architect frontend state: treat server data as a cache (TanStack Query/SWR/RSC), place client state at the narrowest workable scope (local -> context -> store), invalidate deliberately, use optimistic updates with rollback, and derive rather than duplicate. |
| `react-component-craft` | `frontend-engineering` | Build composable, accessible React components: small components with clear props (composition over a flag-laden mega-component), correct hooks (complete deps, no stale closures, effects only for external sync), controlled validated forms, and accessibility in the markup. |
| `rendering-strategy` | `frontend-engineering` | Choose the rendering strategy per route: SSG/ISR for static content, SSR/RSC for personalized or SEO-critical pages, CSR for behind-login interactive shells; default to server components and hydrate only interactive islands to minimize shipped JavaScript. |
| `ensure-deathcare-compliance-and-pricing` | `funeral-home-operations` | Audit a funeral home's pricing and disclosures against the FTC Funeral Rule and clear the cremation-authorization and vital-records gates. Check the General Price List, Casket Price List, and Outer Burial Container list for required disclosures and itemization (no forced packages, embalming-not-required, telephone-price disclosure, no misrepresentation); confirm the cremation authorizing agent, positive ID, written authorization, and unbroken chain-of-custody before any irreversible step; and sequence the death certificate, certification, and disposition permits. Reach for this when the user asks "is our GPL compliant?", "what authorizes a cremation?", or "what vital records/permits do we need?". Used by `funeral-arrangement-and-compliance-specialist` (primary). Not legal advice — verify the current Rule + state law with counsel. |
| `manage-case-logistics-and-fulfillment` | `funeral-home-operations` | Read and manage the funeral-home case-flow pipeline (first call → removal/transfer → arrangement → preparation → services → billing → aftercare), find the constraint stage that gates throughput, size staffing and on-call/removal capacity against call volume, decide build-vs-contract for removals or preparation, and produce the fulfillment plan for the arranged services — all while protecting the family experience, not just the margin. Reach for this when the user asks "why are families waiting?", "are we staffed right for our volume?", "where's the bottleneck in our case flow?", or "can we fulfill these services on our capacity?". Used by `funeral-operations-lead` (primary). Not legal/financial advice — verify licensing and benchmarks. |
| `run-funeral-arrangement-and-intake` | `funeral-home-operations` | Run a grief-aware, FTC-Funeral-Rule-compliant arrangement — from first-call intake through the arrangement conference to documented, itemized selections and disposition. Traverse the deathcare-compliance decision tree so the right disclosures (GPL, CPL, Outer Burial Container list, telephone-price, embalming-not-required, no-misrepresentation) are given at the right moment, itemize without forcing a package, select the disposition and its requirements, and capture it in the arrangement worksheet. Reach for this when the user asks "walk me through the arrangement conference", "how do we handle a first call", or "arrange this service correctly". Used by `funeral-arrangement-and-compliance-specialist` (primary). Not legal advice — verify jurisdiction-specific items with counsel. |
| `balance-the-economy` | `game-development` | Design the economy as a system of sources, sinks, and progression pacing, not a price list, so it doesn't inflate or starve. Reach for this on an economy question. |
| `burn-down-risk` | `game-development` | Track and burn down the riskiest unknowns (fun, tech, content cost) first, not just a task list, since scope kills games. Reach for this on the production plan. |
| `design-the-core-loop` | `game-development` | Design the second-to-second and session-to-session core loop before features, since retention lives there. Reach for this at the start of design. |
| `read-live-ops` | `game-development` | Read retention (D1/D7/D30) and monetization together, gating monetization on retention, to operate the live game. Reach for this post-launch. |
| `scope-to-vertical-slice` | `game-development` | Scope the project to a vertical slice that proves the core loop is fun before scaling content, to de-risk the build. Reach for this at greenlight. |
| `gcp-compute-selection` | `gcp-cloud` | Choose GCP compute by operational burden: Cloud Run (default for stateless containers/HTTP, scale-to-zero), GKE/Autopilot (k8s/portability), Cloud Run functions (small event handlers), GCE (legacy); design Pub/Sub integration with idempotency + dead-letter topics. |
| `gcp-cost-governance` | `gcp-cloud` | Playbook for setting up GCP billing visibility and cost controls — billing export to BigQuery, budget alerts, label-based attribution, committed-use discounts, and the common cost leaks to eliminate first. |
| `gcp-least-privilege-iam` | `gcp-cloud` | Write least-privilege GCP IAM: predefined/custom roles over primitive (Owner/Editor/Viewer), service accounts + Workload Identity Federation instead of exported key files, IAM Conditions, and binding at the correct hierarchy level. |
| `gcp-private-networking` | `gcp-cloud` | Design private-by-default GCP networking: Shared VPC for multi-project, default-deny firewall targeted by tag/service-account, Private Google Access + Private Service Connect, and Cloud NAT for controlled egress. |
| `gcp-resource-hierarchy` | `gcp-cloud` | Design the GCP resource hierarchy: organization -> folders (env/dept) -> projects (app/workload), and set org-policy constraints (allowed regions, disable SA key creation, no external IP, OS Login) high in the tree for inheritance. |
| `brand-conditioned-generation` | `generative-web-media` | Condition generation on a brand: consume brand tokens from whatever source is present (a DTCG design-token file OR ravenclaude-core:brand-extraction's brand.json), assemble a 3-10 image style-reference / Recraft brand-style upload, then post-overlay the exact brand hex rather than trusting the model's color memory. Style-reference beats seed-pinning. This plugin CONSUMES tokens; it does not produce them. |
| `curation-and-accessibility-gate` | `generative-web-media` | The mandatory ship gate: brand-hex/style conformance, anti-slop QA (garbled in-image text, hands/anatomy, off-brand drift, no baked-in text), AI-drafted + human-reviewed WCAG 2.2 alt text (decorative -> alt=""), and a mandatory human curation sign-off. No asset reaches production without a curation artifact — this gate is a hard blocker, not a suggestion. |
| `generation-budget-guard` | `generative-web-media` | Keep generation spend a design input, not a surprise: route a cheap draft before a premium final, set a per-project generation budget cap, log each spend line (you supply the unit price — every provider price is [unverified]), and fail loudly when the cap is exceeded. Backed by gen-budget.py (stdlib, no baked-in prices) and /check-generation-budget. |
| `license-and-provenance-ledger` | `generative-web-media` | Pin each asset's commercial-use license before the prompt (flag the FLUX-dev non-commercial trap; Firefly-indemnified where indemnity_required; Grok has no IP indemnity), write the durable internal provenance ledger (prompt/model/provider/license/indemnity/date) since C2PA is routinely stripped, and add EU AI Act Art.50 disclosure copy for EU-facing sites. Not legal advice -> routes hard calls to security-reviewer. Facts dated [verify-at-use]. |
| `prompt-to-asset-routing` | `generative-web-media` | Route a creative brief to the right AI generator across images (photoreal, illustration, vector/SVG, text-in-image), video, 3D, and audio — plus the editing round-trips (inpaint, outpaint, background-removal, upscale) that beat a fresh generation. License-first, Grok-lean for images where competitive, draft-vs-final cost tiering. Provider/price specifics [verify-at-use]; every price [unverified]. |
| `web-optimization-pipeline` | `generative-web-media` | Turn a raw generated asset into a production web asset: AVIF/WebP/fallback responsive <picture> at 3-5 widths with explicit dims (CLS-safe), LCP hero eager + fetchpriority=high (cap 1-2), lazy below-fold, accessible muted-autoplay prefers-reduced-motion video embeds with a poster-LCP frame + WebM/H.264 fallback, and <model-viewer> glTF. Build-time (Sharp) default; CDN documented. Optimizer LOUD-SKIPs if Node/Sharp absent. |
| `design-postgis-schema` | `geospatial-engineering` | Design a PostGIS table for spatial data — pick the CRS (SRID) and geometry-vs-geography type by use-case, declare the column with an explicit SRID, add the right GiST/SP-GiST spatial index, and emit a runnable CREATE TABLE + index. Reach for this when the user wants to store points/lines/polygons in PostGIS and asks "which SRID?" or "geometry or geography?". Used by `geospatial-data-engineer` (primary). |
| `serve-vector-tiles` | `geospatial-engineering` | Serve geospatial data to a web map — decide GeoJSON vs vector tiles (MVT) by feature count and zoom, stand up a tile server (pg_tileserv / Martin / Tegola or MBTiles), and wire the MapLibre source + layer to consume it. Reach for this when a map is slow, you have many features, or you need a tile-serving architecture. Used by `mapping-visualization-engineer` (primary). |
| `spatial-data-quality` | `geospatial-engineering` | Keep spatial data trustworthy: geometry validity (ST_IsValid / ST_MakeValid, self-intersections, ring order), topology, declared-vs-actual SRID checks, coordinate-order (lon/lat) sanity, and validating geometry at load time so bad data never lands. Reach for this when loading a dataset, debugging a function that crashes on some rows, or hardening an ingest. Used by `geospatial-data-engineer` (primary). |
| `write-spatial-query` | `geospatial-engineering` | Write or fix a spatial SQL query in PostGIS — spatial joins, nearest-neighbor (KNN), buffers, ST_DWithin proximity — so it uses the GiST index and returns sensible units. Reach for this when a query is slow, returns degrees, or you need an index-aware ST_ query. Diagnoses the common smells (no index, degrees-not-metres, SRID mismatch). Used by `geospatial-data-engineer` (primary). |
| `build-grant-pipeline-and-prospect-fit` | `grants-management` | Build a prioritized, capacity-weighted grant pipeline and decide whether to pursue each opportunity by scoring funder fit BEFORE effort and running a real go/no-go — traverse the grants-lifecycle decision tree (grant type → funder fit → go/no-go), then return a fit score per prospect, a pursue/pass verdict weighing eligibility, capacity to deliver, cost-to-apply vs expected value, and compliance burden, plus the conditions that would flip each call. Reach for this when the user asks "should we apply for this grant?", "is this funder a fit?", "build our grant pipeline", or "go/no-go on this RFP". Used by `grants-strategy-lead` (primary). |
| `manage-post-award-compliance-and-reporting` | `grants-management` | Keep an awarded federal grant clean from setup through closeout — run the 2 CFR 200 cost-principle test (allowable/allocable/reasonable) on every charge, establish and apply the indirect rate (NICRA vs de minimis on MTDC), keep time & effort certified, produce the SF-425 FFR and the RPPR/SF-PPR on the award calendar, make the 2 CFR 200.331 subrecipient-vs-contractor determination and stand up subrecipient monitoring, and carry the award to an audit-ready closeout (Single Audit threshold, documentation trail, final reports). Reach for this when the user asks "can we charge this cost?", "what indirect rate?", "build the FFR/RPPR", "subrecipient or contractor?", or "are we audit-ready?". Used by `grants-compliance-and-reporting-specialist` (primary). Not legal/accounting advice. |
| `write-and-assemble-grant-proposals` | `grants-management` | Turn a program into a fundable, NOFO-rubric-aligned proposal by chaining the program-design spine — needs statement → logic model / theory of change → SMART objectives → evaluation plan → budget & budget narrative (every line tied to an activity) — then assemble the LOI or full-proposal package (narrative, attachments, SF-424 family if federal, a reusable boilerplate library, and a NOFO-criteria crosswalk so nothing scored is unaddressed). Reach for this when the user asks "draft the logic model / needs statement", "write the narrative for this NOFO", or "assemble the full proposal / LOI". Used by `grants-strategy-lead` (primary). |
| `choose-graph-or-not` | `graph-engineering` | Walk the graph-vs-relational decision tree and return a one-screen verdict — LPG, RDF, stay relational, stay RAG, or stay KV — plus the neighbor hand-off. Reach for this before any labels or Cypher. |
| `construct-retrieval-graph` | `graph-engineering` | Design a retrieval-graph (GraphRAG) extract-index-search architecture only after a BM25/no-graph baseline has lost. Hands paradigm III.a to memory-engineering and eval to ai-rag-engineering. |
| `model-property-graph` | `graph-engineering` | Design a labeled property graph — labels, typed directed relationships, business-key identity, temporal edges, and a supernode plan. Fill templates/graph-data-model.md before any CREATE. |
| `write-graph-query` | `graph-engineering` | Write a bounded, typed traversal. Cypher examples first, then ISO GQL, then Gremlin or SPARQL 1.1 stubs. Flag unbounded * and untyped -[]- as bugs. Includes GraphRAG local/global/DRIFT query patterns. |
| `graphql-federation-and-composition` | `graphql-engineering` | Decide whether to federate, keep a monolithic graph, or stitch — and if federating, design clean subgraph ownership boundaries with entity @key, reference resolvers, and @external/@requires/@provides, then weigh the real operational cost of running a gateway/router. Federation spec and directive specifics verify-at-use. |
| `graphql-schema-design-and-evolution` | `graphql-engineering` | Design a GraphQL schema for the clients that consume it — not the database underneath: nullability discipline, Relay cursor-connection pagination, input/payload mutation shape, errors-as-data vs top-level errors — and evolve it without breaking clients via additive change, @deprecated, and staged field rollout. Spec/library specifics verify-at-use. |
| `graphql-security-and-governance` | `graphql-engineering` | Defend a GraphQL endpoint whose single URL accepts arbitrary nested queries: depth limiting, cost/complexity budgets, field-level authorization (authorize at the field, not the endpoint), introspection hardening in prod, persisted/allow-listed operations, rate and batching limits, and error-message hygiene so internals never leak. Library/spec specifics verify-at-use. |
| `resolver-performance-and-n-plus-one` | `graphql-engineering` | Kill the N+1 problem GraphQL's per-field resolution invites: batch and per-request-cache with DataLoader, be selection-set aware so you fetch only requested fields, bound pagination cost, avoid over-fetching downstream, and layer response caching / APQ. Includes a worked N+1 example and its DataLoader fix. Library specifics verify-at-use. |
| `create-grok-bot` | `grok-bot-creation` | Use this when creating or refining a Grok Bot — token-efficient autonomous specialists, wall escalation via CoS, math/stats + problem-solver stance (first principles, Occam, quantitative failure analysis, game theory; never one-and-done), sync net-new skills to RavenClaude via GitHub Sage. |
| `delegate-via-expert-bots` | `grok-bot-delegation` | Use this on every user ask: sole-relay through Chief of Staff, wall escalation, prefer math/stats when they win, create/enhance experts, port or upstream RavenClaude skills, then delegate. |
| `grok-bot-token-spend` | `grok-bot-delegation` | Use when optimizing Grok Bot / multi-bot fleet token spend — condensed returns, effort ladder, routine hygiene, connectors over browser, CPCT measurement. |
| `review-schematic-and-layout` | `hardware-electronics-engineering` | Review a schematic and PCB layout before fab: correctness (ERC/DRC, footprints/pinouts/polarity, power), integrity (decoupling at the pin, grounding/return paths, stack-up, controlled impedance), and DFM/DFA/DFT against the target fab's rules — returning a prioritized findings list with fixes. Reach for this before sending to fab, or on an inherited design. Driven by pcb-design-engineer. |
| `scope-a-hardware-design` | `hardware-electronics-engineering` | Turn a product idea into a hardware architecture: decide module/dev-board vs custom PCB (via the decision tree), name requirements before parts, sketch the power tree, the interface plan, and an EMC/pre-compliance posture — against a cost/power/size/volume/schedule budget. Reach for this at the START of any board project. Driven by hardware-systems-architect. |
| `select-components-and-bom` | `hardware-electronics-engineering` | Select the MCU/SoC and key components and build a supply-aware BOM: match parts to requirements, read datasheet parameters at the operating point (worst-case + margin), and weigh availability / second-source / lifecycle / cost at the target volume. Reach for this after the architecture is scoped, before schematic capture. Driven by hardware-systems-architect. |
| `enrollment-funnel-and-yield` | `higher-education-administration` | Model the enrollment funnel stage-by-stage (inquiry->apply->admit->yield->melt), compute yield and melt, and find the leaking stage before spending at the top of the funnel. Every benchmark carries a definition + retrieval date + verify-at-use; cohort-level only, no student PII. |
| `financial-aid-and-discount-rate` | `higher-education-administration` | Model the tuition discount rate and net tuition revenue, and spend institutional aid as deliberate yield leverage rather than a gap-filler. Distinguishes gross vs net, aid as leverage vs entitlement. Discount-rate norms are volatile -> verify-at-use; cohort-level only, no student PII. |
| `registrar-and-academic-operations` | `higher-education-administration` | Registrar and academic operations that the enrollment and retention engines run on: the academic calendar, course/section scheduling and capacity, credential and transcript integrity, and the data definitions IR reports from. Definitions/policies are institution-specific -> verify-at-use; no student PII. |
| `retention-and-student-success` | `higher-education-administration` | Turn retention into an early-alert operation: compute persistence with its definition attached, triage at-risk cohorts by leverage, and read DFW gateway courses as retention infrastructure. Metric definitions vary by IPEDS/accreditor/IR -> verify-at-use; cohort-level only, no student PII. |
| `build-budget-and-reserve-plan` | `hoa-community-association-management` | Build an annual operating + reserve budget, set the assessment (dues) level, and set the reserve-funding policy by traversing the community-association decision tree (association authority & governing docs → operating budget → reserve study & percent-funded target → funding method → assessment level → major-project funding: raise reserves / special assessment / association loan / phase), then return the budget, the dues level, the reserve-funding recommendation, the major-project plan, and the conditions that change it. Reach for this when the user asks 'build our annual budget', 'what should the assessments be?', 'how much do we fund the reserves?', 'are our reserves underfunded?', or 'special assessment, loan, or phase the project?'. Used by association-management-lead (primary) and community-operations-specialist. |
| `manage-board-and-vendor-operations` | `hoa-community-association-management` | Run board/annual meetings, official records, vendor coordination, and common-area maintenance by traversing the community-association decision tree (meeting notice per the bylaws → agenda & board packet → quorum/proxy → minutes (motions/votes/decisions) → official-records retention & owner-inspection; and for vendors: scope → competitive bids with insurance/license verification → board-approval threshold → work-order & preventive-maintenance schedule → inspection loop), then return the meeting package + minutes and the vendor/maintenance plan within budget and spending authority. Reach for this when the user asks 'prepare our annual meeting', 'take the minutes', 'get bids for a contract', 'schedule the common-area maintenance', or 'what records must we keep?'. Used by community-operations-specialist (primary) and association-management-lead. |
| `run-covenant-and-collections-workflow` | `hoa-community-association-management` | Process a covenant violation, an architectural-review request, or a delinquent-assessment account by traversing the community-association decision tree (find the governing-document authority → for a violation: notice → cure period → hearing → fine/remedy, applied evenly and documented; for ARC: application vs the design guidelines → decision → record; for collections: reminder → late fee → demand notice → lien-referral / escalation-to-counsel gate), then return the processed decision, the due-process trail, and the escalation point. Reach for this when the user asks 'process this covenant violation', 'review this architectural change request', 'work our delinquency list', 'can we fine / lien this owner?', or 'what's our collections sequence?'. Even-handed, documented process is the whole point; lien/foreclosure mechanics route to counsel. Used by community-operations-specialist (primary) and association-management-lead (policy). |
| `build-scheduling-and-evv-workflow` | `home-health-care-operations` | Build the visit schedule and the EVV workflow by traversing the home-health decision tree (plan of care + authorization → staffing match & caregiver continuity → visit schedule to ordered frequency/units → EVV capture: check-in/out via GPS/telephony/device per the state model → exception handling for missed/late/unverified visits), then return the continuity-staffed schedule, the EVV capture setup, and the exception procedure that keeps every visit billable and defensible. Reach for this when the user asks 'schedule this patient's visits', 'assign a caregiver for continuity', 'set up EVV', 'why is this visit unverified?', or 'handle a missed visit'. Used by home-care-operations-specialist (primary) and home-health-agency-lead. |
| `plan-intake-and-eligibility` | `home-health-care-operations` | Take a home-health / home-care referral through intake by traversing the home-health decision tree (referral → service-line class: skilled home health vs non-medical home care → eligibility & benefit verification: Medicare homebound + skilled need / Medicaid-waiver authorization / private-pay → the physician-order + face-to-face + certification gate → initial plan of care), then return the verified eligibility, the cleared order gate, the start-of-care date, and the initial plan of care. Reach for this when the user asks 'get this referral through intake', 'is this patient eligible for home health?', 'do we have the physician order / face-to-face?', or 'set up the plan of care'. Used by home-care-operations-specialist (primary) and home-health-agency-lead. |
| `run-billing-and-survey-readiness` | `home-health-care-operations` | Turn home-health documentation into paid, survey-proof claims by traversing the home-health decision tree (documentation completeness: OASIS / plan of care / visit notes → PDGM 30-day period billing: NOA + final claim, LUPA watch, comorbidity → Medicaid-waiver / private-pay per-unit billing → denial root-cause analysis → conditions-of-participation & survey-readiness checks), then return the completeness gate, the period claim, the denial fixes, and the CoP/survey-readiness gap list. Reach for this when the user asks 'bill this 30-day period', 'why are our claims denied?', 'is our documentation complete?', or 'would our charts pass a survey?'. Used by home-care-operations-specialist (primary) and home-health-agency-lead. |
| `admissions-funnel-analytics` | `hospice-referral-sales` | Veteran playbook for reading the hospice referral-to-admission funnel — the stage definitions tied to observable events, conversion rate, time-to-admission and same-day admits, the declined-referral root-cause taxonomy with an owner for each, average daily census and length-of-stay reads, and the activity-to-census model. Consulted by admissions-conversion-coach. A referral is not census until it converts. |
| `goals-of-care-conversations` | `hospice-referral-sales` | Veteran playbook for the human conversations in hospice referral work — the hospice-vs-palliative distinction, the timing problem, the myth-and-objection responses ('giving up', 'too soon', 'my doctor didn't mention it', 'I want to keep fighting'), and a values-first, no-false-promise framing approach. Consulted by goals-of-care-conversation-coach. Empathy and accuracy; never a scripted guarantee or a pressure tactic. |
| `hospice-eligibility-criteria` | `hospice-referral-sales` | Veteran playbook for EDUCATING referral sources on hospice eligibility — the Medicare Hospice Benefit structure, the non-disease-specific decline guidelines, the diagnosis-specific LCD criteria, and the PPS/FAST/NYHA scales. Teaches recognition, never certification. Consulted by hospice-eligibility-educator. Every output ends with 'the attending physician and medical director certify eligibility.' |
| `hospice-sales-compliance` | `hospice-referral-sales` | Veteran playbook for hospice referral-marketing compliance — the Anti-Kickback Statute and its hospice-relevant safe harbors, Stark, the beneficiary-inducement CMP, the gift/meal nominal-value discipline, OIG hospice risk areas, truthful-marketing rules, and HIPAA for a liaison. Consulted by hospice-sales-compliance-advisor. Frames the question and names the rule and safe harbor; routes the RULING to the compliance officer / counsel. |
| `referral-account-planning` | `hospice-referral-sales` | Veteran playbook for hospice key-referral-partner work — the partner business-review structure (patient outcomes, access improvements, honest assessment, shared goals, joint plan), the account-plan template (relationship map, whitespace by unit/service line, growth plays, risks), the relationship-recovery sequence, and the partner-health read. Consulted by referral-account-manager. Patient-outcome-led; never retain or grow a partner with an un-cleared value exchange. |
| `referral-territory-development` | `hospice-referral-sales` | Veteran playbook for planning and growing a hospice referral territory — referral-source segmentation, the volume × eligibility-density × relationship-gap targeting model, trigger events, the in-service education program, and the source-type-specific multi-touch outreach cadence. Consulted by referral-development-strategist. Patient-access-led; every value exchange routes to compliance first. |
| `compare-channels` | `hotel-hospitality-operations` | Compare channels at net rate after acquisition cost, not gross rate. Reach for this on a channel or OTA question. |
| `link-experience-revenue` | `hotel-hospitality-operations` | Link guest satisfaction to rate power and channel margin — treat experience as a revenue input. Reach for this on a guest-experience question. |
| `read-booking-pace` | `hotel-hospitality-operations` | Read booking pace and pickup against the prior cycle to decide hold-rate vs stimulate. Reach for this on a forecast or pace question. |
| `read-revpar` | `hotel-hospitality-operations` | Read RevPAR as ADR × occupancy and test the rate-vs-occupancy trade-off; carry to GOPPAR if profit is given. Reach for this on a rate or RevPAR question. |
| `size-labor` | `hotel-hospitality-operations` | Size labor to the occupancy forecast by hours-per-occupied-room and protect flow-through. Reach for this on a labor question. |
| `acquire-and-preserve-evidence` | `incident-response-dfir` | Acquire and preserve digital evidence so it survives scrutiny — collect in RFC 3227 order of volatility (most-volatile first), hash at collection, maintain an unbroken chain of custody, and use the right acquisition method per source (memory, disk, network, cloud). Returns the acquisition plan, the chain-of-custody log, and the hash/verification record. Used by `detection-and-forensics-engineer` (primary); enforced as a gate by `dfir-response-lead` before remediation. |
| `engineer-a-detection` | `incident-response-dfir` | Turn an observed (or hypothesized) adversary behavior into a durable detection — author a Sigma/SIEM rule, map it to the MITRE ATT&CK technique it covers, and ship a false-positive tuning plan so the rule survives contact with production logs instead of dying in alert fatigue. Returns the rule, its ATT&CK mapping, test cases, and the tuning/allow-list plan. Used by `detection-and-forensics-engineer` (primary). |
| `hunt-for-a-threat` | `incident-response-dfir` | Run a hypothesis-driven threat hunt — turn a testable claim about adversary activity into named data sources and queries, guided by MITRE ATT&CK, and rank findings up David Bianco's pyramid of pain so effort goes at TTPs (expensive for the adversary to change) rather than hashes and IPs (trivial to change). Returns the hypothesis, the data sources + queries, findings, and any detections/incidents to spin up. Used by `detection-and-forensics-engineer` (primary). |
| `run-the-incident-lifecycle` | `incident-response-dfir` | Run a security incident through the four-phase incident-handling lifecycle in order — preparation, detection & analysis, containment/eradication/recovery, and post-incident activity — with the contain-before-eradicate and preserve-evidence-first gates enforced at the right steps. Returns a phase-by-phase runbook, the containment strategy, the recovery/eradication plan, and a blameless post-incident review. Used by `dfir-response-lead` (primary); shared with the forensics engineer at the analysis seam. |
| `triage-and-classify-an-incident` | `incident-response-dfir` | Decide whether an alert or report is a genuine security incident (the is-it-an-incident gate), then classify its severity/priority from a business-impact × scope matrix so the response tier is set by impact, not by how loud the alert looks. Returns the incident verdict, the severity level + the rule that picked it, and the response tier it triggers. Used by `dfir-response-lead` (primary). |
| `benefits-plan-design` | `insurance-life-health-benefits` | Design a group employee-benefits package as a system: plan types per line (medical/dental/vision/life/disability), plan-type mechanics (HMO/PPO/HDHP+HSA, deductible/coinsurance/OOP-max), and the funding decision (fully-insured vs self-funded vs level-funded) sized to the group, with the ACA/ERISA obligations named — educational scaffolding, not advice. |
| `enrollment-and-compliance` | `insurance-life-health-benefits` | Run open enrollment and keep a group benefits program operationally compliant: a backward-planned enrollment cycle (timeline, eligibility, QLE/special enrollment, communications, carrier/EDI coordination) and the recurring compliance calendar (COBRA, HIPAA, ACA 1095-C/1094-C, ERISA Form 5500 + SPD/SBC) — educational scaffolding, not legal advice. |
| `underwriting-and-rating` | `insurance-life-health-benefits` | Explain and pressure-test group rating and renewals: rating factors, manual vs experience rating weighted by credibility, the underwriting loss ratio vs the ACA medical-loss-ratio (MLR) test, and decomposing/sanity-checking a renewal projection (trend, experience, pooling, demographics, plan change) — educational scaffolding, not actuarial advice. |
| `decompose-the-combined-ratio` | `insurance-pc` | Split the combined ratio into loss and expense, then attritional and catastrophe, so a deteriorating result is diagnosed correctly. Reach for this on any result question. |
| `price-to-rate-adequacy` | `insurance-pc` | Price risk to expected loss plus expense plus profit load against loss trend, not to the competitor, so growth doesn't grow a loss. Reach for this on any pricing question. |
| `read-the-portfolio-result` | `insurance-pc` | Read the underwriting result by line of business, attritional-vs-cat and net-of-reinsurance, so the mix story is visible. Reach for this on a portfolio review. |
| `review-claims-leakage` | `insurance-pc` | Read indemnity leakage, LAE, and cycle time as managed metrics, not minimized payout, to find the controllable gap. Reach for this on a claims-cost question. |
| `separate-frequency-and-severity` | `insurance-pc` | Decompose a loss-ratio move into frequency and severity, since they have opposite responses, before prescribing. Reach for this when the loss ratio moves. |
| `build-risk-based-audit-plan` | `internal-audit` | Build a risk-based internal-audit universe and annual plan by traversing the internal-audit decision tree (assurance-vs-advisory → risk-ranking the universe → coverage/cycle → resourcing), then return the scored audit universe, the resource-balanced annual plan (assurance/advisory mix, cycle coverage), the IIA-Standards/Three-Lines positioning, and the audit-committee residual-risk narrative. Reach for this when the user asks 'how do we rank our audit universe?', 'what should be on this year's audit plan?', 'how much of the universe can we cover?', or 'how do we stay IIA-conformant and independent?'. Used by internal-audit-lead (primary). |
| `plan-and-execute-audit-engagement` | `internal-audit` | Plan and execute a single internal-audit engagement by traversing the internal-audit decision tree (assurance-vs-advisory → scope & criteria → sampling approach → evidence), then return the planning memo, the risk & control matrix (risk → control → type → tests), the walkthrough, the test of design + test of operating effectiveness with an attribute-sampling plan and sample size, and review-ready workpapers. Reach for this when the user asks 'draft the planning memo and RCM', 'how do we test this control?', 'what sample size?', or 'are our workpapers sufficient?'. Used by audit-engagement-specialist (primary). |
| `rate-and-report-audit-findings` | `internal-audit` | Turn tested control gaps into well-formed internal-audit findings and report them by traversing the issue-rating branch of the internal-audit decision tree, then return each finding on the 5 C's (Criteria/Condition/Cause/Consequence/Corrective action), an impact×likelihood rating (high/medium/low), the agreed management action plan (owner + date), the audit-committee summary, and the follow-up / remediation-validation plan. Reach for this when the user asks 'write this control gap as a finding', 'how bad is this issue / what rating?', 'draft the audit report or committee summary', or 'how do we validate the fix closed?'. Used by audit-engagement-specialist (primary) and internal-audit-lead. |
| `build-the-cmdb` | `itsm-service-management` | Stand up a maintainable CMDB — configuration items scoped to what earns its place, automated discovery, the relationships needed for impact analysis, and a drift-audit discipline. Reach for this when you need a configuration/asset source of truth. |
| `design-slas-and-catalog` | `itsm-service-management` | Define an SLA backed by the OLAs and underpinning contracts that make it deliverable, and a service catalog of standard requests. Reach for this when designing service targets or a request catalog. |
| `run-change-enablement` | `itsm-service-management` | Classify a change (standard/normal/emergency), assess its risk, and route it — pre-authorizing repeatable changes and reserving the CAB for genuine risk. Reach for this on any 'does this need approval / a CAB?' question. |
| `select-itil-practices` | `itsm-service-management` | Pick the lightest set of ITIL 4 practices that delivers value, grounded in the service value system and guiding principles — adopt what earns its keep, skip the ceremony. Reach for this when standing up or right-sizing ITSM. |
| `triage-incident-vs-problem` | `itsm-service-management` | Classify an issue as an incident (restore service now), a problem (remove the recurring cause), or a major incident (declare command), and open the right record. Reach for this when something is broken or keeps breaking. |
| `allocate-per-pupil` | `k12-school-administration` | Allocate per-pupil dollars to need and impact, not last year's distribution. Reach for this on a budget-allocation question. |
| `fit-staffing-to-budget` | `k12-school-administration` | Model a student:teacher ratio into FTE and salary cost and check it against the budget envelope. Reach for this on a staffing question. |
| `flag-chronic-absenteeism` | `k12-school-administration` | Compute the chronic-absentee rate, flag it early, and size the attendance-recovery funding upside. Reach for this on an attendance question. |
| `model-enrollment-funding` | `k12-school-administration` | Translate enrollment and ADA into funding and quantify the dollar value of each attendance point. Reach for this on a funding question. |
| `read-outcomes-segmented` | `k12-school-administration` | Read proficiency and growth disaggregated by subgroup and link to attendance — never the school average. Reach for this on an outcomes question. |
| `assess-legacy-estate` | `legacy-modernization` | Assess a legacy system and choose a modernization strategy with the 6 R's (retain/rehost/replatform/refactor/rearchitect/replace). Reach for this when the question is 'rewrite or refactor?' or 'is this worth modernizing?'. |
| `characterization-testing` | `legacy-modernization` | Pin a legacy system's current behavior with characterization / golden-master / approval tests before changing it, so a refactor that changes behavior fails loudly. Reach for this before any edit to untested legacy code. |
| `data-migration-and-cutover` | `legacy-modernization` | Migrate data off a legacy store with dual-write / parallel-run / reconciliation, then cut over with go/no-go gates and a tested rollback. Reach for this for any zero-downtime move or final switch-over. |
| `dependency-and-framework-upgrade` | `legacy-modernization` | Upgrade a stuck dependency, framework, or language version incrementally — one major at a time, on green tests, deprecations resolved between each — instead of a single risky leap. Reach for this when a system is several versions behind. |
| `strangler-fig-migration` | `legacy-modernization` | Plan an incremental strangler-fig migration off a legacy system — a facade routing one capability at a time to a new implementation behind an anti-corruption layer. Reach for this instead of a big-bang rewrite. |
| `contract-review-and-redline` | `legal-ops-clm` | Build a clause library with standard / fallback / walk-away positions, run a redline review that flags only the material deviations by risk tier, extract key terms into a structured schema, and route approval by the highest-tier deviation — operational support, not legal advice. |
| `legal-intake-and-playbooks` | `legal-ops-clm` | Design structured legal intake and triage, the request-to-resolution workflow, contract playbooks (self-serve vs. escalate with bright-line escalation triggers), matter management, and the legal-ops metrics that prove the function is healthy — operational support, not legal advice. |
| `obligations-and-renewals` | `legal-ops-clm` | Extract and track contract obligations as owned items, watch renewals / expiries / auto-renew with tiered notice-window alerts, and model the contract repository metadata so contracts are findable and reportable — operational support, not legal advice. |
| `build-practice-scorecard` | `legal-small-firm` | Build a realization-led practice scorecard with utilization, collected revenue, and A/R, each defined and baselined. Reach for this to instrument the practice. |
| `read-realization` | `legal-small-firm` | Read realization and the billed-vs-collected gap, locating write-downs, write-offs, and A/R, so the practice's real economics are visible. Reach for this on any 'busy but broke' question. |
| `run-conflict-checked-intake` | `legal-small-firm` | Run intake as risk management — conflict check and fit/viability screen before the engagement — to prevent the matters that destroy realization. Reach for this at every new matter. |
| `scope-the-matter` | `legal-small-firm` | Scope a matter and choose the fee structure deliberately, since an open-ended hourly with no budget breeds write-offs. Reach for this before engaging. |
| `support-drafting` | `legal-small-firm` | Draft and review documents from clause libraries with issue flags, as attorney-reviewed work product, never legal advice. Reach for this on a drafting or review task. |
| `build-llm-judge` | `llm-evaluation-engineering` | Design, calibrate, and bias-audit an LLM-as-judge so its scores track human judgment: named criteria with anchored levels (not 'rate 1-10'), a structured verdict + reason, a pinned judge model/version, a human-agreement calibration on a sample, and checks for position / verbosity / self-preference / leniency bias. Reach for it whenever a judge grades outputs. Used by `eval-harness-engineer` (primary). |
| `design-eval-suite` | `llm-evaluation-engineering` | Turn a fuzzy 'is the AI good enough?' into a concrete measurement plan: task spec, the eval method from the decision tree (exact / rule-based / model-graded / human), the metric + what it misses, the offline-vs-online split, a power-adequate sample size, and a numeric ship-gate decided before the run. Reach for it at the START of any LLM-feature eval. Used by `eval-strategy-lead` (primary). |
| `gate-releases-with-evals` | `llm-evaluation-engineering` | Wire an offline eval suite into a CI ship-gate so a prompt/model change is scored against a frozen baseline and blocked on a regression past a preset threshold, with guardrail/red-team checks as a zero-tolerance blocker and cost/latency tracked alongside quality. Reach for it to make evals a merge gate instead of a report. Used by both agents. |
| `i18n-foundations-and-icu` | `localization-i18n-engineering` | Core internationalization foundations: string externalization strategy, ICU MessageFormat for plurals and gender selects, CLDR plural rules, locale-aware formatting via ECMA-402/Intl APIs, RTL/bidi layout design, Unicode encoding, and text expansion budget planning. |
| `l10n-pipeline-and-tms` | `localization-i18n-engineering` | Design and operate the localization pipeline: string extraction configuration, TMS (Phrase, Lokalise, Crowdin, Transifex) integration and handoff, XLIFF/ARB/PO/JSON format conversion, translation memory management, continuous localization in a CD cycle, and branching strategies for in-flight translations. |
| `localization-qa-and-pseudo-loc` | `localization-i18n-engineering` | Localization quality assurance methodology: pseudo-localization CI gate design (accent, expansion, bidi variants), l10n linting rules (missing keys, empty values, placeholder consistency, ICU syntax), visual and overflow QA techniques, locale-coverage test matrix, and false-positive triage for l10n lint. |
| `capa-and-spc` | `manufacturing-operations` | Hold quality in control and stop defects recurring: stand up SPC reading special vs common cause correctly, structure a nonconformance through containment into a real CAPA, build inspection/control plans and FMEA, and set the supplier-quality bar — prevention over detection over scrap. |
| `mrp-and-production-planning` | `manufacturing-operations` | Turn demand into a buildable plan: run MPS/MRP and net through the BOM, reconcile the forecast against finite capacity in S&OP, choose lot sizes on an honest setup-vs-holding trade, and build a finite schedule that respects the bottleneck — never infinite-capacity planning. |
| `oee-and-throughput` | `manufacturing-operations` | Diagnose why the line is slow: compute OEE (availability × performance × quality) with stated denominators, compare takt to cycle time, identify the binding constraint via Theory of Constraints, and Pareto MES/downtime loss — fix the constraint, not a non-bottleneck. |
| `audit-attribution-data` | `marketing-operations` | Audit data hygiene, dedup, and UTM/tracking integrity before trusting any funnel or ROI number. Reach for this first on any new dataset. |
| `content-engine` | `marketing-operations` | Run content as a system — brief against search intent, build topic clusters around pillar pages, plan distribution, and measure leading vs lagging signals. Reach for this on a content-strategy or SEO-content question. |
| `diagnose-funnel` | `marketing-operations` | Diagnose MQL→SQL→opp→win conversion stage-by-stage — find the leaking stage before adding lead volume. Reach for this on a funnel question. |
| `evaluate-channel-mix` | `marketing-operations` | Evaluate channels on contribution and marginal ROI under a stated attribution model — not average ROI or lead count. Reach for this on a channel or budget question. |
| `read-cac-ltv` | `marketing-operations` | Read LTV:CAC and CAC-payback to gate acquisition spend on unit economics, not lead count. Reach for this on a CAC or sustainability question. |
| `size-demand` | `marketing-operations` | Back-solve the lead volume a win target requires through each stage conversion. Reach for this on a 'how many leads' question. |
| `choose-cdp-and-collection-architecture` | `martech-event-instrumentation` | Pick the right CDP and event-collection architecture for a described workload by traversing the CDP/collection decision tree (source of truth & activation → packaged CDP vs warehouse-first/reverse-ETL vs Snowplow self-hosted; accuracy vs UI-richness → client-side vs server-side vs hybrid), then return the recommendation, the trade-offs, and the conditions that would flip it. Reach for this when the user asks "Segment vs RudderStack vs Snowplow?", "packaged CDP or warehouse-first?", or "client, server, or hybrid?". Used by `event-taxonomy-architect` (primary). |
| `design-a-tracking-plan` | `martech-event-instrumentation` | Turn product and business questions into an event tracking plan — derive the event taxonomy (object-action naming), the properties, the naming convention, the identity model (anonymousId → userId stitching), and the per-event spec table, captured as the contract instrumentation builds to. Reach for this when the user asks "what events should we track?", "how should we name these?", or "how do we stitch anonymous to known users?". Used by `event-taxonomy-architect` (primary). |
| `implement-event-instrumentation-and-consent` | `martech-event-instrumentation` | Implement a tracking plan as working event collection — typed client/server-side Track/Identify calls, a codegen'd tracking library, schema validation in CI, consent gating at the source (Google Consent Mode v2 / IAB TCF / GPC), destination + reverse-ETL wiring, then QA the live stream. Reach for this when the user asks "implement these events", "add schema validation to CI", "wire consent", or "why is this event missing/wrong?". Used by `instrumentation-engineer` (primary). |
| `consult-to-treatment-conversion` | `med-spa-aesthetics` | Turn aesthetic consults into booked treatments: read where conversion leaks (offer clarity, provider-set treatment plan, transparent pricing, financing, same-day booking, follow-up cadence) and fix the highest-leak step first — without making a clinical or pricing determination. |
| `scope-of-practice-and-supervision` | `med-spa-aesthetics` | Map the med-spa compliance structure — scope of practice, good-faith exam / medical supervision, consent and adverse-event protocols, product handling — as operational structure, flagging every state-specific rule [verify-at-use] and routing the actual determination to the medical director and a licensed professional. Flag, never decide. |
| `service-mix-injectables-devices-memberships` | `med-spa-aesthetics` | Tilt the med-spa service mix toward contribution: read revenue and margin per provider-hour and per room-hour across injectables, energy devices, skincare retail, and memberships; model capital-device payback on realistic volume; size memberships on redemption and the capacity they pre-commit. |
| `treatment-room-and-injector-utilization` | `med-spa-aesthetics` | Read a med spa on its two scarce inventories — injector-hours and treatment-room-hours. Utilization = productive hours booked / available, read by provider and by room and by daypart; confirm the current capacity is full before adding an injector, a room, or a device. |
| `build-rcm-scorecard` | `medical-revenue-cycle` | Build a net-collection-led RCM scorecard with first-pass, denial-by-category, and days-in-A/R, each defined and baselined. Reach for this to instrument the cycle. |
| `prevent-denials` | `medical-revenue-cycle` | Categorize denials by root cause and owner and push fixes upstream to registration and authorization, instead of only appealing. Reach for this when the denial rate is high. |
| `read-coding-denials` | `medical-revenue-cycle` | Trace coding denials to documentation, code selection, or modifier use as decision-support, never to up-coding. Reach for this when coding denials rise. |
| `read-the-cash-cycle` | `medical-revenue-cycle` | Read net collection rate, first-pass resolution, and days-in-A/R together, against benchmark, so a cash problem is diagnosed correctly. Reach for this on any collections question. |
| `work-down-ar` | `medical-revenue-cycle` | Prioritize an A/R work-down by aging bucket, payer, and recoverable dollars, with timely-filing risk first. Reach for this when A/R piles up. |
| `budget-memory-costs` | `memory-engineering` | Put a defensible number on a memory system — break-even against a named baseline, growth and caps, cache-invalidation cost, and cost per correct answer. Reach for this on any pay-for-itself question. |
| `build-memory-eval` | `memory-engineering` | Prove a memory system earns its write path — golden set with provenance, judged failure modes, the runnable bake-off, and cost per correct answer. Reach for this before adopting, replacing or retiring any memory system. |
| `choose-memory-paradigm` | `memory-engineering` | Decide whether to build a memory system at all, and if so which paradigm — raw context, flat retrieval, LLM-extraction or agentic — behind a mandatory baseline-first gate. Reach for this before any memory design work. |
| `design-forgetting-policy` | `memory-engineering` | Design retention and erasure before the first write — TTL, caps, decay, consolidation timing, dedup, contradiction handling, and what a delete actually leaves behind. Reach for this on any durable store. |
| `map-memory-surface` | `memory-engineering` | Name the storage surface a write actually lands on — who holds the bytes, who executes the write, and what trust model comes with it. Reach for this before writing any memory design down. |
| `memory-poisoning-review` | `memory-engineering` | Audit an agent's durable memory for poisoning risk and harden it against OWASP ASI06 — enumerate write paths reachable from untrusted input, classify read-only vs read-write, verify audit and rollback. Reach for this when a diff touches a memory store. |
| `api-plugin-openapi-hygiene` | `microsoft-365-copilot` | Make a REST API safe and correct to expose as a Microsoft 365 Copilot API plugin — lay out the four files (app manifest + plugin manifest + OpenAPI + adaptive cards), verify the plugin-manifest↔OpenAPI `operationId` mapping both ways, respect the OpenAPI-for-Copilot subset, write model-readable operation descriptions, budget responses to ~66% of the 25-item/~4096-token wall, and wire Entra OAuth2/API-key auth (with the GCC-High caveat). Use when building or reviewing a Copilot API plugin. |
| `copilot-agent-eval-harness` | `microsoft-365-copilot` | Build the golden-prompt regression set + pre-publish evaluation gate for a Microsoft 365 Copilot agent — author representative + adversarial prompts, check grounding accuracy and citation correctness, stress the declarative-agent hard limits (50/25/4096/45s, no-loop), and gate publish on the results. Use before declaring any declarative or custom-engine agent done, and on every manifest/grounding change. |
| `copilot-connector-schema-design` | `microsoft-365-copilot` | Design a Microsoft 365 Copilot (Graph) connector schema — choose synced vs federated (MCP), declare property attributes (searchable/queryable/retrievable), apply the mandatory semantic-label map (title/url/createdBy/...), ingest ACLs for per-user trimming, and plan crawl/refresh + semantic-index latency. Use when building a Copilot connector to ground Copilot on a line-of-business store. |
| `declarative-agent-manifest-authoring` | `microsoft-365-copilot` | Author and review a Microsoft 365 Copilot declarative-agent manifest — pin the schema version (v1.8), keep instructions within the ~8,000-char budget, declare only the needed capabilities, write scope-demonstrating conversation starters, wire API actions, and pass manifest + Responsible-AI validation against the 50/25/4096/45s hard-limit wall. Use when building or reviewing a declarative agent. |
| `oversharing-remediation-playbook` | `microsoft-365-copilot` | Remediate Microsoft 365 oversharing BEFORE enabling Copilot — assess the blast radius, then run the sequence (RCD/RSS reach-reduction → Purview sensitivity labels + DLP-for-Copilot → site/permission cleanup → enable), framing RSS/RCD as reach-reduction and NOT a security boundary, with owners, verification, comms, and rollback. Use when planning a Copilot rollout over a tenant with uncertain permissions. |
| `capacity-sizing-and-isolation` | `microsoft-fabric` | Playbook for sizing Fabric capacity SKUs, isolating noisy workloads across capacities, configuring surge protection and smoothing, and diagnosing throttling — the FinOps and operations companion to the capacity-finops knowledge file. |
| `direct-lake-gold-shaping` | `microsoft-fabric` | Playbook for shaping OneLake gold Delta tables to serve a Direct Lake semantic model efficiently — covers framing prerequisites, column naming rules, fallback prevention, and the on-OneLake vs on-SQL mode selection. |
| `fabric-alm-promotion` | `microsoft-fabric` | Playbook for promoting Fabric workspace items from dev to test to prod using Git integration, deployment pipelines, and the Fabric CLI — covers branch strategy, metadata-only deploys, and the pre-promotion checklist. |
| `fabric-ingestion-method-selection` | `microsoft-fabric` | Decision playbook for choosing the right Fabric data ingestion method — Mirroring, Copy job, pipeline Copy activity, Dataflow Gen2, or Eventstream — based on source type, latency, cost, and CDC requirements. |
| `medallion-layer-design` | `microsoft-fabric` | Playbook for designing bronze/silver/gold medallion layers on OneLake — per-layer V-Order, file-size targeting, partitioning vs Liquid Clustering, deletion vectors, and materialized lake view decisions. |
| `batch-request-design` | `microsoft-graph` | Playbook for consolidating multiple Microsoft Graph API calls into a single $batch request — request shaping, dependency ordering, error handling per-response, and the throttling interaction that makes batching both necessary and tricky. Owned by graph-api-engineer. |
| `delta-query-and-change-notifications` | `microsoft-graph` | Playbook for tracking Microsoft Graph resource changes using delta queries (polling) and change notifications (webhooks/subscriptions) — choosing between them, bootstrapping delta tokens, handling subscription lifecycle, and the rich-notification decryption hand-off. Owned by graph-workloads-engineer. |
| `odata-query-builder` | `microsoft-graph` | Playbook for constructing well-shaped Microsoft Graph OData queries: $select, $filter, $expand, $search, $count, $orderby, $top, $skip, the ConsistencyLevel header for advanced queries, and the common 400-error patterns. Owned by graph-api-engineer. |
| `permission-least-privilege-review` | `microsoft-graph` | Step-by-step playbook for auditing a Microsoft Graph app's permission scope list: delegated vs application decision, narrowing over-broad scopes, finding resource-scoped alternatives, and the escalation criteria for ravenclaude-core/security-reviewer. Owned by graph-identity-engineer. |
| `throttling-backoff-handler` | `microsoft-graph` | Playbook for designing a correct Graph API throttling (HTTP 429) response handler: reading Retry-After, exponential backoff with jitter, per-resource throttle budgets, and the SDK built-in retry middleware that makes hand-rolling unnecessary for most cases. Owned by graph-api-engineer. |
| `computer-vision-pipeline` | `ml-engineering` | Run the computer-vision MLOps lane end to end: data/annotation -> CV task -> architecture choice -> training (transfer-learn first) -> eval by task (mAP/IoU/CER/OKS) -> serving/edge placement. CV-specific leakage (scene-aware split, augment-after-split). Seams back to training/serving/monitoring agents. |
| `feature-store-consistency` | `ml-engineering` | Prevent training-serving skew: compute features once via a feature store or shared transformation so training and serving use identical logic, with point-in-time correctness for temporal features and no leakage of future data. |
| `ml-experiment-tracking` | `ml-engineering` | Playbook for setting up and operating an experiment tracking system (MLflow or Weights and Biases) — what to log, run comparison workflow, promotion to the model registry, and avoiding the common leakage and cherry-picking pitfalls. |
| `model-monitoring` | `ml-engineering` | Keep production models honest: monitor input/data drift, prediction/concept drift, and performance decay (when labels arrive); define the retraining trigger up front (schedule/threshold/drop); alert on model health; and close the loop to retraining. |
| `model-serving` | `ml-engineering` | Serve models reliably: choose online vs batch by the use case, deploy a versioned model from the registry, optimize latency to a budget (batching/quantization/distillation/hardware), and roll out safely with shadow -> canary -> full. |
| `reproducible-training` | `ml-engineering` | Build reproducible training: a versioned prep->train->evaluate->register pipeline (not a notebook), experiment tracking (params/metrics/code/data/env), a model registry as source of truth, and leakage-free time-aware validation. |
| `android-craft` | `mobile-engineering` | Build native Android the platform way: state-driven Jetpack Compose (state hoisting, remember, list keys), coroutines/Flow with lifecycle-scoped structured concurrency, Keystore/EncryptedSharedPreferences, WorkManager background respecting Doze, and Material + accessibility. |
| `app-store-release-pipeline` | `mobile-engineering` | Step-by-step guide for automating the iOS App Store and Google Play release pipeline — code signing, build automation with Fastlane, TestFlight and internal track distribution, phased rollout, and the common pipeline failure modes. |
| `cross-platform-mobile` | `mobile-engineering` | Build React Native/Flutter well: maximize shared logic while honoring per-platform conventions, manage the bridge/platform-channel native boundary (and write native modules when needed), avoid framework-specific performance pitfalls, and handle push/deep-links/offline once with secrets in the secure store. |
| `ios-craft` | `mobile-engineering` | Build native iOS the platform way: state-driven SwiftUI with correct property-wrapper ownership, Swift Concurrency (async/await, actors, @MainActor), Keychain secure storage, lifecycle/background-task handling, and Human Interface Guidelines + accessibility. |
| `mobile-platform-choice` | `mobile-engineering` | Decide native vs React Native vs Flutter by the app's real needs (platform-specific UX, performance, OS-feature access, team), and set the offline-first sync strategy (local source of truth, write queue, conflict resolution) and lifecycle-survival plan. |
| `diagnose-pullthrough` | `mortgage-lending` | Diagnose application-to-funded fall-out stage-by-stage and name the worst fallout stage — fix it before buying more apps. Reach for this on a pull-through question. |
| `frame-pipeline-risk` | `mortgage-lending` | Tie fallout assumptions to locked-pipeline exposure and frame the lock/pipeline risk — route the hedge to the risk authority. Reach for this on a lock or rate-risk question. |
| `model-cost-to-originate` | `mortgage-lending` | Compute cost-to-originate (fixed + variable per loan) and the breakeven volume that the rate swing must clear. Reach for this on a unit-economics question. |
| `route-compliance` | `mortgage-lending` | Frame operational compliance workflow and QC/defect signals — and route every TRID/ECOA/HMDA/fair-lending determination to counsel. Reach for this on a compliance or audit-readiness question. |
| `size-cycle-capacity` | `mortgage-lending` | Measure app-to-close cycle, find the bottleneck stage, and size processor/LO capacity as a function of cycle — staff to the cycle, not a ratio. Reach for this on a cycle or staffing question. |
| `grow-membership-and-visitor-revenue` | `museum-cultural-institution-operations` | Design the museum's earned-and-contributed revenue engine — the admissions/pricing model (timed ticketing / dynamic / pay-what-you-wish / free-admission, with the access-vs-revenue trade-off modeled), a tiered membership program built for behavior with an acquisition-and-renewal/retention engine (first-year renewal focused), the development levers (patron cultivation, corporate sponsorship, galas), and a named earned-vs-contributed revenue-mix target with its levers. Reach for this when the user asks "timed/dynamic/free admission?", "design our membership tiers and renewal program", "grow venue-rental/retail earned revenue", or "what's a healthy earned-vs-contributed mix?". Used by `museum-operations-lead` (primary). |
| `manage-collections-and-exhibitions` | `museum-cultural-institution-operations` | Steward a collection and build the exhibitions it feeds — run the accession/deaccession ethics gate (AAM/AAMD; deaccession proceeds fund collection care/acquisition only), cataloging, provenance & NAGPRA due diligence, condition reporting, loans in/out, insurance/valuation, storage & environmental controls, the collections-CMS fit (TMS/Axiell/PastPerfect/CollectionSpace), and the exhibition project lifecycle (concept → checklist & loans → interpretation → budget → schedule → install/condition → evaluation). Reach for this when the user asks "should we accession/deaccession this?", "run the provenance/NAGPRA due diligence", "TMS vs Axiell vs PastPerfect vs CollectionSpace?", or "plan this temporary/traveling exhibition". Used by `collections-and-engagement-specialist` (primary). |
| `publish-digital-collections-and-access` | `museum-cultural-institution-operations` | Publish a collection online, rights- and cultural-sensitivity-cleared — run the copyright/rights gate and the source-community consultation, decide open-access vs restricted (CC0/CC-BY vs a rights-restricted license, with rights statements), and stand up the IIIF image/presentation stack + DAMS + online catalog + virtual exhibitions, defaulting toward openness where rights allow while cultural sensitivity gates the publish button. Reach for this when the user asks "publish our collection online", "open access or not?", "set up IIIF for our images", or "can we put this culturally sensitive material online?". Used by `collections-and-engagement-specialist` (primary). |
| `design-network-topology` | `network-engineering` | Design a campus/datacenter/branch/WAN network topology by traversing the topology decision tree (scale -> traffic pattern -> redundancy need -> topology), then return the recommended topology (collapsed-core vs 3-tier vs spine-leaf vs hub-and-spoke/SD-WAN), an IP addressing plan (summarizable, room to grow), the redundancy/failure model (HSRP/VRRP, dual-homing, MLAG), and a labelled diagram description. Reach for this when the user asks to "design the network for <site/DC>". Used by `network-architect` (primary). |
| `design-segmentation-and-zero-trust` | `network-engineering` | Design network segmentation and a zero-trust network access posture by traversing the segmentation decision tree (what to isolate -> blast radius -> enforcement point -> identity model), then return the segment plan (VLANs/VRFs/microsegmentation), the east-west + north-south policy model, the NAC/802.1X posture, and the SASE/SD-WAN or firewall enforcement point. Reach for this when the user asks "how do we segment <IoT/OT/guest/PCI> off the network?". Used by `network-architect` (primary); security verdicts escalate to security-engineering. |
| `plan-network-change` | `network-engineering` | Turn a network change (routing/VLAN/firewall/cutover) into a staged, reversible plan — blast-radius assessment, change window, pre-checks (baseline), the staged steps with verification gates, and a tested rollback — so no change is a big-bang gamble. Reach for this when the user needs to make a risky network change safely or migrate/cut over network infrastructure. Used by `network-operations-engineer` and `network-architect`. |
| `select-routing-protocol` | `network-engineering` | Choose the right routing protocol (static, OSPF, EIGRP, IS-IS, BGP) for a given boundary and scale by traversing the routing-protocol decision tree (administrative boundary -> scale -> multi-vendor -> convergence/policy need), then return the recommendation, the design knobs (OSPF areas, BGP ASNs/route-reflectors/communities, summarization), and why the alternatives were ruled out. Reach for this when the user asks "OSPF vs BGP vs static between <X>?". Used by `network-architect` (primary). |
| `troubleshoot-connectivity` | `network-engineering` | Isolate a network connectivity fault methodically, bottom-up the OSI stack (L1 link -> L2 VLAN/ARP/MAC -> L3 routing/ACL -> L4 port/firewall -> L7 DNS/app), naming the specific isolating test and confirming command at each layer, then return the ranked most-likely fault and how to confirm it. Reach for this when the user says "X can't reach Y" or reports intermittent/slow connectivity. Used by `network-operations-engineer` (primary). |
| `grant-postaward-compliance` | `nonprofit-fundraising` | Manage a grant AFTER the award — set up, spend only on allowable/allocable/reasonable costs, track budget-vs-actual monthly, report on cadence, stay audit-ready through close-out. Reach for this once a grant is won (the post-award/compliance side; the pre-award qualify→write side is qualify-the-funder). |
| `protect-donor-retention` | `nonprofit-fundraising` | Read donor retention by cohort and fix the leaky bucket before pouring in acquisition, since retention is ~7x cheaper than acquisition. Reach for this on any growth question. |
| `qualify-the-funder` | `nonprofit-fundraising` | Score a grant opportunity on funder fit before writing, so effort goes where alignment is. Reach for this before any proposal. |
| `read-cost-per-dollar` | `nonprofit-fundraising` | Compute cost-to-raise-a-dollar per channel, never blended, so the subsidizing channel is visible. Reach for this on a portfolio/efficiency question. |
| `run-the-cultivation-cycle` | `nonprofit-fundraising` | Move a donor through identification, qualification, cultivation, solicitation, and stewardship rather than jumping to the ask. Reach for this on a major-gift prospect. |
| `segment-the-donor-base` | `nonprofit-fundraising` | Segment donors by value, recency, and engagement (RFM-style) to direct cultivation hours where they pay. Reach for this when cultivation is spread thin. |
| `alerting-rule-design` | `observability-sre` | Playbook for writing alerts that page on user-visible symptoms using multi-window multi-burn-rate rules — covering threshold selection, alert fatigue reduction, and runbook requirements. |
| `chaos-engineering` | `observability-sre` | Verify resilience proactively with chaos experiments — a steady-state hypothesis, a controlled fault injection, a blast-radius limit, and a game day — instead of waiting for the real outage. Reach for this to prove (not assume) a system tolerates failure. |
| `incident-response` | `observability-sre` | Run an incident and learn from it: declare + classify severity, split IC/comms/ops roles, communicate on a cadence, mitigate before root-causing, and write a blameless postmortem with owned, dated action items. |
| `opentelemetry-instrumentation` | `observability-sre` | Instrument a service with OpenTelemetry: OTLP export, semantic conventions, the key spans and metrics, a sampling strategy (head vs tail), cardinality control, and trace/log correlation via propagated context. |
| `postmortem-facilitation` | `observability-sre` | Blameless postmortem facilitation guide — timeline reconstruction, five-whys causal analysis, contributing factor classification, and action item extraction with owners and due dates. |
| `slo-and-error-budgets` | `observability-sre` | Design SLIs/SLOs and an error-budget policy: pick user-centric indicators, set targets by user need (not 100%), define the ship-vs-freeze budget rule, and enforce with multi-window multi-burn-rate alerts. |
| `slo-definition-workshop` | `observability-sre` | Guided workshop playbook for defining SLIs and SLOs with engineering and product — produces a complete SLO document with error budget, burn-rate alert thresholds, and a budget policy. |
| `choose-an-open-source-license` | `open-source-maintenance` | Recommend an open-source license for a project from its intent (permissive adoption vs reciprocal sharing), its dependency-license graph (the strongest copyleft constrains the whole), and its contribution-agreement need (CLA vs DCO vs neither). Returns a license recommendation, the LICENSE/NOTICE files to add, and the contribution posture. Used by `oss-maintainer-strategist` (primary). |
| `coordinate-a-security-release` | `open-source-maintenance` | Run a coordinated security release for a privately-reported vulnerability — private fix branch, GHSA/CVE assignment, patched versions on every supported line, an advisory, and disclosure timing. Returns the coordinated-release runbook and the advisory skeleton. The vulnerability ANALYSIS routes to security-engineering; this skill owns the release choreography. Shared by both agents. |
| `manage-breaking-changes-and-deprecations` | `open-source-maintenance` | Ship a breaking change without stranding users — run a deprecation lifecycle (warn -> window -> remove), author a migration guide, and pair the removal with a major bump and a BREAKING changelog note. Returns the deprecation plan, the migration guide skeleton, and the support-window statement. Used by `release-and-versioning-engineer` (primary). |
| `plan-a-release` | `open-source-maintenance` | Plan a release end to end — decide the semver bump from the change set, assemble a human-readable changelog (Keep a Changelog groups), and run a release checklist (tests green, version bumped, tag signed, artifact + provenance, advisory if needed). Returns the version, the changelog entry, and the release runbook. Used by `release-and-versioning-engineer` (primary). |
| `triage-issues-and-prs` | `open-source-maintenance` | Turn an unbounded issue/PR backlog into a tractable system — a label taxonomy, SLA tiers, a reproduction gate for bugs, a stale policy, and a graceful decline path. Returns a TRIAGE policy, issue/PR templates, and label definitions. Prevents the silent-backlog burnout the project exists to avoid. Used by `oss-maintainer-strategist` (primary). |
| `eligibility-and-claims` | `optometry-eyecare-practice` | Run the eye-care claims loop: verify both medical and vision eligibility before the visit, manage payor mix, and triage denials by cause (eligibility, coding/medical-necessity, wrong-payor-routed, timely-filing). Payor specifics are verify-at-use. |
| `exam-flow-and-pretesting` | `optometry-eyecare-practice` | Engineer the exam lane: pretesting/workup done by a tech before the doctor enters, a workup-to-doctor handoff that protects chair time, and a tech-to-doctor ratio that lets one doctor run multiple lanes. Protect the scarcest resource — the doctor's chair. |
| `medical-vs-vision-billing` | `optometry-eyecare-practice` | Route an eye-care visit to medical insurance vs the vision plan deliberately, on the chief complaint and what the visit addressed. Code to the encounter, document medical necessity for medical claims, and flag every payor/coding specific verify-at-use. |
| `optical-capture-and-dispensary` | `optometry-eyecare-practice` | Run the optical for profit: track and lift the capture rate (eyes examined -> Rx written -> Rx filled in your optical), run the frame board on inventory turns, manage the lab pipeline, and dispense within managed-vision-care formularies knowingly. |
| `schedule-and-recall-management` | `optometry-eyecare-practice` | Build the eye-care schedule off recall: set recall/recare intervals by exam type, template exam-length to exam-type, and read capacity as lanes x exam length x fill rate. Recall, not walk-ins, is the primary schedule-filler. |
| `build-a-partner-tiering-model` | `partnerships-alliances` | Design partner tiers that trade concrete obligations (certs, pipeline, capacity) for concrete benefits (margin, MDF, leads) — not a logo wall. Reach for this when standing up or fixing a partner program. |
| `design-an-mdf-program` | `partnerships-alliances` | Design market-development funds as a measured investment tied to a plan and an ROI floor — not a channel rebate nobody tracks. Reach for this when standing up or fixing MDF/co-op funds. |
| `size-partner-sourced-pipeline` | `partnerships-alliances` | Size partner-sourced vs partner-influenced pipeline with a defined attribution rule, so the program number is one finance trusts and nothing is double-counted with direct. Reach for this before any partner-revenue claim. |
| `structure-a-co-sell-motion` | `partnerships-alliances` | Build a co-sell motion around a named rep-to-rep play — mapped account overlap, a joint value proposition, and a shared incentive — not a 'we'll co-sell' press release. Reach for this when activating an alliance. |
| `craft-candidate-materials` | `people-operations-hr` | Craft honest candidate materials — resume, LinkedIn Experience, LinkedIn About, cover letter, recruiter paste pack — as DIGEST + paste paths under /workspace. Reach for this when packaging Matthew (or fleet user) for a role; never invent metrics; Raven/current role present tense only; CoS does not own prose. |
| `design-comp-bands` | `people-operations-hr` | Design defensible comp bands tied to leveling and dated market data — set midpoints/spreads, compute compa-ratio and range penetration, surface over/under-band outliers. Reach for this on a banding or offer question. |
| `diagnose-attrition` | `people-operations-hr` | Diagnose an attrition spike with cost and cause — split regretted from non-regretted, localize to team/manager, price the loss, name the driver. Reach for this on a retention question. |
| `model-hiring-plan` | `people-operations-hr` | Model a capacity-tied hiring plan — back-solve the funnel pipeline for target hires, flag the leaking stage, size recruiter capacity, and hand off the comp envelope. Reach for this on a hiring-plan or stuck-req question. |
| `read-engagement-signals` | `people-operations-hr` | Read an engagement survey segmented — surface the team/tenure/manager pockets a company-wide eNPS hides and tie them to forward attrition risk. Reach for this on an engagement-survey question. |
| `run-pay-equity-review` | `people-operations-hr` | Run a pay-equity review that controls for legitimate factors — compute the raw gap, then the residual after level/role/tenure/location/performance, and route a material residual to counsel. Reach for this on a pay-equity question. |
| `load-test-design` | `performance-engineering` | Design the load/stress/soak/spike test from a modeled workload: pick the open- vs closed-model executor deliberately, design ramping and think time, generate realistic owned test data, avoid coordinated omission, and assert thresholds in-script — tool-neutral across k6/Gatling/Locust/JMeter. |
| `performance-test-strategy` | `performance-engineering` | Set the performance strategy before testing: turn vague goals into falsifiable NFRs (percentile + threshold + load), model the real workload, link targets to the customer SLO, and choose the test type (load/stress/soak/spike) that answers the open question. |
| `profiling-and-bottleneck-triage` | `performance-engineering` | Localize the bottleneck and size the system: CPU/memory/IO profiling and flame graphs, USE/RED triage to name the constraining resource, capacity planning with headroom via Little's law and the measured saturation point, and regression detection against a committed baseline. |
| `balance-inventory` | `pharmacy-operations` | Read days-on-hand as tied-up cash vs stockout risk by class, handling specialty/340B/refrigerated distinctly. Reach for this on an inventory question. |
| `compute-real-margin` | `pharmacy-operations` | Compute reimbursement minus acquisition cost minus DIR fees per script and flag negative-margin scripts the sticker hid. Reach for this on a margin question. |
| `protect-dispensing-safety` | `pharmacy-operations` | Read dispensing-error rate as the top operational safety + liability signal and connect it to throughput/staffing pressure — routing the clinical judgment out. Reach for this on a safety or error-rate question. |
| `size-throughput-staffing` | `pharmacy-operations` | Size technician and pharmacist hours against script volume PLUS clinical-service time, holding verification safety as the constraint. Reach for this on a throughput or staffing question. |
| `translate-adherence` | `pharmacy-operations` | Measure PDC/MPR over the measurement period and translate the adherence band into the star-rating and reimbursement implication. Reach for this on an adherence or star-measure question. |
| `defensible-documentation` | `physical-therapy-rehab-clinic` | Write and review defensible PT/rehab daily notes and evaluations — establishing medical necessity every visit, documenting skilled care as skilled, tying each note to a plan-of-care goal, and avoiding boilerplate that invites a denial or audit finding. |
| `denial-prevention-and-appeals` | `physical-therapy-rehab-clinic` | Prevent PT/rehab claim denials at the front end (eligibility, authorization, units, modifiers, documentation) and triage the ones that slip through to their root cause, then write a documentation-grounded appeal — confirming each payor's edits before billing. |
| `plan-of-care-management` | `physical-therapy-rehab-clinic` | Manage the PT/rehab plan of care end to end — goals, frequency/duration, certification, and the recertification clock — so the POC stays signed and current, visits trace to goals, and a lapsing certification is re-booked before it invalidates visits. |
| `schedule-and-capacity-planning` | `physical-therapy-rehab-clinic` | Plan outpatient PT/rehab clinic capacity and the schedule template against committed plan-of-care visit cadence, provider hours, patient flow, and the measured no-show/cancellation rate — so provider hours become completed, billable visits. |
| `therapy-billing-and-units` | `physical-therapy-rehab-clinic` | Calculate PT/rehab billable units correctly: separate timed (time-based, 15-min) from untimed (service-based) CPT codes, apply the 8-minute rule to total timed units, and place GP/KX/59 modifiers — confirming the payor's rule variant before billing. |
| `classify-dora` | `platform-engineering-idp` | Compute the four DORA keys and classify the org against the bands with windows and baselines. Reach for this on a DevEx-measurement question. |
| `design-golden-path` | `platform-engineering-idp` | Design a paved road that is the lowest-friction compliant option, with self-service actions and guardrails. Reach for this on a paved-road question. |
| `measure-adoption` | `platform-engineering-idp` | Read adoption as teams-on-golden-path ÷ total, name the gap, and segment the un-adopted teams. Reach for this on an adoption question. |
| `quantify-toil` | `platform-engineering-idp` | Quantify manual toil and the automation ROI in engineer-hours per year. Reach for this on an automate-or-not question. |
| `set-platform-slos` | `platform-engineering-idp` | Define platform SLIs/SLOs and an error budget that gates platform change. Reach for this on a platform-reliability question. |
| `alm-pipeline-design` | `power-platform` | Design end-to-end ALM pipelines for Power Platform solutions — pac CLI primitives, Azure DevOps multi-stage pipelines, source-control unpacked solutions, env-var + connection-reference promotion across DEV → TEST → UAT → PROD, managed-vs-unmanaged discipline. Used by `solution-alm-engineer` (primary). |
| `canvas-app-performance` | `power-platform` | Diagnose and fix Power Fx canvas app performance — delegation as a P1 design constraint, lazy-load patterns, Concurrent() vs sequential, ClearCollect vs collection growth, OnStart vs OnVisible, screen-transition cost, control-count budgets per screen, and the connector-call audit via Monitor. Used by `power-fx-engineer` (primary). |
| `code-review` | `power-platform` | Deep code audit that finds dead wiring, silent failures, unfinished features, placeholder stubs, bloated files, and unnecessary complexity. Produces an actionable report with file:line references grouped by severity. Think of it as a senior dev doing a thorough PR review of the entire codebase. Triggers on: "code review", "audit the code", "review the code", "find dead code", "find placeholders", "check for stubs", "prune the code", "code cleanup", "implementation review", "completeness check", "find unused code". |
| `copilot-studio-bot-design` | `power-platform` | Design Copilot Studio bots — topic vs generative-answers boundaries, knowledge-source hygiene, trigger-phrase design, slot-filling patterns, escalation-to-human criteria, AI Builder vs prompt-flow vs direct Azure OpenAI decisions, and the test-set discipline that catches regressions on every authoring change. Used by `copilot-studio-engineer` (primary). |
| `dataverse-payload-preflight` | `power-platform` | Validate a Dataverse create/update payload against LIVE entity metadata in ONE pass — before you POST/PATCH — so you never fix-one-field-and-retrigger. Catches nonexistent columns, invalid option-set values, malformed/missing lookup binds, missing required fields, and the owner-not-provided (SPN-create) trap together. Run it on the FIRST create failure, or up front when a human re-fire or long run gates each test. |
| `dataverse-plugins` | `power-platform` | Use when developing, registering, or deploying Dataverse plugins (C# server-side extensions). Covers the IPlugin interface, execution pipeline stages, entity images, common patterns (auto-numbering, cascading updates, validation), and registration/deployment. Triggers on: "plugin", "server-side logic", "business logic", "auto-number", "cascading update", "pre-operation", "post-operation", "plugin registration", "IPlugin", "execution pipeline", "plugin trace", "InvalidPluginExecutionException", "PreValidation", "PostOperation". |
| `dataverse-web-api` | `power-platform` | Use when programmatically creating, modifying, or querying Dataverse schema and metadata via the Web API (OData v4.0). Covers table/column/relationship definitions, solution ALM, form and view XML construction, app module composition, global option sets, business rules, Custom API registration, and publishing. Triggers on: "dataverse api", "dataverse metadata", "entitydefinitions", "web api schema", "create dataverse table", "create dataverse column", "fetchxml", "formxml", "layoutxml", "dataverse solution", "dataverse relationship", "odata dataverse", "metadata api", "publish customizations", "dataverse alm", "grid control", "editable grid", "business rule", "rich text", "auto-number", "file column", "image column", "pcf control", "security role", "column security", "environment variable", "custom api", "data migration", "solution import". |
| `dataverse-web-resources` | `power-platform` | Use when creating, deploying, or managing Dataverse web resources for model-driven apps. Covers JavaScript form scripts (OnLoad, OnSave, OnChange events), HTML dashboard pages, CSS styling, image resources, navigation/side panes, ribbon/command bar customization, business process flow client API, and deployment via the Web API. Triggers on: "web resource", "javascript form", "form script", "html dashboard", "ribbon command", "onload event", "onchange event", "onsave event", "formContext", "Xrm.WebApi", "web resource deployment", "dashboard page", "form event handler", "side pane", "command bar", "ribbon", "modal dialog", "navigation", "Xrm.App", "Xrm.Navigation", "business process flow", "bpf", "stage change". |
| `dlp-policy-design` | `power-platform` | Design tenant Data Loss Prevention policies for Power Platform — business / non-business / blocked classification, environment-scoped vs tenant-wide policies, exemption process, common-connector pitfalls (HTTP, SharePoint, Dataverse, custom connectors), and the "every flow gets re-evaluated on policy change" implication. Used by `power-platform-admin` (primary). |
| `grounding-protocol` | `power-platform` | Reduce confident-but-incorrect "I can't do that" claims by forcing agents to verify capabilities before refusing scope. Mandatory checklist covers skills review, alternate-methods enumeration, team-composition check, and escalation phrasing. Inherited by every Power Platform agent. |
| `maintainability-review` | `power-platform` | Forward-looking maintainability + evolvability review of a Power Platform solution — understandability, modifiability, testability, evolution readiness, ownership. Used before major releases, handoffs, when inheriting an existing solution. |
| `managed-solution-import` | `power-platform` | Hardened pac solution import plus explicit baseline-aware cloud-flow reactivation for SPN-driven CI/CD — preflight, baseline, import, reactivate, verify. Managed imports leave flows Draft when the importing identity lacks connection permission; this reactivates only flows that were Active, splits transient vs durable 403s, and verifies state. Run on any managed import to TEST/PROD, or use reactivate/verify standalone. |
| `pbir-ref-integrity` | `power-platform` | Report-wide referential-integrity validator for a PBIR Enhanced report's `definition/` tree. Deterministic, stdlib-only `check_refs.py` that catches DANGLING cross-file references — bookmarks pointing at deleted pages/visuals, `visualInteractions` naming visuals that no longer exist, a `pageOrder` that omits/invents/duplicates a page, an `activePageName`/`activeSection` that names a missing page, and report-wide visual-name collisions. Mimics the referential-integrity half of pbir-utils `validate`/`sanitize` and pbir.tools `validate`. Complements (does NOT duplicate) ravenclaude-core's single-page `pbir-layout-engine`. Owned by `power-bi-engineer`. |
| `pcf-controls` | `power-platform` | Use when building, deploying, or using PowerApps Component Framework (PCF) controls. Covers field controls and dataset controls, React virtual controls, control lifecycle, manifest configuration, solution packaging, and deployment. Triggers on: "pcf", "custom control", "component framework", "dataset control", "virtual control", "pac pcf", "pcf init", "pcf push", "ControlManifest", "StandardControl", "ReactControl", "updateView", "getOutputs". |
| `plan-with-team` | `power-platform` | Spawns an Agent Team to collaboratively plan Power Platform / Dataverse applications. Three specialists (Data Architect, UX Designer, The Skeptic) debate and refine the plan before any code is written. Falls back to structured single-agent planning if agent teams are not enabled. Triggers on: "plan my app", "plan with team", "design my app", "architect this app", "plan the schema", "team planning", "agent team plan", "plan power app", "plan dataverse app", "design the data model". |
| `power-apps-code-apps` | `power-platform` | Use when building, scaffolding, debugging, or deploying Microsoft Power Apps Code Apps using React, Vue, or TypeScript in VS Code. Handles project initialization via pac CLI, Dataverse and connector data access via the @microsoft/power-apps SDK, power.config.json configuration, Vite build pipelines, and deployment to Power Platform environments. Triggers on: "power apps", "code app", "pac code", "dataverse", "power platform app", "vibe coding", "scaffold power app", "deploy code app". |
| `power-automate` | `power-platform` | Veteran-level reference for Power Automate work — expressions, error handling + scopes, child flows, solution-aware flows + connection references, Dataverse triggers, throttling, approvals, performance patterns. Used by `flow-engineer` (primary) and any agent touching flows. |
| `power-bi` | `power-platform` | Veteran-level reference for Power BI — PBIP project structure + git, semantic model design, DAX patterns + performance, deployment pipelines, refresh / gateway troubleshooting, integration with Power Platform solutions / ALM. Used by `power-bi-engineer` (primary). |
| `power-pages-permissions` | `power-platform` | Design table permissions, web roles, and authentication for Power Pages — anonymous vs authenticated patterns, B2C / Entra-External-ID auth, table-permission scoping (global / contact / account / parental / self), record ownership, and the "row I can see in MDA but not in Pages" debugging playbook. Used by `power-pages-engineer` (primary). |
| `record-screen` | `power-platform` | Record a Chrome browser tab to video via CLI. Use when the user wants to capture a screen recording of a browser tab. Supports list, start, stop, caption, and status subcommands. No debug mode required — uses a Chrome extension. |
| `report-visualization-design` | `power-platform` | Design a Power BI report/visualization in the Kurt-Buhler / Bas-Dohmen mold — a checklist-driven method: decide the question first, structure the page with the 3-30-300 information-seeking hierarchy, choose the visual by question-type, design headline KPIs with actual/target/gap + pre-attentive color, lay everything on an 8-pt grid, and tune density / color tokens / accessibility. Emits a layout that maps cleanly onto PBIR (visualType enum + pbir-layout-engine geometry). Used by `power-bi-engineer` (primary). |
| `update-model-driven-app` | `power-platform` | Use when an agent must PROGRAMMATICALLY UPDATE an existing model-driven Power Apps app (including its custom pages) in a real Power Platform environment — typically reusing a service principal (SPN). Owns the "there has to be a way" question: it splits the update surface (record/config data · the model-driven solution shell · custom pages) into the right mechanism per surface, front-loads the SPN-rights + environment-policy gates, and enforces the non-obvious safety facts (canvas .pa.yaml is read-only, unmanaged solution import is irreversible, pack exit-0 ≠ success). Triggers on: "update the app in my power platform environment", "change the model-driven app programmatically", "edit a custom page with code / headless", "push a solution change via pac / SPN", "claude update power apps", "update sitemap / form / view via the API", "import solution service principal". |
| `visual-qa` | `power-platform` | AI-powered visual QA testing that walks through an app in the browser, records every action with annotated captions (what was done, what should happen), captures screenshots/GIFs, and sends the evidence to Gemini for automated review. Catches UX misalignments, broken flows, missing states, and edge cases that traditional tests miss. Can use Agent Teams for parallel test coverage. Triggers on: "visual test", "visual qa", "test the app", "qa review", "check the ui", "record a test", "walk through the app", "e2e test", "end to end test", "catch edge cases", "gemini review", "screen test", "ux test", "visual regression". |
| `build-fertility-from-data` | `precision-agriculture` | Build the fertility program from current soil/tissue data and removal rates, not last year's program, so neither over- nor under-application costs margin. Reach for this on a fertility question. |
| `build-per-acre-economics` | `precision-agriculture` | Build cost and margin per acre by field so the money-losing acres are visible. Reach for this on any margin question. |
| `manage-by-zone` | `precision-agriculture` | Read yield and soil by management zone and apply variable-rate inputs where they pay, instead of a field average. Reach for this on a yield or input question. |
| `optimize-input-economics` | `precision-agriculture` | Set input rates at the economic optimum where marginal return equals marginal cost, not at agronomic maximum, so the last unit pays. Reach for this on any input decision. |
| `time-the-operations` | `precision-agriculture` | Time planting, application, and harvest to the agronomic and weather window, since timing drives yield and quality more than rate. Reach for this on an operations-timing question. |
| `packaging-and-tiering` | `pricing-monetization` | Design good-better-best packaging where each tier is fenced by a self-selection dimension (scale, use case, support, security) rather than a longer feature list, and separate core from add-ons. Reach for this when turning a feature set into tiers, when customers all pick the cheapest plan, or when tiers differ only by feature count. Pairs with value-metric-design. |
| `price-change-rollout` | `pricing-monetization` | Plan a price change as a migration, not an edit — grandfathering, cohort sequencing, renewal-timing, comms, and the guardrail metrics (GRR, contraction, leakage, win-rate) to watch. Reach for this when raising prices, repackaging, migrating models (e.g. seat to usage), or simplifying a price card. Pairs with packaging-and-tiering and the price-change-rollout-plan template. |
| `pricing-model-selection` | `pricing-monetization` | Choose the pricing model — subscription, per-seat, usage/consumption, tiered, flat-rate, freemium, or hybrid — by tracing the value of the product against consumption variance and acquisition needs. Reach for this when a product needs its first model, when a per-seat model is capping growth, or when an AI/usage-cost feature breaks the existing model. Pairs with value-metric-design (decide the metric alongside the model). |
| `value-metric-design` | `pricing-monetization` | Choose the value metric — what you charge per (seats, usage units, records, transactions, outcomes) — the single highest-leverage pricing decision. Reach for this when a product's metric caps growth, when expansion isn't automatic, or before setting any price number. Scores candidate metrics on value-alignment, expansion-with-success, and budget-predictability. |
| `willingness-to-pay-research` | `pricing-monetization` | Design a willingness-to-pay study — Van Westendorp PSM, Gabor-Granger, conjoint/MaxDiff, or a live price A/B test — choosing the method by the decision it serves and the data available, with sample-frame and bias guards. Reach for this before setting a price number, when defending a price, or when stated WTP and behavior disagree. Routes statistical significance to applied-statistics. |
| `control-plan-and-sustain` | `process-improvement` | Lock the gain after an improvement: build the control plan, design SPC monitoring, write standard work, add poka-yoke (mistake-proofing), define the reaction plan, and hand off to the process owner. A fix without a control plan didn't happen. |
| `dmaic-project-charter` | `process-improvement` | Scope an improvement opportunity as a DMAIC project: problem statement, quantified goal, CTQ/VOC, SIPOC boundaries, baseline metric, team, and timeline. Produces a populated charter using the dmaic-project-charter template. |
| `lean-waste-analysis` | `process-improvement` | Find and remove waste using the 8 wastes (DOWNTIME), value-add analysis, takt/cycle time comparison, bottleneck/constraint identification, and quick-win prioritization. Feeds the DMAIC Improve phase with a ranked elimination roadmap. |
| `process-capability-and-spc` | `process-improvement` | Baseline a process: compute DPMO/sigma level and Cp/Cpk, select and read the right control chart (I-MR / Xbar-R / p / c / u), and apply Western Electric/Nelson rules to separate common-cause from special-cause variation. Routes deeper capability inference and hypothesis testing to applied-statistics. |
| `process-mapping` | `process-improvement` | Build the current-state process map: SIPOC, swimlane/flowchart, and value-stream map. Mark value-add vs. non-value-add steps and handoffs. Identify where to instrument and measure. Used in the DMAIC Measure phase before root-cause analysis begins. |
| `root-cause-analysis` | `process-improvement` | Drive to proven root cause using 5 Whys, fishbone/Ishikawa (6M categories), and Pareto (80/20 prioritization), then validate the suspected cause with data. Routes hypothesis testing to applied-statistics. Anti-pattern: solution-jumping before cause is proven. |
| `build-the-spend-cube` | `procurement-sourcing` | Build and classify the spend cube by category, supplier, and business unit, surfacing tail spend, so strategy rests on visibility. Reach for this when spend is opaque. |
| `manage-supplier-risk` | `procurement-sourcing` | Assess supplier and concentration risk across the base and mitigate single-source exposure, instead of a one-time checkbox. Reach for this on a continuity question. |
| `segment-the-spend` | `procurement-sourcing` | Place a category on the supply-risk × spend matrix and match the sourcing play before sourcing, so you don't auction a strategic single-source. Reach for this before any sourcing event. |
| `source-on-tco` | `procurement-sourcing` | Run a sourcing decision on TCO — freight, quality, switching, inventory, lifecycle — not unit price, so a price 'savings' doesn't raise total cost. Reach for this on any sourcing event. |
| `validate-realized-savings` | `procurement-sourcing` | Measure realized savings against a finance-recognized baseline and locate leakage, so negotiated savings aren't mistaken for P&L impact. Reach for this on any savings claim. |
| `assumption-mapping` | `product-management` | Structured playbook for surfacing and ranking the riskiest assumptions behind a product initiative, then designing the cheapest test for each — the core of continuous discovery before building. |
| `continuous-discovery` | `product-management` | Run continuous product discovery: weekly JTBD customer interviews, an opportunity-solution tree (outcome -> opportunities -> solutions -> experiments), assumption mapping with riskiest-assumption testing, and problem validation before solutioning. |
| `prioritization` | `product-management` | Prioritize by evidence, not opinion: use a transparent framework (RICE = reach x impact x confidence / effort, or cost-of-delay, or opportunity scoring) to make trade-offs explicit and arguable, and frame everything around outcomes rather than outputs. |
| `product-metrics` | `product-management` | Measure what matters: define a North Star metric that captures delivered value, decompose it into 3-5 movable input metrics, distinguish vanity (cumulative totals) from actionable (rates/cohorts/retention), set guardrails, and judge outcomes vs a baseline. |
| `rice-prioritization` | `product-management` | Worked RICE scoring playbook for evidence-based backlog prioritization — covers calibrating each factor, avoiding common scoring errors, and using the output to run a defensible prioritization meeting. |
| `project-charter-and-baseline` | `project-management` | Stand up the predictive plan of record — a project charter (objective, success criteria, sponsor, high-level scope, assumptions/constraints), a scope statement + WBS decomposed to single-owner work packages, and the scope/schedule/cost baseline that change control is measured against. Reach for this at project initiation, a reset, or before any earned-value reporting. Used by `delivery-lead` (primary). |
| `raid-facilitation` | `project-management` | Build or refresh a decision-grade RAID register — risks framed cause→event→consequence and scored against a stated rubric (qualitative probability×impact, quantified/EMV where the stakes justify it), each with a response and a single owner; plus issue triage, assumptions, and dependency tracking. Reach for this when a RAID stub needs to become a real register, a risk needs quantifying, or issues need triaging to action. Used by `risk-and-raid-analyst` (primary). |
| `sprint-planning` | `project-management` | Plan a sprint from a backlog — set a single sprint goal, size the commitment to demonstrated capacity (not aspiration), attach acceptance criteria + a single owner to every committed item, and make carry-over explicit. Reach for this when a team is starting a sprint, replanning mid-flight, or diagnosing erratic velocity. Used by `scrum-master` (primary). |
| `stakeholder-engagement` | `project-management` | Build and maintain a stakeholder register with power/interest mapping, design a tailored communications plan, prepare steering packs and executive status reports, and handle escalation memos — ensuring the right message reaches the right stakeholder at the right depth every cycle. |
| `status-and-steering-pack` | `project-management` | Package delivery + risk data into audience-ready communication — a narrative-first status (RAG that explains itself and never contradicts the numbers), a steering-committee pack, and an escalation memo that is a decision request. Reach for this for recurring status, an exec/board update, or an escalation under pressure. Used by `stakeholder-comms-lead` (primary). |
| `context-window-engineering` | `prompt-engineering` | Decide what actually goes in the context window — static instructions vs just-in-time retrieval vs conversation history vs tools — with a per-section token budget and lost-in-the-middle-aware ordering. Reach for this when the window is bloating, quality is dropping as context grows, cost/latency is climbing, or you're unsure what to keep vs compress. Pairs with prompt-pattern-selection. |
| `prompt-eval-and-regression` | `prompt-engineering` | Build the eval/regression set that gates prompt changes — labeled input/expected pairs over the hard cases, a scoring method (exact / schema-valid / rubric / LLM-judge with its caveat), a pass threshold, a CI gate with the model pinned, and injection cases. Reach for this before shipping a prompt, when a tweak silently broke other cases, or to defend against prompt injection. Pairs with structured-output-design. |
| `prompt-pattern-selection` | `prompt-engineering` | Choose the prompting pattern — zero-shot, few-shot, chain-of-thought, decomposition/chaining, role framing, or self-consistency — by tracing the task against reliability need and token/latency cost. Reach for this when a prompt is inconsistent, when you're about to add examples 'just in case', or when one prompt is quietly doing several jobs. Pairs with structured-output-design. |
| `structured-output-design` | `prompt-engineering` | Make an LLM return reliably machine-parseable output — choose the enforcement mechanism (native JSON/schema mode, tool/function calling, constrained grammar, or prose+parser), define the schema, and build the parse/validate/repair path. Reach for this when output format drifts, when downstream code parses model output, or when 'return JSON' in prose keeps failing. Pairs with prompt-pattern-selection. |
| `age-delinquency` | `property-management` | Age delinquency into buckets and weight collections by collectability, not the total. Reach for this on a delinquency or cash question. |
| `build-noi` | `property-management` | Build the EGI-to-NOI bridge from gross potential rent and translate to value at a cap rate. Reach for this on an NOI or valuation question. |
| `diagnose-leasing-funnel` | `property-management` | Diagnose the leasing funnel step-by-step and split renewal-vs-acquisition need. Reach for this on a lease-up question. |
| `project-occupancy` | `property-management` | Project ending occupancy as a flow of move-ins, move-outs, and renewals against a target. Reach for this on an occupancy question. |
| `quantify-turn-loss` | `property-management` | Quantify lost rent during unit turns and frame the work-order backlog as a retention risk. Reach for this on a turn or maintenance question. |
| `accessibility-508-and-records` | `public-sector-govtech` | Section 508 / WCAG 2.x conformance lifecycle: gap assessment, automated and manual testing methodology, VPAT/ACR authoring using the ITIC template, remediation prioritization, and ongoing testing cadence. Covers FOIA / public-records request handling (intake, exemption analysis, redaction, response timelines) and plain-language compliance (Plain Writing Act, Federal Plain Language Guidelines). |
| `grants-management` | `public-sector-govtech` | Federal and state grant lifecycle management: pre-award application (NOFO analysis, project narrative, budget, SF-424 family), post-award setup (Notice of Award review, restricted-fund structure), ongoing management (drawdowns, budget modifications, subrecipient monitoring, progress reporting), closeout, and single audit readiness under 2 CFR 200 (Uniform Guidance). |
| `public-procurement-and-rfp` | `public-sector-govtech` | End-to-end public procurement and RFP/RFI response workflow: bid-no-bid scoring, compliance matrix construction, Section L/M mapping, technical and management volume drafting, past-performance selection and narrative, price volume structure, and post-submission debrief analysis. Covers federal (FAR Parts 12, 13, 15, 16) and SLED (cooperative purchasing, state procurement codes) procurement. |
| `e2e-automation` | `qa-test-automation` | Write deterministic E2E/integration tests: target resilient role/test-id selectors, wait on conditions never fixed sleeps, isolate and clean up test data, and structure with page objects so a UI change updates one locator. |
| `flaky-test-triage` | `qa-test-automation` | Structured procedure for detecting, classifying, and eliminating flaky tests — covers quarantine mechanics, root-cause patterns (timing, state, network, ordering), and the fix or delete decision. |
| `test-infrastructure` | `qa-test-automation` | Build trustworthy test infrastructure: factory-based isolated test data, ephemeral per-run environments + service virtualization, automated flaky-test detection/quarantine, parallel sharding, and coverage+mutation reporting in CI. |
| `test-pyramid-audit` | `qa-test-automation` | Audit procedure for diagnosing test pyramid shape — identifies ice-cream-cone suites, slow E2E over-reliance, and unit test gaps, then produces a concrete rebalancing plan. |
| `test-strategy-design` | `qa-test-automation` | Design a test strategy on the pyramid: map defect classes to the cheapest test level that catches them, prioritize by risk, use coverage as a floor and mutation testing as the quality truth, and decide what not to test. |
| `design-and-transpile-quantum-circuit` | `quantum-computing-engineering` | Design a quantum circuit for a chosen algorithm and transpile it to a real device's topology and native gate set — qubits/gates/measurement, the VQE/QAOA/quantum-kernel ansatz, decomposition to native gates, routing to qubit connectivity with SWAP overhead, and the transpiled depth checked against the coherence budget so it stays shallow enough for NISQ. Also builds the hybrid quantum-classical optimizer loop for variational algorithms. Reach for this when the user asks 'build/transpile this circuit for <backend>', 'set up a VQE/QAOA', 'what's the depth after routing?', or 'which ansatz/optimizer?'. Used by `quantum-algorithm-engineer` (primary). |
| `select-error-mitigation-and-benchmark` | `quantum-computing-engineering` | Select NISQ error-mitigation techniques for a noisy circuit and benchmark the result honestly — zero-noise extrapolation, probabilistic error cancellation, measurement-error mitigation, dynamical decoupling (mitigation, NOT the error correction fault tolerance will provide), the shots for a target statistical error, and a benchmark against an exact/simulated reference with the residual bias/variance quantified. Reach for this when the user asks 'the results are noisy — can I trust them?', 'which error mitigation?', 'how many shots?', or 'benchmark this vs the exact answer'. Used by `quantum-algorithm-engineer` (primary). |
| `triage-quantum-use-case` | `quantum-computing-engineering` | Decide whether a problem should use quantum computing at all — and if so, which paradigm, qubit modality, NISQ-vs-fault-tolerant placement, SDK/provider, and resource estimate — by traversing the quantum triage decision tree (classical-vs-quantum gate → paradigm → modality → NISQ-vs-FT → SDK/provider), returning a go/no-go verdict that defaults to 'classical wins today' unless a proven advantage, an in-regime problem size, and an affordable state-prep cost all hold. Reach for this when the user asks 'should we solve this with quantum?', 'gate-model or annealing?', 'which qubit hardware?', 'is this NISQ-doable or does it need fault tolerance?', or 'Qiskit/Cirq/PennyLane/Braket?'. Used by `quantum-solutions-architect` (primary). |
| `adaptive-run-classifier` | `ravenclaude-core` | Substrate-neutral pre-execution classifier contract. A single Haiku call emits a `run_config` JSON envelope that right-sizes cardinality knobs + per-phase model tier + reasoning level for multi-phase agentic workflows (the rc-deep-research loop is the first consumer). Workflows read the envelope; substrate adapters (Claude / Codex / Copilot) map tier labels to SKUs. Carved out behind `.ravenclaude/run-config.json` `enabled: false` so adoption is opt-in and rollback is one line. |
| `agent-dispatch-evaluator` | `ravenclaude-core` | Universal pre-dispatch model right-sizer. A single Haiku 4.5 forced-tool call evaluates `{subagent_type, description, prompt_head}` at every Agent dispatch / Workflow `agent()` call / `thing-decide.py` seat dispatch and binds (downgrades AND upgrades) the model selection. Carved out behind `.ravenclaude/dispatch-config.json` `enabled: false` so adoption is opt-in and rollback is one line. Tribunal-seat verdicts are shadow forever for MVP (protects the v0.32.0 backbone-diversity invariant). |
| `agent-quality-rubric` | `ravenclaude-core` | Score and improve an agent file against a 6-dimension rubric — Mission clarity, Scope sharpness, Capability Grounding alignment, Output-Contract completeness, Escalation paths, Example scenarios. Each dimension scored 1-5 with anchors; includes a remediation template that turns a low score into an actionable PR. Reach for this skill when authoring a new agent, reviewing a PR that adds or modifies an agent, or running a periodic agent-bank audit. Used by `prompt-engineer` (primary) plus `architect`. |
| `analog-closeness-scorecard` | `ravenclaude-core` | Recompute the M/H/G/O/E/I/T/V weighted closeness score (and the observed-vs-inferred quality bar) for a product-analog comparison, reusing the exact formula from the 2026-08-14 analog-repos-gap-fill survey instead of hand-deriving the arithmetic each time. Use when scoring how close a candidate repo/product is to RavenClaude (or any similarly-shaped catalog+governance+ops comparison) on the eight-dimension rubric. |
| `audit-ci-gates` | `ravenclaude-core` | For any consumer project where a CI workflow is meant to *enforce* a property (lint, format, security scan, manifest validation, version pin, layout allow-list, etc.). When working on a CI file or adding a new check, run this skill — every gate must fail on a known-bad input AND pass on a known-good input. A gate that runs without gating, or gates the wrong thing, is invisible from inside a green CI dashboard. Also triggers on user phrases like "audit the CI", "verify the gates", "is this gate real", "does this lint actually fail". |
| `authoring-org-skills` | `ravenclaude-core` | Authors, validates and packages a claude.ai Organization Skill — the intake questions, the trigger and scope exercises, then lint, pack and verify against measured platform constraints. Reach for this when someone wants to publish a Skill to their organization, or when an upload was rejected and the reason is unclear. |
| `branch-archive` | `ravenclaude-core` | Safely retire a local branch by tagging its tip first, then deleting the branch. The sanctioned escape hatch from guard-destructive.sh's blanket `git branch -D` block — turns silent-loss-of-unmerged-work into a reversible, audit-logged operation. Use when an agent or maintainer wants to clean up old feature branches that represent abandoned approaches, stale plans, or superseded work. |
| `brand-extraction` | `ravenclaude-core` | Point at a website home page and extract every logo variant plus the brand 'schema' (design tokens — colors, typography, radii) into a ready-to-apply brand kit, so HTML documents/reports you generate for that project match the brand. Use when the user says things like 'pull the logo and brand from this site', 'extract the brand schema from <url>', 'make my reports match <company>'s style', or 'grab the colors and fonts from this homepage'. |
| `cheap-lane-delegation` | `ravenclaude-core` | Route ONE well-defined job (single-file, tests, summary, mechanical refactor) off Claude via cheap-lane-delegate.sh (bounded, returns). Opt-in cheap_lane: advise\|agent. NOT for quota-escape, host-switch, fresh window, or 'pass remaining work to Grok' → session-handoff. |
| `claude-code-parallel-and-modes` | `ravenclaude-core` | Use when choosing Claude Code CLI parallelism or modes — remapping informal "max parallel", picking plan mode / subagents / worktrees /batch / ultracode workflows / ultrathink /effort /compact, surviving parent context limits during fan-out (disk-first handoff), or writing operator prompt templates. Not for non-Claude coding tools (escalate ai-coding-model-guidance) and not for inventing a /max-parallel command. |
| `claude-orchestrate` | `ravenclaude-core` | One-off Claude orchestration — route this task through Claude's brain even when the host CLI is Copilot/GPT/Grok. The `orchestrator:` knob in comfort-posture.yaml sets the always-on default; this skill is for on-demand invocation. |
| `cleanup-worktrees` | `ravenclaude-core` | Remove finished agent worktrees, prune their branches, and surface anything still in flight. Run at the end of a multi-agent session and weekly as hygiene. |
| `contribute-finding` | `ravenclaude-core` | For Claude sessions running in a consumer project (any project where ravenclaude-core is installed). Triggered when you discover a cross-domain finding worth contributing back to the RavenClaude marketplace — either spontaneously, or when the user says "contribute this," "save to RavenClaude," "this is worth keeping," or similar. Walks through the qualifying check, picks the right shape (lesson, best-practice, or both), and formats a copyable staging submission the user can drop into RavenClaude/docs/staging/incoming/. |
| `create-pr` | `ravenclaude-core` | Open a pull request for the current branch using the project's standard template. Verifies the branch is green, summarizes the diff against main, and pushes only after the user confirms. |
| `cross-platform-determinism` | `ravenclaude-core` | For any script that produces a file the repo COMMITS and CI DIFFS — generated HTML, lockfiles, JSON snapshots, fixture files, documentation rendered from source. The output must be byte-identical regardless of who regenerated it or on what OS. This skill catches the specific failure modes that turn a freshness gate into a paper tiger that fails forever — OS-dependent path separators, locale-dependent encodings, nondeterministic ordering, drifting timestamps. Triggers on phrases like "freshness check failing", "regenerated locally but diff doesn't match", "works in CI not on Windows", "generator produces different output", and on any review of a script whose output is committed. |
| `decision-review` | `ravenclaude-core` | Route a yes/no decision through the command-review tribunal (the Thing) for a binding verdict instead of pausing the human. Use before asking the user any yes/no question, and in the post-PR decision review. The tribunal auto-decides rule/fact-derivable calls and defers genuine preferences (and irreversible/high-blast calls) back to the human. |
| `declarative-visualization` | `ravenclaude-core` | Author a Vega-Lite / Deneb / SVG spec for a stated intent on any surface (web vega-embed, react-vega, Evidence, Observable, Power BI Deneb, Tableau extension/SVG, SVG-in-DAX). Six-step method: pick grammar → bind data → encode → wire interactivity → test null/empty → verify via render loop. Ships a surface-agnostic spec-patterns library. Mandatory security audit (no data.url, no remote loader, no SVG script) enforced by lint.py (Gate 101). Complements the visual-feedback-loop (render referee) and pbir-layout-engine (coordinate linter). NOT for coordinate/layout arithmetic (pbir-layout-engine) or render-loop orchestration (visual-feedback-loop). |
| `dependency-update-sweep` | `ravenclaude-core` | When a tracked host tool (Claude Code, Copilot CLI/Chat, Codex CLI, Cursor, Gemini CLI, Aider, Windsurf — read live from host-support.json) ships a new version, scan the repo for citation-marked drift, auto-apply safe mechanical fixes, and queue judgment calls for review. Reach for this skill on "a host tool updated, what needs to change" or via the SessionStart nudge. |
| `design-clone` | `ravenclaude-core` | Capture a reference website's full design schema (spacing/type/grid/elevation/component recipes) and apply it to a target — cloning the craft while swapping in the target's own brand and structurally blocking the reference's identity from leaking. Fidelity is browser-gated; trade dress is not cleared here. |
| `design-link` | `ravenclaude-core` | Bind THIS repo to one of your claude.ai/design design-system projects in one step — lists your projects, lets you pick, and writes .ravenclaude/design-project.json so every session's capability banner surfaces the link and the agent can read/edit the project. Use when starting design work in a repo that has no .ravenclaude/design-project.json yet (or to re-point it). Pairs with the built-in /design-sync skill (which does the actual component sync) and the DesignSync tool. |
| `diff-budget` | `ravenclaude-core` | Enforces a per-PR file-count and LoC budget. PRs touching >5 files or >400 LoC route to architectural review before merge. Counters T-1 (premature abstraction) + T-4 (going off-script) — Copilot CLI degrades sharply past 10 files per file, and uncontrolled diff growth is the strongest predictor of off-pattern mutations. |
| `draft-agent-brief` | `ravenclaude-core` | Use this skill when the user wants to create a new agent and has a clear business goal but isn't fluent in the agent's target domain. Walks them through producing a strong brief by filling in `templates/agent-brief.md` from their plain-language description, then iterating once or twice before building or dispatching the agent. Triggers when the user asks for "a new agent that does X" without already supplying the technical spec, or when they've filled the brief template and left blanks where they didn't know. |
| `environment-discovery` | `ravenclaude-core` | Auto-discover the consumer's environment posture by probing installed CLIs (pac / az / aws / gcloud / gh) with read-only commands at session start, decoding JWTs for role/scope claims, and assembling a draft `.ravenclaude/environment-context.md` for save/edit/skip. Streamlines proposal 2026-05-22-001's permission-awareness mechanism. |
| `external-agent-onboarding` | `ravenclaude-core` | Onboards a non-Claude-Code coding agent (GitHub Copilot CLI / OpenAI Codex CLI / Cursor / Aider / Devin Desktop) to this repo at session start. Use when this repo will be operated on by an agent that does not natively read CLAUDE.md. Routes through AGENTS.md, then layers the per-host wiring, version floors, and failure-mode mitigations that host actually needs. |
| `forge-pipeline` | `ravenclaude-core` | The FORGE gated-planning pipeline that /forge runs: depth-scaled gates that turn any idea into a two-panel-reviewed, critic-checked, tiebroken, routed plan. Mimics Claude Code Ultraplan's deep-plan loop and improves it with cross-model divergence, a fact-verification gate, a correlated-error critic, and a binding tribunal for conflicts. |
| `game-theory-basics` | `ravenclaude-core` | Use this when multiple agents or parties have incentives — sketch payoffs, dominant strategies, and equilibrium intuition for coordination, gates, and escalation. |
| `github-gold-standard` | `ravenclaude-core` | Score a consumer repo's GitHub-development protocol against the shipped gold-standard catalog and produce a remediation queue ranked by leverage. A 10-row core rubric (mapping 1:1 to the P3 exemplar-repo catalog + the P4 Actions-hardening rules) plus 3 agent-operability rows for the agent-as-primary-GitHub-operator bar — each row is a check the agent runs against .github/workflows/*, the repo's .git, and its ruleset, a pass/partial/fail verdict, and the shipped fix (an /init-agent-ready template or a knowledge file). Proportional banding (dynamic denominator). Use to measure a repo against the best-of-the-best bar before calling its CI/branch-protection done. Honest scope: it measures STRUCTURAL COVERAGE, not taste. |
| `knowledge-file-staleness-sweep` | `ravenclaude-core` | Run a periodic staleness sweep over all `plugins/<plugin>/knowledge/*.md` files and any decision-tree sections — flag entries past their `last-verified` window, categorize by re-verification effort (Tier 1-5 per Researcher schema), produce a remediation queue with named re-verifiers. Reach for this skill on the Researcher's weekly cadence OR before a marketplace release. Used by `deep-researcher` (primary) plus the maintainer. |
| `knowledge-health` | `ravenclaude-core` | Surface knowledge-file staleness across all plugins as a Structured Output block. Wraps the `knowledge-health.py` script — sweeps `plugins/*/knowledge/**.md`, groups files by bucket (stale / due_soon / untracked / fresh), and returns a remediation queue. Used by the release checklist and the `ravenclaude doctor` health check. Read this skill before answering "is our knowledge layer current?", "which knowledge files are stale?", or before tagging a marketplace release. |
| `mimir` | `ravenclaude-core` | Claude-Code-session-state surfacing contract for the Mímir dashboard tab. Documents the five reachable on-disk sources under `~/.claude/` and `<project>/.claude/`, the encoded-path algorithm + reverse-decode fallback, the hard scrubbing/torn-write/staleness/worktree/server-parity invariants, the per-card source map, and the honest empty-state contract for in-process-only fields. Read this before authoring or modifying `_read_mimir` (in both `serve-dashboards.py` copies), the `/__mimir` endpoint, the `#/mimir` generator tab, or the Gate 49 render fixture. |
| `new-worktree` | `ravenclaude-core` | Create an isolated git worktree under .claude/worktrees/ for a sub-agent to work in. Use this before dispatching any coder agent so that parallel work cannot collide. |
| `pbir-layout-engine` | `ravenclaude-core` | Deterministic layout-arithmetic linter for dashboard/report page definitions. Runs seven checks — no-overlap (AABB), within-canvas, equal-gap, column-alignment, and three PBIR-specific invariants (no-empty-binding, bounded theme-override count, visualType/displayOption schema validity) — against a page JSON, a page directory, or a fixture set. Stdlib-only, no network, exit-coded for CI. The load-bearing technical core under the data-viz-designer agent; usable standalone to lint a Power BI PBIR page layout. |
| `permission-hygiene` | `ravenclaude-core` | Diagnose and improve a Claude Code project's permission setup — the `.claude/settings.json` allow/ask/deny rules and the `.claude/settings.local.json` personal overrides. Use when settings.local.json has grown bloated (>20 rules, many one-shot), when permission prompts feel too frequent or too coarse, or before sharing a project's settings.json with a team. Companion to the Claude Code core `/fewer-permission-prompts` skill (which is the data-driven sweep); this skill is the design discipline that decides what should and shouldn't be allowlisted. |
| `plugin-release-checklist` | `ravenclaude-core` | Pre-release checklist for shipping any plugin update through this marketplace — plugin.json + marketplace.json + architecture.md version-mirror discipline, .repo-layout.json glob coverage for new dirs, CLAUDE.md skill / template tables synced, JSON validation, prettier check, audit-gates meta-test, and the consumer migration-note rule. Includes the exact bash commands to run (Windows PowerShell + bash). Reach for this skill at the end of any plugin PR or before merging a release-candidate branch. Used by the maintainer (primary) plus `project-manager`. |
| `probe-kit` | `ravenclaude-core` | Run a ready-made CONTROL probe alongside any negative result — http/dns/file/cmd. A negative is not a diagnosis until a positive control on the same subsystem has been observed. Makes the right action one line instead of an idea you have to have. |
| `prompt-optimizer` | `ravenclaude-core` | Rewrites an ambiguous-but-single-domain (domain_count<=1) user prompt via emit_optimized_prompt, or drafts an advisory multi-domain dispatch plan via emit_dispatch_plan (domain_count>=2), before the turn runs — surfacing constraints, missing context, and wild assumptions instead of silently guessing or fragmenting. Phase 5 screens/formats either generator's output before injection. Companion generators to prompt-optimizer-gate.sh's Tier-1 classifier. |
| `prompt-pattern-library` | `ravenclaude-core` | Curated, applied prompt-pattern catalog used across this marketplace — decision-tree traversal pre-action prior, alternate-methods-before-blocked, Structured Output Protocol `---RESULT_START---` block, scenario-retrieval inline prior, escalation-by-mandatory-phrasing, citation-aware research, environment-context preamble, orchestrator-worker reinforcement, agent-scenario-authoring frontmatter, claim-grounding/source-honesty marker. Each pattern includes when to use it, what it composes with, an example block, and the failure mode it prevents. Reach for this skill when authoring a new agent, when an existing agent shows a behavior gap that a known pattern would close, or when the `prompt-engineer` is consulting on an agent revision. Used by `prompt-engineer` (primary). |
| `pseudonymize` | `ravenclaude-core` | Reversibly pseudonymize names/entities in text BEFORE sending it to a model, and restore them in the reply. Deterministic denylist (reliable) + structured PII + optional NER; local vault; residual scan. Pseudonymizes, does NOT anonymize. |
| `quantitative-problem-solving` | `ravenclaude-core` | Use this when something failed or may fail — enumerate failure hypotheses, cost each try, update P(cause\|history), and pick the next action by expected value / EVPI. |
| `ravenclaude-core-orchestration` | `ravenclaude-core` | Use this when leading multi-agent work — dispatch specialists, gate reviews, handoffs, walls, plan→build→verify, and disciplined problem-solving (first principles, Occam, quantitative failure analysis). |
| `rc-deep-research` | `ravenclaude-core` | Deep research harness — fan-out web searches, fetch sources, adversarially verify claims, synthesize a cited report. Includes an inline substrate adapter that reads .ravenclaude/run-config.json once at startup; when enabled:false (the default) all agent() calls are byte-identical to the pre-port baseline (a behavioral invariant — no gate currently CI-enforces it). |
| `refine-to-rubric` | `ravenclaude-core` | Iterate an artifact until it measurably passes a BOUNDED rubric — the Convergence Engine. Objective/deterministic gates run BEFORE any model judge, the judge is a DIFFERENT model than the author (never self-grade), the stop decision is a model-free predicate, and it emits the BEST iteration (keep-best/regression-revert) under a hard iteration cap + model-call budget. The engine NEVER claims perfect — verdicts are rubric-pass \| capped \| plateaued \| budget-exhausted with an honest residual-gaps list. Use to drive any artifact (code, prose, a visual report, an agent file) to a defensible bar; for the agent-file case it delegates to agent-quality-rubric, and for visual surfaces it composes with visual-feedback-loop. |
| `repo-build-studio` | `ravenclaude-core` | Build a website or dashboard by prompting Claude and watching it render live, then commit it back — by COMPOSING existing surfaces (Claude Code on the web + a self-contained-HTML constraint + a GitHub Pages/githack branch preview + a PR), not by building a custom backend. Use when someone wants the "pick a repo, prompt, see it build, ship it" loop. Covers the static/self-contained case fully; says when a real data-connected dashboard needs the heavier Tier-1 path. |
| `repo-review` | `ravenclaude-core` | Whole-repo systematic bug sweep — deterministic chunking + a content-hash cache + a Workflow-orchestrated multi-dimension review fan-out (correctness / security / concurrency / resource-leaks / error-handling / performance / ci-cd-actions-security / dead-code-simplification), cross-model-checked at higher tiers, merged and verified before any fix is proposed. Distinct from Claude Code's own built-in /code-review, which reviews a diff/PR/branch — this skill reviews the whole tree, including GitHub Actions workflows and CI gate definitions. |
| `researcher` | `ravenclaude-core` | Meta-skill that keeps all agents, skills, and knowledge files current and honest — Daily Quick Check + Weekly Deep Research modes. Categorization schema (Tier 1 Consensus / 2 Strong-but-Contextual / 3 Divergent / 4 Emerging / 5 Deprecated). Includes 90-day staleness checks for decision trees AND `.ravenclaude/environment-context.md`. |
| `review-staged-contributions` | `ravenclaude-core` | For the RavenClaude marketplace maintainer. Walks every file in docs/staging/incoming/ one at a time, runs a security sweep + topic-expert analysis on each, presents each with a keep/update/deny prompt, promotes approved submissions to their canonical location (docs/memory-bank/lessons-learned.md for lessons, docs/best-practices/<slug>.md for best-practices), and deletes denied ones. Trigger when the maintainer says any of "check for updates", "check the staging queue", "anything in staging", "review submissions", "drain the queue", or "review staged contributions" — also fires on the slash command /review-staged-contributions. |
| `routine-reserve` | `ravenclaude-core` | Set up, inspect, override, or remove the routine token reserve — an hourly meter Routine records what your claude.ai Routines cost, and a projected reserve of the weekly usage cap is held back for them so non-stop interactive work never starves them. Use for '/routine-reserve setup\|status\|override\|clear-override\|uninstall', 'keep enough tokens for my routines', or 'how much of my weekly cap do my routines need'. |
| `routine-review-tribunal` | `ravenclaude-core` | Gate an unattended scheduled routine's produced diff/PR through a two-panel, cross-model tribunal (mirrors /forge-pipeline's divergent-panel + tiebreak shape, applied after the fact) before it is finalized: approved as-is, sent back for a bounded revision round, or escalated to a human. Use at the end of any routine whose run contract ends in opening or updating a PR (plugin-discovery, research-cadence). |
| `run-full-test-suite` | `ravenclaude-core` | Run the project's full quality gate — format check, lint, typecheck, unit tests, integration tests — in order, fail fast, summarize. Use before reporting any non-trivial change as complete. |
| `scenario-retrieval` | `ravenclaude-core` | Consult the unverified scenarios bank (`plugins/<plugin>/scenarios/*.md`) before answering plugin-domain questions. Glob + tag-filter + recency-weight, surface top 2-3 with mandatory unverified-scenario preamble ("Based on N unverified scenarios from YYYY-MM tagged [scope] — verify in your environment"). Secondary source — never replaces canonical knowledge files. |
| `scout` | `ravenclaude-core` | Discover great-but-low-visibility ideas — the fringe excellence mainstream search buries under popularity. Given a seed (a name, repo, post, or topic), traverse its citation/collaborator graph + the periphery sources, score each candidate on depth × novelty × practitioner-grounding MINUS a popularity penalty, dedup against the idea-board + installed plugins, and emit a ranked shortlist that routes the best finds into /forge. Use when you spot a promising fringe idea (often on LinkedIn / X / GitHub) and want the cluster around it, or to periodically sweep a niche for under-the-radar excellence. |
| `session-handoff` | `ravenclaude-core` | Write a run-dir handoff and start a NEW interactive session (unbounded TUI — never a headless print-flag). Use for /handoff, context full, fresh window, quota host-switch, 'pass remaining work to Grok'. NOT for one bounded Grok/Copilot job → cheap-lane-delegation. |
| `session-relay` | `ravenclaude-core` | Hand a mid-flight finding or a small, well-scoped task to the RIGHT peer Claude Code session — the one already working in the relevant worktree/branch — via ListAgents/SendMessage, instead of paging the human or letting the finding go stale until that session's next Stop. Use when you discover something relevant to another live worktree; NOT for routine sub-agent dispatch (spawn-team) or starting a new peer session. |
| `set-posture` | `ravenclaude-core` | Translate `.ravenclaude/comfort-posture.yaml` into `.claude/settings.json` permission rules. Owns the (category, level) → permission-rule emission table that the `/set-posture` slash command applies. Read this skill when authoring or reviewing the translation logic, when a category is missing rules, or when a level's behavior surprises you. |
| `skill-index` | `ravenclaude-core` | Look up any skill in the marketplace by name or topic, including a disabled one, and get its exact re-enable command. Reach for this when you suspect a skill exists for the current task but it is not in your listing. |
| `spawn-team` | `ravenclaude-core` | Team Lead dispatch playbook. Pick the surface first (slash command vs skill vs specialist agent vs orchestration shape — Step 1.25), then whether to delegate (Step 1.5), then which agents and order. Load whenever choosing skill vs agent vs slash, weighing delegation, or about to dispatch more than one agent. Keeps routing consistent; platform description-match alone is not the router. |
| `spec-reread-ritual` | `ravenclaude-core` | Before writing any code for a task in a multi-task build, the agent MUST re-read the relevant spec section verbatim, paste it into the work log, and quote the prior. NO work from memory. Counters the "100% spec drift" failure mode from the Claude Code bug study (issue #19739) — where 11/11 sessions drifted from the spec and exact-match format compliance was 0%. |
| `structured-output` | `ravenclaude-core` | Enforce the Structured Output Protocol — every sub-agent handoff ends with a `---RESULT_START--- ... ---RESULT_END---` JSON block alongside the human-readable Markdown. Team Lead parses the JSON for routing; Markdown stays for human review. Active across all 14 core specialists. |
| `svg-report-lint` | `ravenclaude-core` | Lint a standalone SVG file for geometry soundness, legibility, and security before committing to a report or embedding in Power BI/Tableau. Checks viewBox presence and aspect ratio, minimum text font-size, and the security floor: no <script>, no on* handlers, no <foreignObject>, no remote href/use. Gate 103. Complements declarative-visualization (Vega-Lite/JSON spec lint, Gate 101) and pbir-layout-engine (coordinate arithmetic). NOT for Vega-Lite JSON specs (use declarative-visualization) or coordinate layout arithmetic (pbir-layout-engine). |
| `terminal-status-indicators` | `ravenclaude-core` | Make VS Code terminal tabs show 🔔 + chime the moment an agent session needs you, across many parallel Copilot/Claude terminals. Installs three layers: workspace settings (tab bell icon + audio cue), a shell prompt hook (bell on command completion), and a background /proc-io watcher that rings a terminal's PTY bell when its agent process goes idle after responding. Use in a Codespace / VS Code setup where you run multiple background agent sessions and can't tell which one is waiting for input without clicking through each tab. |
| `thing` | `ravenclaude-core` | Command review (the Thing) — the opt-in command-review tribunal that votes ALLOW/EDIT/DENY on shell commands (and ALLOW/DENY on file edits) a comfort-posture category is set to review. Read this when wiring, debugging, or explaining the tribunal: the PreToolUse orchestrator, the reviewer panel + tie-breaker, the deterministic concern evaluator, the tier model, the dashboard-configurable panel, the per-category toggle, the audit trail, and the fail-closed rules. T5 = tiered routing (low→extreme) where a clean low-risk read gets no LLM panel, seat count + confidence escalate with the tier, and a dashboard-configurable gate_floor decides which confident allows you confirm; live for six command categories (ALLOW/EDIT/DENY) — the five shell categories plus network_write (curl/wget/gh writes, v0.40.0) — plus six tool-shape categories that are ALLOW/DENY-only (a seat EDIT is coerced to DENY): file_edit_project, file_edit_global, file_read_project, file_read_global, network_read, mcp_tools. |
| `thing-denial-kb` | `ravenclaude-core` | The Thing-denial knowledge base (Muninn). When the command/decision tribunal DENIES or DEFERS an action, consult this to identify WHY the same block keeps happening and the known fix, then teach the KB a new resolution once you solve one. Read it the moment the Thing blocks you. Reads the Sága audit logs; never touches the tribunal's live path. |
| `two-panel-plan-review` | `ravenclaude-core` | Two fresh-independent expert panels review a strategic plan, fill its gaps, author a tactical build plan, then a different panel cold-reviews the build plan and emits P0/P1 recommendations. Includes an upfront advisory routing analysis recommending Ultraplan (cloud) vs. local for the task. |
| `update-ravenclaude` | `ravenclaude-core` | Bring a RavenClaude install up to date when it's stale, when new skills/agents aren't showing, or after upstream changes ship. Covers both hosts: under GitHub Copilot CLI the update is `git pull` in the marketplace clone then re-running `ravenclaude setup` (idempotent); under Claude Code it's `/plugin marketplace update ravenclaude` then `/reload-plugins`. Read this skill on triggers like 'update ravenclaude', 'ravenclaude is stale', 'refresh skills', or 'new skills not showing'. |
| `visual-feedback-loop` | `ravenclaude-core` | Render → see → critique → edit → re-render: the discipline (and a deterministic referee) that lets an agent inspect its OWN rendered output — a web page, a dashboard, a Power BI / Tableau report — and iterate toward correctness/pixel-perfection against objective stopping signals instead of 'looks better'. The referee (driver.py) merges the pbir-layout-engine layout linter with agent-captured console/Lighthouse evidence into one pass/fail verdict. Use when building or refining any visual surface; the standalone canon is knowledge/visual-feedback-loop.md. |
| `wall-handling` | `ravenclaude-core` | When an agent hits a wall (same tool + same error 3+ times, an impossible TypeScript fix, a missing API surface, a failing test it can't resolve in one attempt), STOP — do not invent the API, do not delete the prop, do not '@ts-ignore'. Take the documented default with an inline comment, or ask the user. Counters the "agents push forward through impossible tasks" failure mode (Cognition/Devin retrospective + Claude Code spec-drift study). |
| `webfetch-hardening` | `ravenclaude-core` | Deterministic sanitizer floor for WebFetch return envelopes — strip injection-shaped blocks before any agent treats fetched-body content as authoritative. Two confirmed-in-wild observations (2026-06-02) at ibcs.com/standards and the FT chart-doctor GitHub tree drove this. Used by any agent that issues a WebFetch — deep-researcher (most exposed), architect, code-reviewer, security-reviewer, plugin-release-checklist, dashboard-builder, power-bi-engineer. |
| `wireframe` | `ravenclaude-core` | Invoked by /wireframe. Turn a plain-language description of anything — a web page, an app/software screen, a dashboard, or a flow/diagram — into a validated wireframe MODEL, then a high-fidelity self-contained HTML Artifact (authored via artifact-design) and, for flows, a Mermaid flowchart. One model, many surfaces; iterate by editing the model. NOT a full design spec or accessibility audit (that is the designer agent) and NOT production code. |
| `build-presence-and-awareness` | `realtime-collaboration-engineering` | Build live cursors, selections, and who's-here as an EPHEMERAL channel separate from the persisted document: last-write-wins per client, throttled, expiring on disconnect. Never write presence into the CRDT/OT log — it corrupts undo and bloats history. |
| `choose-crdt-or-ot` | `realtime-collaboration-engineering` | Choose the merge model for a collaborative feature: CRDT vs OT vs last-writer-wins, decided by whether the system must converge without a central order (offline/P2P) and by the data shape — not by hype. Name the consistency guarantee and the growth-bounding obligation that comes with the choice. |
| `design-the-document-model` | `realtime-collaboration-engineering` | Map the app's shared state onto CRDT/OT primitives per field — sequence for text/lists, map for records, register for scalars, counter for tallies, OR-Set for membership — so the merged result preserves intention, not just converges. Choose each field's type for the conflict you want. |
| `handle-offline-and-reconnection` | `realtime-collaboration-engineering` | Design the offline-edit and reconnection path: buffer local ops with stable causal identity while disconnected, resume from the last acknowledged version on reconnect, and merge the delta — never replay offline edits as brand-new. The reconnect merge is where naive builds lose data. |
| `scale-the-sync-server` | `realtime-collaboration-engineering` | Scale a realtime sync server: shard by document/room with connection affinity, fan-out ops within a room, offload snapshots to durable storage, bound document growth (tombstone GC + compaction), and enforce access control at the sync boundary. Horizontal scale is more rooms, not a bigger single node. |
| `choose-recsys-approach` | `recommendation-systems-engineering` | Choose the recommendation approach — popularity/heuristic baseline, collaborative filtering, content-based, hybrid, two-tower/embedding retrieval, or sequential — from data volume, sparsity, cold-start severity, latency, and interpretability. Use when starting a recsys or deciding whether to add model complexity. |
| `evaluate-recommenders` | `recommendation-systems-engineering` | Evaluate recommenders correctly — a temporal train/test split, per-stage offline metrics (recall@k, precision@k, nDCG, MAP, coverage, diversity, novelty) against a popularity baseline, AND the online A/B that is the real verdict. Use to build an eval harness or diagnose an offline-vs-online gap. |
| `handle-cold-start-and-serving` | `recommendation-systems-engineering` | Handle cold-start (new users and new items) and serve recommendations within a latency budget — content/popularity fallbacks, onboarding & exploration, ANN retrieval, precompute/caching, online feature fetch, and popularity-on-timeout fallback. Use when new entities recommend poorly or serving is too slow. |
| `aml-program-review` | `regulatory-compliance` | Structured review of an AML program against FATF / FFIEC expectations — the 5 pillars, common findings, regulatory citations with primary sources. Used by `aml-kyc-analyst` (primary). |
| `bma-licensing-classification` | `regulatory-compliance` | Classify a Bermuda (non-insurance) entity into its BMA sector + licence class and resolve its AML/ATF position before any capital/Code/filing advice. Used by `bma-financial-institutions-specialist`. Traverses the BMA decision trees, then the sector files. |
| `compliance-policy-authoring` | `regulatory-compliance` | Draft or refresh a compliance policy that survives an exam and an annual refresh — scope the regime, keep policy separate from procedure, frame conduct as outcomes, give every layer a cite + named owner + exceptions. Used by policy-and-procedure-writer. Gap analysis against a new regulation stays in regulatory-mapping. |
| `control-testing` | `regulatory-compliance` | Compliance / second-line control testing rubric — design adequacy + operating effectiveness for compliance controls (KYC quality, monitoring rule tuning, training coverage, regulatory-mapping freshness). Distinct from SOC1/SOC2 financial-control testing — second-line compliance testing has different scoping, sampling, and reporting. Reach for this skill when scoping a periodic compliance-monitoring program, training MI/QC analysts, or responding to an exam request for "evidence your controls work." Used by `risk-and-controls-specialist` (primary) and `aml-kyc-analyst`. |
| `examination-readiness` | `regulatory-compliance` | Pre-exam playbook for regulator examinations — PBC tracker, walkthrough rehearsal, mock interviews, exam-week posture, MRA / MRIA / management-letter response patterns. Used by `examination-prep-specialist` (primary). |
| `kyc-edd-review` | `regulatory-compliance` | KYC file + EDD review playbook — risk-rating logic, BOI / UBO verification, source-of-wealth vs source-of-funds, EDD trigger conditions, file completeness checklist, sign-off chain. Reach for this skill when reviewing a single customer file, designing the firm's KYC standard, or training analysts. Used by `aml-kyc-analyst` (primary). |
| `regulatory-mapping` | `regulatory-compliance` | Map internal controls / policies / procedures to specific regulatory citations (regulator + section + paragraph). Gap-analysis output format. Used by `risk-and-controls-specialist` + `policy-and-procedure-writer`. |
| `risk-register-build` | `regulatory-compliance` | Build / refresh an enterprise risk register that survives audit committee scrutiny — three lines of defense assignment, inherent + residual rating math, KRI design, risk-appetite mapping, control coverage, and the half-yearly refresh cadence. Reach for this skill when standing up a new ORM/ERM framework, refreshing the register, or remediating an "outdated register" finding. Used by `risk-and-controls-specialist` (primary) and `policy-and-procedure-writer`. |
| `sanctions-hit-disposition` | `regulatory-compliance` | Disposition framework for sanctions screening alerts — true-match vs false-positive triage, secondary-match evidence chain, escalation criteria, documented-rationale template, list-version capture, and the audit-trail requirements that survive examiner review. Reach for this skill when designing the disposition process or training analysts on hit clearance. Used by `aml-kyc-analyst` (primary). |
| `sar-narrative-drafting` | `regulatory-compliance` | Draft SAR / STR narratives that survive regulator review — typology + the W's + what to omit + reviewer sign-off chain. Used by `aml-kyc-analyst` (primary). Confidentiality class always at least client-confidential; often regulator-only. |
| `supervisory-return-prep` | `regulatory-compliance` | Period-end supervisory / regulatory return preparation playbook — data lineage, maker-checker, materiality / threshold definitions, common return families (FATCA, CRS, BMA EBS, Solvency II, supervisory returns, capital adequacy / RBC), late-filing protocols. Reach for this skill 4-6 weeks before a periodic filing or when responding to a regulator data request. Used by `regulatory-reporting-analyst` (primary). |
| `model-lcoe-and-irr` | `renewable-energy` | Model levelized cost of energy and project IRR together, on net cost after the live incentives, since they answer different questions. Reach for this on any project-economics question. |
| `model-the-interconnection-queue` | `renewable-energy` | Read the interconnection queue, study sequence, and likely upgrade allocation as the project's schedule and cost risk. Reach for this before committing a schedule. |
| `read-asset-performance` | `renewable-energy` | Read availability, degradation, and O&M cost over the 25-year asset life so the IRR rests on real operations. Reach for this on an operating-asset question. |
| `structure-the-incentive` | `renewable-energy` | Structure the project around the incentive pathway that's actually available post-2025, with a date, instead of an expired one. Reach for this on any financing-structure question. |
| `value-storage-dispatch` | `renewable-energy` | Value a battery on its dispatch use-case — arbitrage, demand-charge reduction, capacity — not a flat $/kWh. Reach for this on a storage add. |
| `infer-office` | `report-regeneration` | Stage 1 of the report-regeneration OFFICE (docx) pipeline. Parses a Word .docx template into a schema-valid Report Structure Graph (RSG) via stdlib zipfile + xml.etree over word/document.xml: per-node OOXML body-walk anchor, role, rebind class, confidence, provenance, plus the deterministic data-shaped-literal detector reused from the HTML lane. Stdlib-only, Python 3.9; python-docx optional. |
| `infer-report-structure` | `report-regeneration` | Stage 1 of the report-regeneration HTML pipeline. Parses an HTML template into a schema-valid Report Structure Graph (RSG): per-node stable anchor, role, rebind class, confidence, provenance, plus the deterministic non-inference data-shaped-literal detector that drives the earned-frozen rule. Stdlib-only, runs on Python 3.9. |
| `powerbi-ingest` | `report-regeneration` | Pipeline-facing Power BI ingestion adapter, wrapping scripts/powerbi_probe.py for two modes: `data` runs every dax-kind Binding Manifest binding via REST executeQueries (service-principal/token from ENV ONLY), returning a data.json-shaped fragment keyed by data_query.expression with source_period stamped -- a genuinely independent V1 recompute source for a PBI-sourced value. `shot` captures a fresh report image via ExportToFile (Playwright fallback), packaging it as the embedded image for a regenerate-class PBI node with source_period stamped so period-coherence can catch a stale screenshot. Fail-closed throughout: no creds/route/period => not_captured + the named fallback (manual-figure-labeled-unverified for data, user-provided-image for shot), never a fabricated value or period. Token never logged. Reach for this to turn a Binding Manifest's PBI-sourced bindings into pipeline artifacts. NOT for manifest construction (rebind-manifest) or running the fidelity harness itself (report-fidelity-harness). |
| `rebind-html` | `report-regeneration` | Pipeline stage 3 (the HTML surgical output engine) for report-regeneration. Applies a Binding Manifest to a COPY of an HTML report template and emits the regenerated HTML: frozen nodes stay byte-identical, surgical/regenerate nodes are rebuilt under the zero-literal construction rule (strip the old value, THEN write the new one), needs-review nodes are left untouched but visibly flagged + logged. Stdlib-only (re/html.parser/json), jinja2 optional acceleration, runs on Python 3.9.6. NOT for structure inference (that's an earlier pipeline stage) or the fidelity harness (a separate downstream track) or Office/docx output (a later release lane). |
| `rebind-manifest` | `report-regeneration` | Pipeline stage 2 of report-regeneration (detect -> strip -> rebind): turn an RSG + the OLD template + the new dataset into a schema-valid Binding Manifest and a taint dictionary. Enforces the earned-frozen rule (a data-shaped literal / old-taint / new-dataset value demotes a candidate-frozen node to needs-review), forces raster/embedded-cache nodes to regenerate, and proposes each node's data_query. Reach for this when building or amending a Binding Manifest. |
| `rebind-office` | `report-regeneration` | Pipeline stage 3 (the Office/docx surgical output engine) for report-regeneration — the Office analogue of rebind-html. Applies a Binding Manifest to a COPY of a Word .docx template and emits the regenerated .docx: frozen OPC parts + nodes stay byte-identical, surgical/regenerate nodes are rebuilt under the zero-literal construction rule (strip the old value, THEN write the new), rasters are re-captured (never transplanted), needs-review nodes are left untouched but visibly marked + logged. Stdlib-only (zipfile/xml.etree), edits via the shared rr_anchor OOXML resolver, python-docx/docxtpl optional, runs on Python 3.9. NOT for structure inference (infer-office, an earlier stage), the fidelity harness (a separate downstream track), or HTML output (the rebind-html lane). |
| `report-a11y-gate` | `report-regeneration` | report-regeneration a11y gate: a11y_lint.py is a stdlib, machine-checkable WCAG-subset linter over an output HTML deliverable (the Tier-A a11y FLOOR, not axe-core/veraPDF -- that is the later Tier-B upgrade). BLOCKING rules: img-alt (non-decorative <img> with no alt), html-lang, link-name, button-name, control-label, table-headers. ADVISORY -> manual residue: th-scope, heading-order. Catches seeded defect D3 (missing alt-text) as a crisp img-alt BLOCK. Emits a sub-receipt folded into report-qa-gate (blocking a11y violation -> assembled verdict FAILs; manual residue -> reviewer checklist). HONEST about the ~30-50% machine-checkable floor: the rest is manual residue, never claimed passed. Stdlib-only, exit-coded, path-guarded, no network/subprocess. |
| `report-fidelity-harness` | `report-regeneration` | The load-bearing wall of report-regeneration — the 6-leg + period-coherence fidelity verifier. Runs V1 value-accuracy, V2 frozen-complement diff, V3 re-inference isomorphism, V4 taint-egress over the decoded container, V5 render referee, V6 manifest-coverage, plus period-coherence over a regenerated HTML output, and emits a schema-valid fidelity-receipt (PROBE_ERROR != pass; any not_captured => PARTIAL, never a fake PASS). V2/V4/V6/period-coherence are genuinely ML-free. Stdlib-only, Python 3.9-safe, no network. Reach for this to prove a regenerated report leaked no old-client data and changed nothing outside its bound anchors. NOT for report generation or inference (that is the infer/rebind track). |
| `report-gold-standard-rubric` | `report-regeneration` | The Phase-5 iterate-to-gold-standard loop contract for report-regeneration — score a review-ready draft against 4 dimensions (Accurate HARD FLOOR / Dynamic / Inclusive / Polished), each anchored to a deterministic harness leg with an honest judged residue. Owns the loop mechanics: stop = PASS or plateau(2) or cap(6), monotonic ratchet (revert on any regression), per-node edit budget, N=3 median for judged dims, and the do-no-harm zero-diff fixture. Also owns feedback-instrumentation: classify the client's real peer-review edits substantive-vs-mechanical and feed that back to tune the bars. Use after report-fidelity-harness emits a receipt and before a draft is handed to the human peer reviewer. |
| `report-injection-guard` | `report-regeneration` | report-regeneration prompt-injection / untrusted-content gate: injection_guard.py runs two deterministic, ML-free checks the six-leg fidelity harness cannot. (1) PARTITION-ANOMALY gate on the Binding Manifest -- flag a force-all-frozen shape (frozen fraction above a calibrated ceiling, OR zero mutable bindings on a report carrying N data-shaped tokens). (2) PROVENANCE-BOUND NARRATIVE on every regenerate slot -- every number/currency/percent/date/URL/email/bare numeric identifier/imperative must trace to a manifest binding; un-provenanced -> BLOCK. Treats all template/source/OCR text as DATA, never instructions. Catches seeded defect D13 (force-all-frozen + un-provenanced attacker prose). Emits a sub-receipt folded into report-qa-gate (blocking finding -> assembled verdict FAILs). Stdlib-only, exit-coded, path-guarded, no network/subprocess. |
| `report-qa-gate` | `report-regeneration` | Pipeline stage 5 of report-regeneration: collapses a fidelity-harness receipt (fidelity-receipt.schema.json, the six-leg + period-coherence harness) PLUS the two adjacent-gate sub-receipts (report-a11y-gate + report-injection-guard, both OPTIONAL) into ONE tiered verdict via qa_gate.py -- any BLOCKING leg fail OR a blocking a11y/injection failure => FAIL; any not_captured/PARTIAL/PROBE_ERROR leg or missing leg => PARTIAL (never PASS); every leg pass + no blocking a11y/injection => PASS (review-ready draft). Also emits a manual-residue checklist (human-WCAG residue, needs-review nodes, not_captured legs, V1 binding-correctness 'values unverified' note, folded a11y residue) that is NEVER empty. Stdlib-only, exit-coded, path-guarded. Does not run the harness/gates itself -- consumes their receipts. |
| `cma-and-pricing-strategy` | `residential-real-estate-brokerage` | Build a defensible comparative market analysis and list price: select genuinely comparable sales, apply explicit adjustments, produce a supported price range, and script the seller conversation around the comps rather than their target. A CMA is not an appraisal; local figures are verify-at-use. |
| `commission-split-and-cap-economics` | `residential-real-estate-brokerage` | Model brokerage commission economics: compare split, cap, and fee models at an agent's expected GCI, compute company dollar per agent and the cap crossover point, and weigh the recruiting/retention trade-off. Commission rates and fees are business-agreement- and market-specific — verify-at-use. Not legal or tax advice. |
| `listing-launch-and-marketing` | `residential-real-estate-brokerage` | Launch a listing to win the first weekend: sequence prep/staging, accurate and complete MLS entry, professional photography, and a coordinated marketing push to go-live. The listing gets one first-weekend of peak attention — everything happens before that, not after a price drop. Fair-housing-clean copy throughout. |
| `transaction-timeline-management` | `residential-real-estate-brokerage` | Run contract-to-close as a dated deadline checklist: reconstruct every contingency and deadline from the effective date (inspection, appraisal, financing, title, closing), track each to resolution or the required notice, and surface at-risk items before they forfeit a remedy. Contingency periods are jurisdiction- and contract-specific — verify-at-use. |
| `close-the-food-cost-gap` | `restaurant-operations` | Decompose actual vs theoretical food cost into waste, portioning, price, and theft, so the fix targets the real driver. Reach for this when food cost moves. |
| `engineer-the-menu` | `restaurant-operations` | Place every item on the contribution-margin × popularity matrix and move the mix, instead of cutting prices, to raise margin. Reach for this when margins are thin. |
| `rank-multi-unit` | `restaurant-operations` | Rank comparable units against each other, normalized for format and daypart, to find where the margin actually is. Reach for this on a portfolio review. |
| `read-prime-cost` | `restaurant-operations` | Lead any four-wall read with prime cost (food + labor) before decomposing either half, so the master number frames the diagnosis. Reach for this on any margin problem. |
| `schedule-to-demand` | `restaurant-operations` | Build a labor plan to forecast demand by daypart that holds the service line, so a labor cut doesn't cost more than it saves. Reach for this on a labor problem. |
| `inventory-and-replenishment` | `retail-store-operations` | Run a store inventory accuracy and replenishment design: diagnose out-of-stocks and phantom inventory, set replenishment triggers (reorder point, safety stock with explicit service-level target), design a cycle-count program, and build BOPIS inventory integrity controls. |
| `labor-scheduling` | `retail-store-operations` | Build or diagnose a store labor model: translate hourly traffic data into a coverage-ratio schedule, decompose a labor % of sales variance into rate vs. hours vs. demand, size a flex/part-time headcount for a seasonal period, and flag predictive-scheduling compliance exposure. |
| `merchandising-and-assortment` | `retail-store-operations` | Run a merchandising and assortment analysis: evaluate category health via GMROI, design or audit a planogram for space-to-sales alignment, build a sell-through-triggered markdown ladder, or define an assortment architecture (depth vs. breadth, role by SKU, private label vs. national brand). |
| `motion-planning-and-control` | `robotics-autonomous-systems-engineering` | Build the motion stack: Nav2 for mobile-base navigation vs MoveIt for manipulator planning, kinematics and the TF tree (REP 105), trajectory generation inside velocity/acceleration/jerk limits, ROS 2 actions for long-running motion, and control loops (PID vs MPC). Trust the frames before the planner. Safety-bearing limits are verify-at-use. |
| `perception-and-state-estimation` | `robotics-autonomous-systems-engineering` | Build the perception stack: sensor fusion of complementary modalities (lidar/camera/IMU/odometry/GPS), SLAM vs known-map localization, EKF/UKF/particle-filter state estimation, object detection with propagated uncertainty, and behavior-tree / state-machine autonomy that fails safe. Time sync and frames come before the fusion math. Benchmark accuracy is verify-at-use. |
| `ros2-architecture-and-dds` | `robotics-autonomous-systems-engineering` | Design the ROS 2 computation graph: nodes and their boundaries, topics/services/actions, the RMW/DDS layer and per-topic QoS, executors & callback groups, node composition, and the real-time vs non-real-time split. QoS and the real-time boundary are architecture decisions, not runtime flags. Distro/DDS specifics are verify-at-use. |
| `sim-to-real-and-safety` | `robotics-autonomous-systems-engineering` | Cross the sim-to-real gap and build the safety architecture: simulate every behavior before actuating, measure and close the reality gap (dynamics, sensor noise, latency, domain randomization), and make safety a system property — monitored safe state, bounded actuation, degraded modes, and a risk assessment. Functional-safety standard pointers (ISO 10218 / ISO 13849 / ISO 12100) are verify-at-use. |
| `demo-design` | `sales-engineering` | Design a demo that maps to the buyer's discovered pain instead of touring features — build a Great Demo!-style storyline (show the compelling result first, then peel back only the layers the buyer asked for), tie every moment to a discovered pain and its business impact, and script the honest shipped-vs-roadmap boundaries. Reach for this after discovery, when the user needs to build or tighten a demo. Used by `sales-engineer` (primary). |
| `poc-success-criteria` | `sales-engineering` | Decide if a POC is warranted and, if so, write measurable success + exit criteria a champion signs before kickoff, scope a time-boxed plan, and build the evaluation scorecard that converts a passed POC to a technical win. Reach for this when a prospect asks for a proof-of-concept or pilot, or when an SE needs to keep a POC from sprawling. Used by `poc-evaluation-lead` (primary) and `sales-engineer`. |
| `rfp-response` | `sales-engineering` | Respond to an RFP/RFI/RFQ — decide go/no-go before committing effort, then build a compliant, scannable requirement-by-requirement response matrix (comply / partial / roadmap / no-bid), thread the win themes, and run the compliance checklist so the bid isn't disqualified on a technicality. Reach for this when a formal RFP/RFI lands. Used by `rfp-security-response-specialist` (primary). |
| `security-questionnaire-response` | `sales-engineering` | Answer a security / vendor-risk questionnaire (SIG, CAIQ, VSA, or a bespoke one) honestly and defensibly — map every answer to an actual control and its SOC 2 / ISO 27001 evidence, state shipped vs roadmap vs not-applicable plainly, flag any unverifiable claim for security-reviewer before it ships, and capitalize answers into a reusable, freshness-dated trust-answer library. Reach for this on any inbound security questionnaire. Used by `rfp-security-response-specialist` (primary). |
| `technical-discovery` | `sales-engineering` | Run value-based technical discovery before any demo or POC — frame the deal with MEDDPICC, surface the prospect's pain and its quantified business impact, identify the decision criteria/process/champion, and capture it all in the discovery-notes template so the demo can be tailored to real pain. Reach for this when the user has (or just had) a discovery call, or is about to demo with no discovered pain. Used by `sales-engineer` (primary) and `poc-evaluation-lead`. |
| `build-forecast` | `sales-revops` | Build a stage-weighted, aged forecast with coverage — surface the at-risk deals. Reach for this on a forecast question. |
| `design-quota` | `sales-revops` | Design quota to ramped-rep capacity and read the attainment distribution it implies. Reach for this on a quota or territory question. |
| `diagnose-funnel` | `sales-revops` | Diagnose win-rate and sales-cycle stage-by-stage — find the leaking stage before adding leads. Reach for this on a conversion question. |
| `model-velocity` | `sales-revops` | Model sales velocity across its four levers (deals, win-rate, ACV, cycle) and show the trade-offs. Reach for this on a speed question. |
| `read-pipeline-coverage` | `sales-revops` | Read coverage as a ratio against quota by segment and close-date, not a total pipeline number. Reach for this on a coverage question. |
| `bulk-rest-api-client` | `salesforce` | Build Bulk API 2.0 ingest and query jobs for high-volume data movement. Use when loading or extracting large datasets over the REST Bulk API rather than row-by-row. |
| `data-loader-runbook` | `salesforce` | A safe data-load runbook — sandbox-first, backup, dedup, and verify — for any bulk data operation. Use before loading, updating, or deleting production data at volume. |
| `lwc-component-scaffold` | `salesforce` | Scaffold a Lightning Web Component bundle (.html / .js / .js-meta.xml) with an FLS-aware Apex controller. Use when creating a new LWC. |
| `salesforce-release-pipeline` | `salesforce` | Stand up a 2GP + DevOps Center release pipeline — packaging, dependency-ordered deploy, test gate, and promotion across environments. Use when designing or running a Salesforce release process. |
| `soql-authoring` | `salesforce` | Write selective, bulk-safe SOQL that binds its variables and avoids non-selective-query errors on large objects. Use when authoring or fixing a SOQL query, especially against high-volume objects. |
| `booking-and-no-show-control` | `salon-spa-operations` | Control the perishable-inventory leak: design a no-show / late-cancel policy with deposits or card-on-file, a rebook-at-checkout habit, a reminder cadence, and a waitlist that backfills cancellations. Prevent the no-show first; enforce the policy second. |
| `chair-and-room-utilization` | `salon-spa-operations` | Read the salon/spa as a stack of perishable chair-hours and room-hours. Compute utilization (productive hours booked / available), test whether current capacity is full before adding a chair, room, or provider, and tie utilization to the staffing model and demand pattern. |
| `compensation-models-commission-vs-booth-rent` | `salon-spa-operations` | Model provider pay deliberately: commission tiers vs hourly-plus-commission vs booth rent vs hybrid. Compare risk, upside, control, and cost against the provider's book — and flag the worker-classification (employee vs 1099) consequence for a licensed professional. Economics only, not legal advice. |
| `retail-attach-and-service-mix` | `salon-spa-operations` | Lift the two margin levers the chair controls: retail attach (product sold alongside the service, on trust the provider already earned) and service mix (tilting the book toward higher-margin services). Read revenue and margin per service hour, not just bodies through the door. |
| `build-judgment-list` | `search-relevance-engineering` | Build graded relevance judgments (explicit or click-derived) and an offline harness before tuning. Reach for this when there's no eval. |
| `fix-analyzer` | `search-relevance-engineering` | Root-cause a relevance bug in tokenization/analysis/mapping before touching the ranking formula. Reach for this on a no-match or wrong-match bug. |
| `measure-relevance` | `search-relevance-engineering` | Compute NDCG, MRR, and precision@k against the judgment list with a baseline. Reach for this before any tuning. |
| `set-latency-budget` | `search-relevance-engineering` | Set a p95 latency budget, decompose per-stage latency, and tune relevance within it. Reach for this on a speed/capacity question. |
| `validate-online` | `search-relevance-engineering` | Confirm an offline relevance win with an online A/B on CTR/conversion before declaring victory. Reach for this after an offline gain. |
| `appsec-scanning` | `security-engineering` | Stand up tuned application security scanning in CI: SAST + SCA per-PR, DAST on a deployed build, secret-scanning, and triage by exploitability×blast-radius rather than raw CVSS. |
| `secrets-detection-and-remediation` | `security-engineering` | Playbook for detecting secrets committed to Git — pre-commit hooks, CI scanning, historical repo scanning — and the full remediation procedure when a secret is found: rotation, history rewrite, and the post-incident checklist. |
| `secrets-management` | `security-engineering` | Manage secrets safely: detect them in code/config/logs, vault them, federate with short-lived credentials, rotate on a schedule, and treat any committed secret as compromised (rotate, don't just delete). |
| `supply-chain-security` | `security-engineering` | Secure the software supply chain from the consume side: ingest the SBOM, triage CVEs by reachability, pin dependencies with a deliberate update cadence, verify SLSA provenance, and defend against malicious packages. |
| `threat-modeling-stride` | `security-engineering` | Threat-model a design with STRIDE: draw the data-flow diagram and trust boundaries, walk STRIDE per element, rank threats by likelihood×impact, and map each to a mitigation or a routed accepted-risk. |
| `manage-facility-operations-and-security` | `self-storage-operations` | Run a self-storage facility's operations — choose the operating model (staffed vs hybrid vs remote-unmanned + kiosk) against the site's volume and labor market, set the staffing, harden security and access control (gate/keypad, individual door alarms, cameras with retention, lighting, overlock discipline), keep climate control, maintenance, and curb appeal to standard, protect the move-in/move-out flow (agreement, protection-plan and autopay offer, gate-code provisioning, overlock-release), and standardize a multi-site portfolio with an SOP, PMS-config parity, a district-manager cadence, and a per-site scorecard. Reach for this when the user asks "staffed or remote/kiosk?", "how do I tighten security after a break-in?", "our move-in process is leaky", or "how do I run five sites to one standard?". Used by `self-storage-operations-lead` (primary). |
| `optimize-occupancy-and-dynamic-pricing` | `self-storage-operations` | Turn a self-storage facility's occupancy and rate picture into a revenue plan by reading physical vs economic occupancy, comparing street rate to in-place rate by unit type, designing the ECRI program (existing-customer rate increases — cadence, increase size by tenure and gap, churn guardrail), setting dynamic-pricing floors and ceilings, rebalancing the unit mix, and pricing promotions against the ECRI that recovers them — returning the recommended moves with projected NOI lift and the conditions that would flip them. Reach for this when the user asks "how do I raise rates on existing tenants?", "my street and in-place rates are far apart", "should I run a $1-first-month promo?", or "why is my full facility not making money?". Used by `storage-revenue-and-occupancy-specialist` (primary). |
| `run-delinquency-and-lien-process` | `self-storage-operations` | Run a self-storage tenant from first missed payment to lien auction as a disciplined, state-specific process — start with prevention (autopay enrolment, late-fee discipline), then walk the statutory lien timeline (late fees → gate lockout/overlock → pre-lien and lien notices → advertising/public notice → auction via StorageTreasures/Lockerfox → sale of goods → surplus handling), flagging at every step that lien law varies by US state, attaching the state and a retrieval date, and marking the whole thing operational guidance and NOT legal advice. Reach for this when the user asks "I have tenants 60+ days past due — what now?", "walk me through the lien and auction process", "when can I overlock a unit?", or "how do I handle auction surplus?". Used by `storage-revenue-and-occupancy-specialist` (primary). |
| `manage-census-flow` | `senior-care-operations` | Read census as a flow of move-ins, move-outs, and length of stay, not a point number, so the right lever is pulled. Reach for this on any occupancy question. |
| `price-to-acuity` | `senior-care-operations` | Build acuity-based pricing that captures the care cost by level, instead of a flat rate, to protect margin. Reach for this on a pricing question. |
| `quantify-labor-and-turnover` | `senior-care-operations` | Read labor cost, agency reliance, and turnover as quantified unit economics, since they drive both margin and quality. Reach for this on a cost question. |
| `read-quality-and-compliance` | `senior-care-operations` | Read survey readiness, incidents/falls, and quality measures as existential operational risk, as decision-support. Reach for this on a quality question. |
| `staff-to-acuity-ppd` | `senior-care-operations` | Build a staffing model on acuity-weighted hours-per-resident-day, not a fixed ratio, so labor matches need. Reach for this on a labor question. |
| `design-event-driven-architecture` | `serverless-engineering` | Decompose a workload into functions and events for a serverless/event-driven design — the serverless-vs-container-vs-managed-service call (and where serverless is the WRONG choice: steady high-throughput, long-running, tight-latency, pooled-RDBMS), sync-vs-async boundaries per interaction, orchestration (state machine/saga) vs choreography (event bus), the event schemas & contracts, serverless-friendly storage vs a connection-pool-hostile RDBMS, and the dual-write/outbox fix — designed around events and contracts so it never becomes a distributed monolith (lambda pinball). Reach for this on 'serverless vs containers vs managed service?', 'decompose this into functions/events', 'state machine vs event bus?', or 'can our RDBMS sit behind these functions?'. Driven by `serverless-architect` (primary). |
| `harden-serverless-runtime` | `serverless-engineering` | Harden a serverless function/pipeline for the runtime & ops realities — cold starts (causes, the provisioned/warm-concurrency vs package-slimming trade-off against the latency budget, and what NOT to over-provision), concurrency & account/region limits & throttling with downstream (RDBMS) protection, idempotency keys + exactly-once-EFFECT (delivery is at-least-once), DLQ + poison-message policy, and retry/backoff/visibility-timeout so a queue is never an infinite-retry outage. Reach for this on 'fix our cold starts', 'this queue double-processes / retries forever', or 'we're getting throttled — plan our concurrency'. Driven by `serverless-runtime-and-ops-engineer` (primary). |
| `model-serverless-cost-and-scale` | `serverless-engineering` | Model serverless cost and scale — a per-invocation cost model (invocations × duration × memory + requests + data-transfer + downstream), the serverless-vs-container crossover point where steady high-throughput makes always-on cheaper (and 'serverless is cheaper' stops being true at scale), and concurrency/quota/limit planning (account/region caps, reserved/provisioned concurrency, throttle headroom). Reach for this on 'is serverless actually cheaper here?', 'where do we cross over to containers?', or 'plan our concurrency/quota headroom'. Driven by `serverless-runtime-and-ops-engineer` (primary), consulted by `serverless-architect` for the cost side of the serverless-vs-not call. |
| `design-shopify-build` | `shopify-app-engineering` | Design a Shopify build from who-uses-it and does-it-ship-to-the-App-Store backward: the app type (custom vs public vs theme/extension), the integration surface (Admin GraphQL API, webhooks, App Bridge/Polaris embedded UI, extensions), the current-generation customization path (Shopify Functions + checkout UI extensions, never script tags / checkout.liquid), the metafields/metaobjects data model, the storefront choice (Online Store 2.0 theme — the default — vs Hydrogen/Storefront API headless), and the commercial/safety envelope (Billing API, OAuth + session tokens, GraphQL cost-based rate limits + bulk operations, mandatory GDPR/data webhooks, App Store review). Reach for this when the ask is 'how should we build this on Shopify?', 'public app or theme?', 'embedded or headless?', or 'Functions or script tags?'. Used by `shopify-app-architect` (primary). |
| `ship-app-store-ready` | `shopify-app-engineering` | Make a Shopify build correct, secure, and App-Store-review-ready: HMAC-verify every webhook + process idempotently + fast-200-async, implement the mandatory GDPR/data webhooks (customers/redact, shop/redact, customers/data_request), authenticate embedded requests with session tokens (not cookies) over OAuth, charge through the Billing API, handle GraphQL cost-based rate limits with back-off + bulk operations (never a hot pagination loop), pin the Admin API version, and build the current-generation way (Shopify Functions / checkout UI extensions / App Bridge+Polaris, never script tags or checkout.liquid). Reach for this when the ask is 'wire up OAuth + a webhook', 'why are we getting throttled?', 'is this ready for App Store review?', or 'build the Function/extension/embedded page'. Used by `shopify-app-engineer` (primary). |
| `build-flat-rate-book` | `skilled-trades-contracting` | Build a flat-rate price book from loaded labor and real material cost with good/better/best options, so service pricing protects margin. Reach for this on service pricing. |
| `build-the-loaded-rate` | `skilled-trades-contracting` | Build a billable labor rate that absorbs wage, burden, vehicle, tools, insurance, and overhead, so every hour sold makes money. Reach for this before any estimate or flat-rate book. |
| `cut-callbacks` | `skilled-trades-contracting` | Read first-time-fix and quantify the callback labor cost, then fix truck stocking and diagnosis, since a callback is a free truck roll. Reach for this when callbacks are high. |
| `raise-billable-efficiency` | `skilled-trades-contracting` | Read the billable-hour ratio and cut non-billable drive, restock, and rework time, since billable efficiency is the field's master number. Reach for this on a productivity question. |
| `read-the-sales-levers` | `skilled-trades-contracting` | Read close rate and average ticket and option-presentation, since they move revenue more than lead volume. Reach for this before spending on marketing. |
| `bill-rate-margin-modeling` | `staffing-operations` | Decompose staffing margin into bill minus pay minus burden, itemize the burden stack, and locate whether a compression is pricing, pay, burden, or mix — before anyone calls it a pricing problem. Reach for this when gross margin or spread is moving and the cause is unclear. |
| `competitive-positioning-analysis` | `staffing-operations` | Build a segment-by-segment competitive-positioning analysis for a staffing firm — placing it on a players-by-segment grid, naming where it wins and where scale competitors lead, with a source on every claim. Reach for this when the question is where the firm is strong vs. losing in the competitive set. |
| `credentialing-pipeline-design` | `staffing-operations` | Design or audit the credentialing and clearance pipeline as a measured part of time-to-fill, with stage timings, document-completion gates, and the parallelizable steps that compress time-to-start. Reach for this when time-to-start lags time-to-offer or fall-off concentrates between accept and start. |
| `fill-rate-diagnostics` | `staffing-operations` | Diagnose a fill-rate move without blaming the wrong thing — by pinning the denominator, checking the seasonal boundary, splitting supply from order-quality, and pairing with time-to-fill including the credentialing clock. Reach for this when fill rate dropped and the cause is unclear. |
| `funnel-leak-diagnosis` | `staffing-operations` | Locate where the recruiting pipeline leaks by decomposing it stage by stage (order to workable to submittal to interview to offer to accept to start to billing), naming the leak stage and its likely cause. Reach for this when placements or submittal-to-fill are down and you need to find where candidates fall out. |
| `kpi-dashboard-design` | `staffing-operations` | Lay out a staffing KPI dashboard so the most decision-relevant number is read first, every tile pairs with its partner metric, and a red number explains itself via drill-down. Reach for this when turning a scorecard spec into a dashboard layout (not the build — the design). |
| `recruiter-capacity-model` | `staffing-operations` | Right-size a recruiting desk by modeling fillable-order supply against the reqs a recruiter can carry at target conversion, distinguishing nominal from fillable orders and under-fed from under-staffed. Reach for this when the question is whether to hire more recruiters or whether the team is the right size. |
| `seasonality-aligned-readout` | `staffing-operations` | Produce a staffing readout that compares like-cycle-to-like-cycle instead of calendar-quarter-to-calendar-quarter, so the academic or healthcare seasonality doesn't masquerade as a performance change. Reach for this when a fill-rate or volume comparison crosses a seasonal boundary. |
| `staffing-scorecard-build` | `staffing-operations` | Build a staffing operations scorecard where every KPI carries a definition, formula, window, baseline, owner, drill-down, and a triggered action — so an operator can act on it Monday morning. Reach for this when standing up a new scorecard or auditing one that reports numbers nobody acts on. |
| `trend-analysis-readout` | `staffing-operations` | Produce a defensible staffing market-trend readout — segment-resolved, SIA-anchored, triangulated across primary sources, with the inflection (not just the level) named and soft numbers marked. Reach for this when a client wants the market read for healthcare and/or education staffing. |
| `build-investor-pipeline` | `startup-fundraising` | Build a tiered, stage-fit investor pipeline and a warm-intro-first outreach sequence for a founder running a round. Produces a target list scored by stage-fit + thesis-fit + check-size, a warm-path map for each target, and a sequenced outreach plan that builds momentum. Reach for this when the user asks "who should I pitch?", "build my investor list", or "how do I run outreach?". Used by `fundraising-strategist` (primary); coordinated with `pitch-and-narrative-coach`. |
| `model-cap-table-and-dilution` | `startup-fundraising` | Model a startup cap table and the dilution a round causes — including option-pool shuffle, pro-rata, and post-money SAFE conversion — with worked arithmetic. Produces a post-round ownership table and surfaces the post-money-cap dilution gotcha. Reach for this when the user asks "what does my cap table look like after this round?", "how much do I get diluted?", "how does my SAFE convert?", or "what option pool should I set aside?". Used by `fundraising-strategist` (primary). |
| `prepare-data-room` | `startup-fundraising` | Assemble a founder's fundraising data room — the structured set of documents investors expect in diligence — so a "send me the data" request never stalls the round. Produces a stage-appropriate checklist organized by section (corporate, financials, cap table, product/tech, traction, team, legal/IP) with a what-to-include and a what-to-redact note per item. Reach for this when the user asks "what goes in a data room?" or "I got a diligence request — am I ready?". Used by `fundraising-strategist` (primary). |
| `low-latency-live-streaming` | `streaming-media-engineering` | Hit a live-streaming latency target: pick the approach (standard HLS/DASH, LL-HLS/LL-DASH with chunked CMAF, or WebRTC for sub-second/interactive) from the required end-to-end latency and scale, then budget latency across capture/encode, segment & part duration, chunked transfer, live origin, CDN, and the player live-edge buffer — trading latency against rebuffer risk deliberately. Protocol/latency specifics verify-at-use. |
| `playback-qoe-and-delivery` | `streaming-media-engineering` | Deliver playback quality-of-experience: integrate the player (hls.js / dash.js / Shaka / ExoPlayer / AVPlayer) to the chosen protocol and DRM, tune the ABR algorithm (buffer- vs throughput-based, start bitrate, switch thresholds, caps) for stability, measure QoE by rebuffer ratio / startup time / average bitrate / VSF, and tune CDN/edge cache (cache-key, TTL, prefetch) — all instrumented with playback analytics. Player/CDN/QoE specifics verify-at-use. |
| `streaming-architecture-and-protocol-selection` | `streaming-media-engineering` | Choose VOD vs live and the streaming protocol (HLS / MPEG-DASH / CMAF / LL-HLS / WebRTC) on the use-case, latency target, and device/browser reach — then commit to a packaging format (CMAF hedge), an origin/edge design, a single-vs-multi-CDN strategy, and the multi-DRM matrix (Widevine / FairPlay / PlayReady) the reach implies. Protocol/DRM/CDN specifics verify-at-use. |
| `transcoding-and-abr-ladder` | `streaming-media-engineering` | Choose codecs in tiers (H.264 reach floor + HEVC/AV1/VP9 efficiency), design the ABR ladder per-title from content complexity rather than a fixed table, build the FFmpeg pipeline for the quality/throughput/cost triangle (CRF vs 2-pass, GPU vs CPU, chunked parallel, GOP/segment alignment), and package once to CMAF/fMP4 with captions and loudness-normalized audio. Codec/flag/bitrate specifics verify-at-use. |
| `design-dunning-and-recovery` | `subscription-billing-engineering` | Design and automate failed-payment recovery (dunning) — retry schedule, smart/adaptive retries, grace period, customer comms sequence, and entitlement-downgrade policy — trading recovered revenue against churn of good customers. Use for involuntary-churn reduction. |
| `implement-metered-billing` | `subscription-billing-engineering` | Implement usage-based / metered billing correctly — idempotent usage recording, aggregation & rating to billable quantities, on-time usage reporting before invoice close, and counted-vs-billed reconciliation. Use when billing on API calls, seats used, GB, events, or any consumption metric. |
| `model-plans-and-pricing` | `subscription-billing-engineering` | Model the plan / price / entitlement structure for a recurring-billing system — choose flat vs tiered vs per-seat vs usage/metered vs hybrid, define entitlements, and set proration/trial/coupon rules. Use when starting a billing build or re-pricing an existing product. |
| `demand-forecasting` | `supply-chain-planning` | Build a defensible demand forecast: traverse the forecast-method selection tree, clean demand history, select and fit the statistical model, measure MAPE and bias on a holdout period, design the consensus overlay process, and hand off the error distribution to inventory policy. |
| `inventory-policy-and-safety-stock` | `supply-chain-planning` | Set a defensible inventory policy: segment SKUs with ABC/XYZ, select the replenishment method per segment, calculate safety stock from the service level and variability inputs, calculate reorder point and EOQ, and quantify the working-capital tradeoff. |
| `sop-process` | `supply-chain-planning` | Design or facilitate the monthly S&OP/IBP cycle: run the five-step gate sequence (product review → demand review → supply review → pre-S&OP reconciliation → executive S&OP), produce the gap analysis, build scenarios, and close the cycle with a decision record. |
| `content-promotion-runbook` | `tableau` | Step-by-step runbook for promoting Tableau workbooks and data sources from development through test to production using the Content Migration Tool, REST API, and tabcmd — with pre-promotion checklists, rollback steps, and the governance gates that prevent silent data breaks. Owned by tableau-admin. |
| `dashboard-layout-review` | `tableau` | Checklist-driven review for Tableau dashboard layout, chart-type selection, formatting, and accessibility — covering the question-first design principle, attention hierarchy, filter placement, colour and font conventions, and the five layout anti-patterns that confuse users. Owned by tableau-viz-engineer. |
| `embedding-connected-apps-jwt` | `tableau` | A step-by-step setup for secure Tableau embedding with a Connected App (Direct Trust) + a server-minted JWT and the Embedding API v3 — minting the right claims, scoping the token, and binding the JWT identity to the RLS entitlement key. Use when embedding a viz in an app with per-user or per-tenant data isolation. The auth verdict escalates to ravenclaude-core/security-reviewer. |
| `extract-performance-tuning` | `tableau` | Playbook for diagnosing and fixing slow Tableau workbooks: the measurement-first approach, the six extract optimisation levers, query performance recording interpretation, and the view-level and data-source-level fixes that address 90% of performance complaints. Owned by tableau-data-architect. |
| `lod-expression-builder` | `tableau` | Step-by-step playbook for diagnosing the grain mismatch that causes wrong numbers, then selecting and constructing the right LOD expression (FIXED, INCLUDE, EXCLUDE) or table calculation. Includes the LOD-vs-table-calc decision, worked examples, and the common double-counting fixes. Owned by tableau-viz-engineer. |
| `rls-design-checklist` | `tableau` | Gate-by-gate checklist for designing Tableau row-level security (RLS): mechanism selection (user filter vs entitlement table vs data-policy VDM), implementation verification, performance impact assessment, and the mandatory security-reviewer escalation criteria. Owned by tableau-admin. |
| `workbook-performance-audit` | `tableau` | A repeatable, evidence-first Tableau workbook performance audit — run the Performance Recorder, read the longest events, and apply the right lever per dominant event category (Executing Query / Computing / Rendering / Connecting). Use when a workbook or dashboard is slow and you need the cause, not a guess. |
| `handle-notices-and-planning` | `tax-preparation-practice` | Respond to an IRS/state notice and run the planning calc by traversing the practice decision tree (identify the notice type & deadline → reconcile the agency figures vs the return → agree/partial/disagree response + substantiation → representation posture: handle vs refer; and for planning: entity-choice SE-tax vs S-corp reasonable-comp → QBI/§199A → retirement & timing levers as scenarios), then return the notice-response plan or the planning scenarios with assumptions and the verify-against-current-law caveat. Reach for this when the user asks 'we got a CP2000 / CP notice — how do we respond?', 'should this client be an S-corp?', 'how do we optimize QBI / retirement / timing?', or 'what's our representation posture?'. Used by tax-preparation-specialist (primary) and tax-practice-lead. |
| `plan-engagement-and-capacity` | `tax-preparation-practice` | Plan the client mix, open the engagement, and size busy-season capacity by traversing the practice decision tree (engagement accept/decline & risk screen → client-mix/niche → engagement letter + organizer scope → busy-season volume × preparer-hours vs reviewed-hours → extension policy as load valve → pricing/realization model), then return the accept/decline call, the engagement letter & organizer scope, the capacity/staffing plan, and the pricing model with the conditions that resize it. Reach for this when the user asks 'what client mix should we take?', 'draft our engagement letter / organizer', 'how do we plan busy-season capacity?', or 'how should we price returns?'. Used by tax-practice-lead (primary) and tax-preparation-specialist. |
| `run-return-preparation-workflow` | `tax-preparation-practice` | Run a return from organizer through e-file by traversing the practice decision tree (organizer & completeness check → entity→form routing: 1040 / 1120 / 1120-S / 1065 → preparation & schedules → self-review vs a separate-reviewer gate → e-file & acknowledgment → extensions 4868/7004 & quarterly estimates), then return the prepared return, the completeness gaps, the review findings, the e-file path, and any extension/estimate schedule. Reach for this when the user asks 'prepare this 1040 / 1120-S / 1065', 'which form does this entity file?', 'review this return before e-file', or 'file an extension and set quarterly estimates'. Used by tax-preparation-specialist (primary) and tax-practice-lead. |
| `cross-repo-project-tracking` | `team-portfolio` | Define and track a project that spans multiple GitHub repos. Use when a piece of work (a launch, a client, a feature) lives across several repositories and you want its status rolled up in one place instead of checked repo-by-repo. Covers the three match rules (repo / label / title-prefix), how an event is attributed to a project, choosing a convention that scales, and reading the per-project status the report and dashboard produce. |
| `cross-team-contributor-analysis` | `team-portfolio` | Analyse the portfolio activity data to identify cross-team contributors, unmatched activity, and load distribution across repos and people. Reach for this skill when a supervisor wants to understand who is contributing where across the team's repos, or when the portfolio output shows unexpected activity patterns. |
| `portfolio-access-review` | `team-portfolio` | Review and tighten the GitHub token scope and hub-repo access configuration for a team-portfolio deployment. Reach for this skill during any security audit, when a team member leaves, when new repos are added to the tracked list, or when a 403 error appears in the collection log. |
| `portfolio-setup` | `team-portfolio` | Stand up centralized multi-repo, multi-person activity tracking for a team. Use when a team works across several GitHub repos and needs one place to see who did what — and a supervisor needs a manage-the-team roll-up that a single-repo activity log can't provide. Walks choosing a hub repo, writing team-portfolio.json (repos + roster + cross-repo projects), wiring the scheduled GitHub Action and the on-demand command, picking a GitHub token, and optionally enabling a hand-maintained narrative layer. |
| `report-cadence-tuning` | `team-portfolio` | Tune the portfolio-tracker scheduled Action cadence, collection-window-days, and report output settings to match the team's actual review rhythm. Reach for this skill when the weekly tracker is generating too much noise, when the window produces gaps or double-counts, or when the supervisor wants a different report frequency. |
| `dependency-mapping` | `technical-program-management` | Build the cross-team dependency graph and derive the critical path — every handoff gets a producer, consumer, due date, and interface contract; cycles and single points of failure get flagged. Use when a program spans multiple teams and you need to know what actually decides the date. |
| `launch-readiness-review` | `technical-program-management` | Run a go/no-go launch-readiness review against written, pre-agreed criteria and design a staged rollout with a tested rollback. Use as a launch approaches — define measurable, owner-assigned criteria first, then facilitate the decision and record any waiver with its risk acceptance. |
| `program-charter` | `technical-program-management` | Turn a fuzzy cross-team mandate into a chartered program — a measurable outcome, a named sponsor, explicit in/out-of-scope boundaries, the teams on the hook, and the starting RAID. Use at the very start, before any planning, whenever a multi-team effort lacks a clear outcome or owner. |
| `choose-seo-strategy-and-priorities` | `technical-seo-engineering` | Diagnose what to fix first for a described site by walking the SEO strategy decision tree (crawl → render → index → understand → rank), fixing the lowest broken rung first, then return the priority diagnosis, the indexation strategy, the E-E-A-T posture, and the conditions that would reorder the priorities. Reach for this when the user asks "our organic traffic is flat — where do we start?", "what should we fix first for SEO?", "which pages should we index or noindex?", or "how do we rank in a helpful-content world?". Used by `seo-strategy-architect` (primary). |
| `design-site-architecture-and-content-model` | `technical-seo-engineering` | From a site's target queries and page classes, design the crawl-efficient information architecture (flat depth, hub-and-spoke topic clusters), the internal-linking model that flows authority to the money pages, and the topical-authority / entity map that tells search engines what the site should own. Reach for this when the user asks "how should we structure the site and internal links?", "design our topic clusters / content model", or "what's our topical-authority / entity map?". Used by `seo-strategy-architect` (primary) and `seo-implementation-engineer`. |
| `implement-technical-seo-and-structured-data` | `technical-seo-engineering` | Implement and verify the technical-SEO layer for a site — crawlability (robots.txt, XML sitemaps, log-file analysis), rendering (CSR→SSR/SSG/prerender), indexation controls (canonical, meta-robots noindex, hreflang), JSON-LD schema.org structured data for rich-result eligibility, Core Web Vitals (INP/LCP/CLS on field data), and redirect-mapped site migrations — each checked against GSC / URL Inspection / the Rich Results Test / server logs. Reach for this when the user asks "fix our crawl/index", "our SPA doesn't rank — is it rendering?", "add schema markup", "improve Core Web Vitals", or "run our site migration without losing rankings". Used by `seo-implementation-engineer` (primary). |
| `api-reference-writing` | `technical-writing-docs` | Write trustworthy developer reference: drive it from the spec (OpenAPI/AsyncAPI) so it can't drift, make every example runnable, document the unhappy path (errors/limits/auth/pagination), and optimize the quickstart for time-to-first-success. |
| `diataxis-classification` | `technical-writing-docs` | Practical guide for classifying documentation into the four Diataxis quadrants (tutorial, how-to, reference, explanation) — with a decision checklist, anti-pattern catalog, and remediation moves. |
| `diataxis-documentation` | `technical-writing-docs` | Apply the Diataxis framework: identify which of the four documentation kinds you're writing (tutorial/how-to/reference/explanation), keep them separate, and organize the whole docs set around the reader's journey rather than the system's structure. |
| `docs-as-code-site` | `technical-writing-docs` | Run docs like software: pick the tooling by needs (Docusaurus/Mintlify/MkDocs/Starlight), keep docs in the repo with PR review, build/preview/deploy in CI, version docs to match the product, and gate quality with link-checking + example-testing. |
| `example-testing-setup` | `technical-writing-docs` | Setup guide for testing code examples in documentation CI — covers doctest, snippet extraction, execution sandboxing, and the failure-handling policy to ensure every published example actually runs. |
| `iac-module-design` | `terraform-iac` | Write composable Terraform/OpenTofu modules: single responsibility, typed variables with validation, documented outputs, for_each over count to avoid reorder churn, pinned provider requirements, and a working example. |
| `module-design-checklist` | `terraform-iac` | Pre-publish checklist and design guide for Terraform/OpenTofu modules — covers interface design, input validation, output documentation, for_each patterns, version pinning, and testability. |
| `policy-as-code-iac` | `terraform-iac` | Gate infrastructure with policy-as-code: evaluate the Terraform plan JSON with OPA/Conftest (or Sentinel) to reject misconfigurations — public exposure, wildcard IAM, missing tags, unencrypted resources — before apply, preventively. |
| `state-surgery` | `terraform-iac` | Safe procedure for Terraform state manipulation — covers import, mv, rm, and state-split operations with pre/post verification steps and the rollback strategy for each operation. |
| `terraform-state-safety` | `terraform-iac` | Design safe remote Terraform/OpenTofu state: remote backend with locking, encryption, and versioning; isolate state by blast radius; keep secrets out (and treat the whole file as sensitive); and do state surgery only with a snapshot. |
| `commitment-and-curative` | `title-escrow-settlement` | Build the title commitment and clear it: separate Schedule B-I requirements from Schedule B-II exceptions, and decide each defect as cure vs insure-over vs except. Clear the requirements before you close; insure-over only with underwriter approval. Underwriter/jurisdiction specifics are verify-at-use. |
| `escrow-closing-and-disbursement` | `title-escrow-settlement` | Run the escrow endgame: confirm the commitment requirements are cleared, balance the settlement statement to the lender CD, collect good funds, close/sign, then disburse -> record -> fund in the order the jurisdiction requires. Never disburse against uncollected funds; every good-funds/recording specific is verify-at-use. |
| `title-search-and-examination` | `title-escrow-settlement` | Run the title search and examination: define the search period, trace the chain of title to a reliable root, confirm the current vesting, and inventory every lien, encumbrance, easement, and prior exception. Chain of title is examined, not assumed; every underwriter/jurisdiction specific is verify-at-use. |
| `wire-fraud-and-trust-account-controls` | `title-escrow-settlement` | Protect the money: verify every wire by out-of-band callback before sending, require dual authorization, reject email-changed instructions, and safeguard the escrow trust account with three-way reconciliation, no commingling, and daily oversight. Business-email-compromise sensitive; each control specific is verify-at-use. |
| `group-vs-fit-trip-operations` | `travel-agency-tour-operations` | Decide and run group vs FIT trips: FIT (individual custom) flexibility vs group-block economics (room block, deposit, cutoff date, attrition, tour-conductor benefit). Build the block before you sell against it, and manage the deposit/cutoff/attrition liabilities. Contract terms are verify-at-use per supplier. |
| `itinerary-design-and-quoting` | `travel-agency-tour-operations` | Turn a travel brief into a structured, bookable, transparently-quoted itinerary: structure before price, itemize net/commissionable cost + service fee + taxes + insurance, attach the per-supplier cancellation/penalty schedule (verify-at-use), and document every element. No traveler PII in the artifact. |
| `service-recovery-and-disruption` | `travel-agency-tour-operations` | Run travel disruption and service recovery: triage the failure, rebook the traveler fast, escalate to supplier/insurance, decide goodwill deliberately, and document every change. A well-run recovery protects the traveler and earns the repeat booking. Supplier remedies and insurance terms are verify-at-use. |
| `supplier-and-commission-management` | `travel-agency-tour-operations` | Make earned margin real: maintain a booked-vs-paid commission ledger by supplier, chase gaps on a cadence, handle net vs commissionable pricing correctly, understand BSP/ARC air settlement, and steer the mix to preferred-supplier/consortia programs. Commission terms are verify-at-use per supplier agreement. |
| `build-cash-forecast-and-liquidity-plan` | `treasury-management` | Build a cash position + rolling forecast and a liquidity plan by traversing the treasury decision tree (cash position → forecast method (direct/receipts-and-disbursements vs indirect) → 13-week build & drivers → variance loop → minimum-cash/buffer sizing → committed vs uncommitted facility mix), then return the daily cash position, the 13-week forecast, the buffer target (stress-tested), the facility/revolver plan, and the conditions that resize it. Reach for this when the user asks 'build our 13-week cash forecast', 'how much cash should we hold?', 'what's our liquidity buffer?', 'direct or indirect forecast?', or 'committed vs uncommitted facilities?'. Used by cash-and-risk-operations-specialist (primary) and treasury-strategy-lead. |
| `design-fx-and-interest-rate-hedge` | `treasury-management` | Design an FX or interest-rate hedge by traversing the treasury decision tree (scope the exposure: transaction vs translation vs economic → decide hedge-vs-accept → set hedge ratio & horizon → choose the instrument: forward/swap/option/collar → set the hedge-accounting stance: ASC 815 / IFRS 9, cash-flow vs fair-value), then return whether to hedge, how much and how long, the instrument, the accounting designation with documentation/effectiveness, and the conditions that flip it. Reach for this when the user asks 'should we hedge this FX/rate exposure?', 'forward or option or collar?', 'what hedge ratio?', 'cash-flow or fair-value hedge?', or 'do we need hedge accounting?'. 'Do nothing' is a valid output. Used by treasury-strategy-lead (policy) and cash-and-risk-operations-specialist (execution). |
| `optimize-working-capital-and-payments` | `treasury-management` | Optimize working capital and harden the payments flow by traversing the treasury decision tree (cash-conversion cycle: DSO/DIO/DPO levers → DPO extension vs supply-chain finance / dynamic discounting → DSO reduction → inventory financing → payment-method choice → payment fraud controls: positive pay, dual auth, SoD, BEC), then return the working-capital levers ranked by cash freed, the payment-method recommendation, and the fraud-control setup. Reach for this when the user asks 'how do we free up working capital?', 'should we extend DPO or offer supply-chain finance?', 'how do we reduce DSO?', 'which payment method?', or 'set up positive pay / dual authorization / BEC controls'. Used by cash-and-risk-operations-specialist (primary) and treasury-strategy-lead. |
| `build-abuse-detection-pipeline` | `trust-and-safety` | Design an abuse/fraud/spam detection pipeline — inventory signals, decide rules vs. ML (or hybrid), wire signal → score → threshold → action/reviewer-queue, and set the operating point from a precision/recall tradeoff. Reach for this when the user asks to catch an abuse type, choose signals, or route to a reviewer queue. Used by abuse-detection-engineer (primary). |
| `design-moderation-policy` | `trust-and-safety` | Design a content-moderation policy from scratch — a policy taxonomy (categories + severity tiers), a proportional enforcement ladder (warn / limit / remove / ban), and a real appeal path — by traversing the enforcement decision tree. Reach for this when the user asks to design or review a moderation policy, or to map a violation to an action. Used by trust-safety-policy-lead (primary). |
| `measure-enforcement-quality` | `trust-and-safety` | Build the Trust & Safety measurement frame — prevalence (not just volume), enforcement precision/recall, time-to-action SLA, and appeal-overturn rate — with the formulas and the applied-statistics seam for eval validity. Reach for this when the user asks what to measure, whether moderation is working, or how to read a high overturn rate. Used by trust-safety-policy-lead + abuse-detection-engineer. |
| `plan-the-research-study` | `ux-research` | Frame a fuzzy research ask into a researchable question, run the research-theater gate (is this a real question or a decision already made?), select the method (generative/evaluative, qual/quant, attitudinal/behavioral, moderated/unmoderated) from the question rather than the reverse, size the sample to the claim it must bear (directional ~5 vs statistically-powered), plan the recruit/screener/incentive/panel, set the informed-consent + data-minimization + de-identification + retention ethics plan, and tie every finding to the decision it informs. Reach for this when the ask is 'how should we study X?', 'run a study that confirms Y', 'how many participants and from where?', or 'what do we need for consent/PII?'. Used by `ux-research-lead` (primary). |
| `run-usability-and-interview-sessions` | `ux-research` | Design and run the study without contaminating it — protocol & task design (goal-based tasks, not step instructions), think-aloud and non-leading moderation (open probes, silence, 'tell me more' — never 'was that easy?'), usability-test instrumentation (task-success criteria + severity ratings), survey design that avoids leading, double-barreled, and social-desirability-loaded items, and clean data capture that keeps what participants DID separate from what they SAID. Reach for this when the ask is 'write the protocol/tasks', 'moderate this interview without leading', or 'design/fix this survey'. Used by `research-execution-and-synthesis-specialist` (primary). |
| `synthesize-research-into-insight` | `ux-research` | Turn raw notes into evidence-weighted, bias-checked, prioritized, decision-ready insight — affinity/thematic analysis, keeping observation ('6 of 8 abandoned at step 3') strictly separate from interpretation ('because the CTA is unclear'), weighting each finding by evidence strength (n, consistency, behavioral vs attitudinal, directional vs conclusive), ranking by severity, actively seeking disconfirming evidence, and ending every insight in a prioritized recommendation tied to a decision. Guards against confirmation, recency, and availability bias. Reach for this when the ask is 'turn these notes/sessions into findings we can act on' or 'what did we actually learn?'. Used by `research-execution-and-synthesis-specialist` (primary), consulted by `ux-research-lead`. |
| `design-care-protocol` | `veterinary-practice` | Build an evidence-aligned, standardized care protocol as decision-support for the licensed DVM, to reduce unwarranted variation. Reach for this on a common presentation worked up inconsistently. |
| `instrument-production-and-act` | `veterinary-practice` | Read practice revenue as production per DVM and average client transaction × visits, never one alone, so a revenue problem is diagnosed correctly. Reach for this on any revenue question. |
| `lift-care-compliance` | `veterinary-practice` | Read recommended-care acceptance as a communication metric and raise it, instead of treating it as fixed demand. Reach for this when acceptance of dentals/diagnostics/preventives is low. |
| `reprice-the-fee-schedule` | `veterinary-practice` | Reprice fees from the cost-of-service stack and medical value, not the neighbor's prices, to recover margin without losing position. Reach for this when margin erodes despite volume. |
| `unlock-schedule-capacity` | `veterinary-practice` | Find the doctor bottleneck and fix the appointment template so a fully-booked practice can grow throughput. Reach for this when revenue is flat despite full demand. |
| `improve-diversion-and-recycling-economics` | `waste-recycling-operations` | Measure the real diversion rate from weigh tickets, diagnose the MRF & recycling commodity economics by grade (OCC/cardboard, PET, HDPE, aluminum, mixed paper — post-National-Sword bale prices), attack the contamination rate that decides the P&L, and set the pricing response (commodity-share vs processing/tip-fee) against the mandates in force (SB 1383 organics, EPR packaging, landfill bans). Reach for this when the user asks "what's our real diversion rate?", "our MRF revenue is underwater", or "contamination is killing single-stream". Used by `route-and-diversion-specialist` (primary). |
| `manage-disposal-and-regulatory-compliance` | `waste-recycling-operations` | Choose the disposal path (direct-haul to a Subtitle D landfill vs consolidate through a transfer station) and manage its economics (tipping fees, landfill airspace, leachate/gas) and its RCRA Subtitle D compliance, scale/weigh-ticket controls, and DOT/CDL + hopper/backing/lifting safety program — while routing hazardous Subtitle C streams OUT of scope. Reach for this when the user asks "landfill direct or through a transfer station?", "manage tipping fees / airspace", "stay Subtitle-D compliant", or "cut our injury rate". Used by `waste-operations-lead` (primary). |
| `optimize-collection-routes-and-fleet` | `waste-recycling-operations` | Raise route density and cut cost-per-stop for a collection territory by measuring stops-per-hour and windshield time, sequencing and balancing routes, choosing static vs dynamic routing (RouteWare / Routeware-AMCS / Trux), and matching the fleet mix (front / rear / side-load ASL / roll-off, RNG/EV) to each stream. Reach for this when the user asks "how do we get more stops per hour?", "static or dynamic routing?", "cut windshield time", or "what truck for this stream?". Used by `route-and-diversion-specialist` (primary, route half) and `waste-operations-lead` (fleet half). |
| `decompose-aum-growth` | `wealth-management-ria` | Separate AUM growth into net new flows vs market and compute the organic growth rate. Reach for this on a growth question. |
| `model-fee-revenue` | `wealth-management-ria` | Model tiered-fee revenue and the blended fee, flagging inconsistent application. Reach for this on a fee or revenue question. |
| `segment-client-profitability` | `wealth-management-ria` | Segment clients by revenue net of cost-to-serve and find breakeven AUM — not AUM alone. Reach for this on a client-value question. |
| `size-advisor-capacity` | `wealth-management-ria` | Size advisor capacity in households per advisor and treat over-capacity as a leading retention risk. Reach for this on a capacity question. |
| `track-compliance-cadence` | `wealth-management-ria` | Track the ADV/review/disclosure cadence as an operational schedule — not legal advice. Reach for this on a cadence question. |
| `commerce-gold-standard-rubric` | `web-commerce` | Score a scaffolded commerce integration against the seven-dimension gold-standard rubric and run the BUILD-measure-fix iteration loop until it passes. Use after scaffolding a provider track, before calling it done. Each dimension is a falsifiable test; a live provider-sandbox test is required beyond the static checks. |
| `payment-lifecycle-contract` | `web-commerce` | Understand and extend the thin shared contract every provider track implements — the payment-lifecycle interface plus advertised capabilities. Use when adding a provider, wiring a track to the contract, or deciding what belongs in the shared seam vs a track. The ONLY cross-provider abstraction; catalog/cart/inventory are track-specific. |
| `pos-reconciliation-loop` | `web-commerce` | Reconcile online inventory/catalog with an in-store POS (Square), keeping the POS as the source of truth. Use when a storefront's online store must mirror in-store stock. One-way sync driven by catalog/inventory webhooks, de-duped by event id — never bidirectional. Square-specific; Shopify inverts and Stripe has no catalog. |
| `provider-track-selection` | `web-commerce` | Choose the commerce provider (Stripe / Square / Shopify) and the tier (static hosted-checkout vs framework embedded-SDK) for a site, then point at the right template set. Use at the START of any commerce integration, before scaffolding. Routes on how the merchant's inventory truth already lives and the site's runtime. |
| `webhook-hardening` | `web-commerce` | Harden a commerce webhook handler: verify the provider signature with a constant-time compare BEFORE parsing the body, then de-duplicate retried deliveries by provider event id. Use when writing or reviewing any Stripe/Square/Shopify webhook receiver. Two invariants (verify-before-parse, event-id idempotency) that are non-negotiable. |
| `accessibility-review` | `web-design` | WCAG 2.2-aligned accessibility audit — semantics, ARIA, keyboard navigation, color contrast, focus management, motion preferences. Severity guide + tooling notes. Used by `accessibility-auditor` (primary). |
| `brand-guidance-authoring` | `web-design` | Author a project's generation-time brand-voice contract (brand-guidance.md) — a named aesthetic, a two-typeface max, a tiny palette, a 4px spacing scale, a motion philosophy, and a project-scoped anti-pattern catalogue that bans the recurring "AI slop" patterns (generic-sans brand faces, indigo gradients, 3-card grids, card-in-card, stock-photo 100vh heroes) by default. Loaded into context before every page-generation call — the tokens answer "what are the values," this answers "how does an agent reliably apply them." Reach for this skill when a project's design-tokens.json exists (or is being produced alongside) and no brand-voice contract exists yet. Used by `visual-designer` (primary); `frontend-implementer` and `content-strategist` co-consume it (voice rules straddle visual and copy). |
| `card-tile-ui` | `web-design` | Design and implement an Intercom-style card / "tile" UI — discrete soft-shadowed rounded surfaces on a calm monochromatic canvas, in a multi-pane (navigation-rail + content) layout, with a single restrained accent used only as hairlines, outlines, and occasional text. Used by `visual-designer` (primary) and `frontend-implementer` (token-to-code wiring). Invoke when a brief asks for a "card", "tile", "panel", "Intercom-style", "dashboard-like", or "clean SaaS" surface, or when restyling an existing flat/monochromatic page toward elevated content tiles. |
| `content-audit` | `web-design` | Audit existing site content — full inventory (URL × type × intent × last-updated × owner), scoring against business / user-need / SEO criteria, remediation queue (keep / consolidate / rewrite / retire), and the migration plan when re-platforming. Reach for this skill at the start of a re-platform, before an SEO push, or when content quality has stopped predicting conversion. Used by `content-strategist` (primary) + `web-architect`. |
| `conversion-design` | `web-design` | Design and audit conversion-focused screens — funnel definition, friction-vs-trust balance, form field selection (every field is a cost), one CTA per screen discipline, social-proof placement, microcopy patterns, and the conversion-rate measurement plan. Reach for this skill when designing or reviewing a landing page, sign-up flow, checkout, or any "convert visitor → action" screen. Used by `ux-designer` (primary) + `content-strategist`. |
| `core-web-vitals-tuning` | `web-design` | Diagnose and improve Core Web Vitals (LCP / CLS / INP). Includes a Mermaid decision tree for root-cause triage across all three vitals + canonical fix-by-symptom map. Field data (CrUX / RUM) at p75 is the measurement target. Used by `performance-engineer` (primary). |
| `design-system-audit` | `web-design` | Audit an existing brand / design system for consistency, completeness, token coverage, dark-mode readiness. Used by `visual-designer` (primary) + `frontend-implementer` (token-to-code wiring). |
| `design-tokens-scaffolding` | `web-design` | Scaffold a token system from brand spec to token JSON to CSS variables to framework theme (Tailwind / Shadcn / CSS-in-JS / Theme UI). Includes naming convention, scale design (color / spacing / typography / radius / shadow / motion), light/dark mode, semantic vs primitive tokens, and the dual-mode build pipeline. Reach for this skill when launching a new design system or when an existing system has "design drift" between Figma and code. Used by `visual-designer` (primary) + `frontend-implementer`. |
| `fluent-react-implementation` | `web-design` | Implement a Fluent UI v9 + React website end-to-end — set up FluentProvider, turn a brand color into a BrandVariants ramp and light/dark/high-contrast themes (createLightTheme / createDarkTheme), wire design tokens, style with Griffel makeStyles, handle Next.js App Router SSR (the use-client + renderToStyleElements boundary) or Astro islands, build custom components on Fluent primitives, and ship a themed Storybook. Reach for this skill when building or reviewing a Fluent/React site, implementing a brand as a Fluent design language, or debugging Fluent SSR / dark-mode / theming issues. Used by `frontend-implementer` (primary) + `visual-designer` (brand to theme). |
| `gold-standard-website-pipeline` | `web-design` | The gated pipeline the web-design Team Lead runs on a new marketing site or storefront — and, for a pure web-app, as a thinner brand/UX/a11y/perf wrapper around frontend-engineering's build, not the app's build pipeline: nine fail-closed gates (discovery → IA → tokens → content → build → a11y → perf → SEO/AEO → pre-launch), each against numeric WCAG 2.2 / CWV / SEO bars, seaming app builds to frontend-engineering and auth/payments to security-reviewer, ending in one Go / Conditional / No-go. |
| `information-architecture` | `web-design` | Design site information architecture — sitemap, URL taxonomy, navigation patterns (primary / utility / footer / contextual), card-sort discipline, content model that the IA implies, and the URL-to-template mapping. Reach for this skill at the start of a new build or when redesigning navigation on an existing site. Used by `web-architect` (primary) + `ux-designer`. |
| `seo-technical-audit` | `web-design` | Technical SEO sweep — crawlability, indexability, schema markup, sitemaps, OG / Twitter Card metadata, hreflang, structured data. Used by `web-architect` (primary, technical) + `content-strategist` (content-SEO). |
| `static-site-implementation` | `web-design` | Build a non-React static site: semantic HTML, token-driven CSS (custom properties, grid/flex, container queries, logical properties), and an SSG-first Astro/11ty/Hugo or plain HTML+CSS build with islands only where earned. Covers reflow to 320px, in-markup performance (AVIF/WebP srcset, lazy-load, font-display, critical CSS), and accessible markup. Used by frontend-implementer; dispatched by gold-standard-website-pipeline G5 for non-React static stacks. |
| `third-party-script-hygiene` | `web-design` | Catalogue and hygiene-audit third-party scripts on a marketing site — performance budget by category (analytics / chat / A/B / fonts / video / social), async-defer patterns, consent-gating (GDPR / CCPA / consent-mode v2), CSP implications, and the periodic re-audit cadence. Every third-party is debt; this skill quantifies it. Reach for this skill before launch, during a Core Web Vitals push, or when adding a new external script. Used by `performance-engineer` (primary) + `web-architect`. |
| `crawl-scheduling-and-pipeline` | `web-scraping-data-extraction` | Design the crawl schedule, change-detection, and the extraction-to-storage pipeline — a re-crawl cadence matched to data volatility, incremental crawls via conditional GET / ETag / sitemap lastmod, a polite rate-limit/backoff budget, and storage with provenance (source URL + fetch timestamp) and dedup. Traverses the schedule/pipeline branch of the web-scraping decision tree. Reach for this when the user asks 'how often should we re-crawl?', 'how do we detect changes?', 'set up the extraction pipeline', or 'add rate-limiting so we don't get blocked'. Used by scraper-implementation-engineer (primary) and extraction-architect. |
| `legal-ethical-and-fetch-strategy` | `web-scraping-data-extraction` | Run the legality/ethics gate BEFORE any code (robots.txt, ToS, public-vs-authenticated, rate, PII/copyright), prefer an API/feed/export over scraping, then choose the fetch strategy (HTTP + parser vs headless, JSON-endpoint-first). Traverses the top of the web-scraping decision tree. Reach for this when the user asks 'is it OK to scrape this?', 'should we scrape or is there an API?', 'do we need a headless browser?', or 'how do we do this without getting blocked/sued?'. Legality-first; never evasion for abuse. Used by extraction-architect (primary) and scraper-implementation-engineer. |
| `resilient-extraction-and-parsing` | `web-scraping-data-extraction` | Extract web data defensively — prefer structured data (JSON-LD / microdata / __NEXT_DATA__ / JSON API) over brittle CSS/XPath selectors, anchor selectors on stable attributes with fallbacks, and validate every record to a schema so breakage is DETECTED not silently wrong. Traverses the parse branch of the web-scraping decision tree. Reach for this when the user asks 'build a robust extractor', 'this scraper keeps breaking', 'how do I parse this reliably?', or 'why is my scraped data wrong?'. Used by scraper-implementation-engineer (primary) and extraction-architect. |
| `build-blocks-and-themes` | `wordpress-cms-engineering` | Build Gutenberg blocks (block.json, the edit/save split, dynamic render_callback, attributes, supports) and themes (classic templates or block/FSE with theme.json), enqueuing assets with versioned handles the supported way. |
| `choose-wordpress-architecture` | `wordpress-cms-engineering` | Decide how to build a WordPress site: classic vs block/FSE theme, plugin vs theme vs must-use plugin for custom code, headless/decoupled vs traditional, and single vs multisite — matched to the editing model, not fashion. |
| `extend-with-hooks-and-plugins` | `wordpress-cms-engineering` | Extend WordPress through actions and filters at the right hook and priority, register custom post types/taxonomies and REST routes, and query with WP_Query (or a $wpdb->prepare'd query) — keeping logic in a plugin, never editing core. |
| `harden-and-secure-wordpress` | `wordpress-cms-engineering` | Secure WordPress: sanitize-in/escape-out, $wpdb->prepare for all dynamic SQL, nonce + capability checks on every action, least-privilege roles, disable file editing, force HTTPS, secure wp-config, and keep core/plugins/themes current. |
| `performance-and-caching` | `wordpress-cms-engineering` | Make WordPress fast with layered caching: a full-page cache for anonymous traffic, a persistent object cache (Redis/Memcached behind wp_cache_*/transients) for dynamic work, expensive queries cached, plus profiling to find the real bottleneck before adding layers. |