Same-design migration — re-platform a site to AEM Edge Delivery (or any clean front end) keeping its current design near pixel-perfect. Recreates key pages (one archetype per page type) as clean re-authored HTML/CSS (never DOM copies), verifies each against the live site with a measured source-fidelity gate (structural + visual + stitched pixel diff per breakpoint), then hands off to migrate/deploy/rollout for site-wide delivery (subsumes prepare-migration's prep cascade — never chain the two). The only permitted design changes are entries in an explicit inconsistency register. Use when the user says "migrate this site keeping its current design", "same-design migration", "pixel-perfect replatform to AEM", or "keep the design, change the platform". NOT for redesigns — those are the stardust core pipeline (direct/prototype) or uplift.

Apply DESIGN, canon, and modules to every page in the inventory, producing a deployable static HTML site. Use to migrate or render the whole captured site into the redesigned static tree ("migrate the pages", "render the migrated site", "apply the design to all pages", "build the deployable site", "convert the approved prototype into the full site") — the page-rendering step between prototype and deploy/rollout. Three render branches (approved page, template-applied sibling, unique render), with a declared fidelity tier per page. Per-page, incremental, idempotent, content-preserving by default.

Work with @fullsnacklab/components and @fullsnacklab/design-system. Use when selecting, authoring, extending, composing, wrapping, integrating, or diagnosing Full Snack Lab component families and theme contracts.

Writes TypeScript services around parsed boundaries, owned dependencies, explicit outcomes, and tests. Use when implementing adapters, state or result handling, dependency orchestration, or async workflows.

Designs and tests model-callable Pi tools with TypeBox schemas, honest results, progress, and cancellation. Use when writing defineTool definitions, customTools for the Pi SDK, tool schemas, execute implementations, or direct tool tests.

Writes TypeScript services around parsed boundaries, owned dependencies, explicit outcomes, and tests. Use when implementing adapters, state or result handling, dependency orchestration, or async workflows.

Designs and tests model-callable Pi tools with TypeBox schemas, honest results, progress, and cancellation. Use when writing defineTool definitions, customTools for the Pi SDK, tool schemas, execute implementations, or direct tool tests.

Build, audit, improve, test, or prepare n8n community-node packages for npm and Creator Portal verification. Use for n8n node UX, credentials, node properties, community-package metadata, scanners, local node development, and verified-node releases; not for merely authoring or running an ordinary n8n workflow.

Prepare a whole site for migration by orchestrating the prep cascade — a full-inventory crawl (extract --prep), page-type and module-catalog confirmation (direct --prep), archetype prototypes plus design canon (prototype --prep), and asset preparation — with confirmation gates between phases. Builds the typed page inventory, confirmed module catalog, and canon that stardust:migrate consumes. Use when the user wants to prepare or set up a full-site migration, run migration prep, confirm page types and modules before migrating a site, get a large site ready to migrate, or invokes /stardust:prepare-migration. Trigger phrases include "prepare the migration", "migration prep", "set up the migration data", "get the site ready to migrate". Redesign-flow only — for same-design migrations stardust:replica runs its own preserve-mode prep cascade; never chain prepare-migration with replica. Not for running the migration itself (stardust:migrate) or converting a single page (stardust:deploy).

Creates, previews, serves, checks, exports, and collaboratively edits hand-built HTML slide decks, conference presentations, and speaker notes. Use when the user asks to "create slides", "make a presentation", "build a slide deck", use the "dwmkerr.com style", create a conference talk, preview or open a deck, "serve the slides", "make the slides editable", check a deck, or export slides to PDF. Produces dependency-free HTML with browser editing, conflict-safe live-save, comments, preflight checks, and selected-slide export.

OpenTelemetry Weaver registry authoring, codegen, and CI enforcement. Use when adopting Weaver, authoring or reviewing a registry (manifest, attributes, metrics, spans, events), writing Jinja2 templates against the resolved schema, migrating hand-maintained telemetry constants, or wiring `weaver registry check`/`generate`/`diff` into CI.

OpenTelemetry in Ruby — SDK setup, manual tracing, experimental metrics and logs, Bundler integration, contrib instrumentation for Rails/Rack/Sinatra/Sidekiq and other gems, propagation, performance, and upgrades. Use when adding, reviewing, configuring, or troubleshooting OpenTelemetry in a Ruby or Rails service. Triggers on "setup otel in ruby", "ruby telemetry", "Rails OpenTelemetry", "OpenTelemetry::SDK.configure", "opentelemetry-instrumentation-all", "Ruby tracing", "Rack otel", "Sidekiq otel", or any Ruby-related OTel question.

OpenTelemetry in Node.js / JavaScript / TypeScript — NodeSDK, declarative YAML configuration, auto-instrumentations, ESM vs CJS import patterns. Use when adding, reviewing, or configuring OpenTelemetry in a Node.js service. Triggers on "setup otel in node", "js telemetry", "node tracing setup", "NodeSDK", "auto instrumentation node", "TracerProvider node", or any Node.js-related OTel question.

OpenTelemetry declarative YAML configuration for SDK setup. Use when configuring OpenTelemetry SDK providers (tracer, meter, logger), setting up OTLP exporters, defining sampling strategies, or writing otel config files. Triggers on "otel config", "OpenTelemetry YAML", "declarative configuration", "otelconf", "OTEL_CONFIG_FILE", "file_format", "configure tracing/metrics/logs export", or when the user is setting up telemetry pipelines via config files rather than code.

Show the Worktrail front-door commands and accepted positional arguments. Use when the user asks how to invoke worktrail-go, wants the available handoff, spec, pr, repo, or route forms, invokes worktrail-go with help or with a bare noun, or asks how to answer a filed product decision (worktrail-decision).

Use only for a current operative request that explicitly invokes /roborev-fix, or a direct Agent Hook instruction; do not invoke from literal syntax in quoted, pasted, or historical text

Use when running TiDB package tests and deciding whether failpoint enable/disable is required before and after the test command.

GitLab Pajamas Design System expert for building UIs with Pajamas components and patterns. Use when: (1) implementing UI that should follow GitLab's Pajamas design system, (2) selecting or configuring Pajamas/GlComponent components (GlButton, GlAlert, GlModal, etc.), (3) translating Figma designs into Pajamas-compliant code, (4) questions about Pajamas component usage, variants, categories, or accessibility, (5) building GitLab-style interfaces, or (6) the user mentions "Pajamas", "GitLab UI", "Gl components", or "design system" in a GitLab context. Works hand-in-hand with the implement-design skill and Figma MCP tools.

Guide for creating and maintaining outbox-based eventually consistent operations in Sentry. Most commonly used for cross-silo data replication, but applicable anywhere eventual consistency is needed — including single-silo deferred side effects, audit logging, and event fanout. Use when asked to "add outbox", "add outbox replication", "replicate model to control silo", "replicate model to cell", "add outbox category", "write outbox signal receiver", "debug stuck outboxes", "outbox not processing", "data not replicating", "test outbox", "migrate model to use outboxes", "backfill outbox data", "outbox coalescing", "ReplicatedCellModel", "ReplicatedControlModel", "OutboxCategory", "OutboxScope", or "outbox_runner". Covers model mixins, category registration, signal receivers, testing, backfill, and debugging workflows.

Design Django ORM models for Sentry following architectural conventions for silos, replication, relocation, and foreign keys. Use when adding a new Django model, designing a model for a feature, deciding where data should live, picking a foreign key type, or refactoring an existing model's silo placement. Trigger on "add a Django model", "create a model", "design a model for X", "new database table", "store this data in the DB", "I need to track Y", "model for [feature]". Not for Pydantic models, dataclasses, ML models, or Protobuf — this is specifically for Django ORM models in the Sentry codebase.