adobe

Single entry point for all AEM as a Cloud Service Workflow skills. Covers workflow model design, custom process step and participant chooser development, launcher configuration, workflow triggering, and production support including debugging stuck/failed workflows, triaging incidents with Cloud Manager logs, thread pool analysis, and Sling Job diagnostics for the Granite Workflow Engine.

Debug AEM Workflow issues on AEM as a Cloud Service — stuck workflows, failed steps, missing Inbox tasks, launcher failures, stale instances, thread pool exhaustion, queue backlogs, purge failures, and permissions errors. Use when the user reports workflow problems on Cloud Service, asks why a workflow is stuck or failed, needs step-by-step troubleshooting, or provides thread dumps, configuration status output, or Sling Job console output for analysis.

Triage AEM Workflow issues on AEM as a Cloud Service by classifying symptoms, gathering the right logs and metrics, and mapping to runbooks or Splunk searches. Use when the user asks for workflow activity/errors on a Cloud Service host, needs to classify a Jira ticket, or wants to know what to collect for workflow debugging.

Convert per-page styled HTML prototypes (stardust under stardust/prototypes/**, or claude-design / Mobirise / Relume / Lovable / v0 / Figma-derived pages, or JSX prototypes pre-rendered to HTML, often under samples/) into Edge Delivery Services (EDS / AEM) blocks and content pages, then deploy via DA. Each prototype section becomes one EDS block; the prototype's per-section CSS becomes that block's CSS scoped under the block class. Use when the user wants to lift styled per-page HTML prototypes into a working EDS site under blocks/ and content/.

Reconcile a converted/built web page against its source prototype with two complementary probes — a PIXEL/layout diff (stretched images, dropped wraps, blank renders, colour flips) and a STRUCTURAL content+typography diff (dropped/mis-slotted headings, eyebrows, CTAs; rendered-face font forks). Stack-agnostic via profiles (eds | generic). Use after converting a prototype to EDS/AEM (the stardust:deploy Step 10), or for any prototype↔build fidelity check; invocable as stardust:diff and from workflows.

Crawl an existing website (capped, multi-page) and seed stardust/current/ with PRODUCT.md, DESIGN.md, DESIGN.json, a per-page inventory, and the consolidated brand surface — the captured design system, palette, typography, motifs, and voice of the live site. Use when the user wants to analyze an existing site's design, extract or reverse-engineer its design system or brand, capture design tokens from a live site, import a website as the starting point for a redesign, capture the current state before a migration, or invokes /stardust:extract. Trigger phrases include "analyze this site", "extract the design tokens", "capture the brand", "crawl the site", "reverse engineer the design". Not for scraping page data or content for its own sake (it captures design evidence, not datasets), and not for the redesign itself — extraction is descriptive; direction and prototyping happen downstream.

Render a proposed redesign of a page on the current website as a self-contained static HTML file, then iterate via the impeccable craft loop. Per-page, idempotent, stale-aware. Use when the user asks for a redesign prototype, a before/after comparison, a design preview, a page mockup, a visual diff of the redesign, or invokes /stardust:prototype.

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 diff + visual diff + stitched pixel diff per breakpoint), then hands off to migrate/deploy/rollout for site-wide delivery with reusable blocks. 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", "rebuild the site exactly as it is but clean", or "keep the design, change the platform". NOT for redesigns — a new or refreshed design is the stardust core pipeline (direct/prototype) or uplift.

Phase 3 of 1st-gen to 2nd-gen component migration. Use to move properties, methods, and types from 1st-gen to 2nd-gen while maintaining a clear public API.

Create accessibility migration analysis docs for 2nd-gen component migration. Use when on the "analyze accessibility" step for one or more components.

Phase 5 of 1st-gen to 2nd-gen component migration. Use to migrate CSS to the 2nd-gen structure, apply Spectrum 2 tokens, and ensure stylelint passes.

Phase 6 of 1st-gen to 2nd-gen component migration. Use to write unit tests, accessibility tests, and Storybook play functions for a migrated component.

Upgrade Spectrum 1 (sp-* elements, @spectrum-web-components/*) to Spectrum 2 (swc-* elements, @adobe/spectrum-wc). Use when developers need to migrate from Spectrum 1 to Spectrum 2 web components, or when they mention @spectrum-web-components, sp-* elements, or Spectrum 1.

Build UIs with Spectrum Web Components (SWC), Adobe's Spectrum 1 web component library. Use when developers are working with @spectrum-web-components/* packages or sp-* custom elements. Includes component API references, usage examples, accessibility guidance, and integration guides.

Phase 1 of 1st-gen to 2nd-gen component migration. Use to understand the component, plan breaking changes, and define scope before any refactoring begins.

When writing documentation in a variety of scenarios, follow the Adobe content writing standards.

Review code for AEM Edge Delivery Services projects. Use at the end of development (before PR) for self-review, or to review pull requests. Validates code quality, performance, accessibility, and adherence to EDS best practices.

Scrape webpage content, extract metadata, download images, and prepare for import/migration to AEM Edge Delivery Services. Returns analysis JSON with paths, metadata, cleaned HTML, and local images.

Analyze content sequences and determine authoring approach (default content vs blocks). Validates block selection and section styling for import/migration to AEM Edge Delivery Services.

Survey available blocks from local AEM Edge Delivery Services project and Block Collection to understand the block palette available for authoring. Returns block inventory with purposes to inform content modeling decisions.

Searches the aem.live documentation for information on AEM Edge Delivery Services features. Use this skill when you need more information about a feature, want guidance on how to implement a feature, and using existing tools you have to search the web isn't turning up relevant results.

Generate structured HTML from authoring analysis for AEM Edge Delivery Services. Creates section structure, applies block tables, handles metadata, and manages images folder.

Identify section boundaries and content sequences within a scraped webpage for AEM Edge Delivery Services import. Performs two-level analysis (sections, then sequences per section) and surveys available blocks.

Analyze content sequences within a section and provide neutral descriptions for AEM Edge Delivery Services. Invoked per section during page import to identify breaking points between default content and blocks.

Single entry point for all AEM as a Cloud Service Workflow skills. Covers workflow model design, custom process step and participant chooser development, launcher configuration, workflow triggering, and production support including debugging stuck/failed workflows, triaging incidents with Cloud Manager logs, thread pool analysis, and Sling Job diagnostics for the Granite Workflow Engine.

Debug AEM Workflow issues on AEM as a Cloud Service including stuck workflows, failed steps, missing Inbox tasks, launcher failures, stale instances, thread pool exhaustion, queue backlogs, purge failures, and permissions errors. Use when the user reports workflow problems on Cloud Service, asks why a workflow is stuck or failed, needs step-by-step troubleshooting, or provides thread dumps, configuration output, or Sling Job console output for analysis.

Implement custom AEM Workflow Java components on AEM as a Cloud Service. Use when writing WorkflowProcess steps, ParticipantStepChooser implementations, registering services via OSGi DS R6 annotations, reading step arguments from MetaDataMap, accessing JCR payload via WorkflowSession adapter, reading and writing workflow metadata and variables, and handling errors with WorkflowException for retry behavior.

Design and create AEM Workflow models on AEM as a Cloud Service. Use when creating workflow models via the Workflow Model Editor or content package XML, defining step types (PROCESS, PARTICIPANT, DYNAMIC_PARTICIPANT, OR_SPLIT, AND_SPLIT), configuring step properties, declaring workflow variables, and deploying models through the Cloud Manager pipeline.

Triage AEM Workflow issues on AEM as a Cloud Service by classifying symptoms, gathering the right logs and metrics, and mapping to runbooks or Splunk searches. Use when the user asks for workflow activity/errors on a Cloud Service host, needs to classify a Jira ticket, or wants to know what to collect for workflow debugging.

Start AEM Workflows on AEM as a Cloud Service using all available triggering mechanisms. Use when starting workflows manually via the Timeline UI, programmatically via WorkflowSession.startWorkflow(), via the HTTP Workflow API, through Manage Publication, or passing initial metadata and payload to a workflow instance.

AEM as a Cloud Service Java/OSGi best practices, guardrails, and legacy-to-cloud pattern transformations. Use for Cloud Service–correct bundles, deprecated APIs, schedulers, ResourceChangeListener, replication, Replicator, JCR observation (javax.jcr.observation.EventListener), OSGi Event Admin (org.osgi.service.event.EventHandler), DAM AssetManager, BPA-style fixes, HTL (Sightly) Cloud SDK lint warnings (data-sly-test redundant constant value comparison), or any time you need the detailed pattern reference modules under this skill.

Create, modify, review, and harden configuration for the Adobe Dispatcher Apache HTTP Server module and Apache HTTPD in AEM as a Cloud Service environments only. Use for `.any`, vhost, rewrite, cache, and filter changes.

Add or modify Adobe Commerce Admin UI extensions on the commerce/backend-ui/2 extension point: custom grid columns, mass actions, order view buttons, and a custom Admin menu entry. Use whenever the user wants to extend the Commerce Admin — add a column to the order, product, or customer grid, add a bulk/mass action to a grid, add a button to the order view page, or add a custom menu item or page — even when they don't name the extension point.

Manage custom business configuration in an Adobe Commerce app. Use when the user wants to add, modify, or remove merchant-configurable settings (config fields, admin config, store configuration) exposed through Commerce Admin. Creates typed config fields (text, password, email, url, tel, boolean, list) in businessConfig.schema. Requires a base app initialized with commerce-app-init.

Add or modify Commerce and external event subscriptions, configure event field extraction and filter rules in an Adobe Commerce app. Use when the user wants to set up event-driven workflows triggered by Commerce operations (such as order placement or catalog changes) or third-party systems. Requires a base app initialized with commerce-app-init.

Scaffold a new Adobe Commerce app using the aio-commerce-sdk. Creates the base project structure and app.commerce.config file with metadata. Use when the user wants to create a new Commerce app from scratch or initialize a bare Commerce app project. After scaffolding, chains to appbuilder-project-init for Developer Console setup (project, workspace, API subscriptions) when the user wants to deploy. Does not configure extensibility domains — use commerce-app-eventing, commerce-app-webhooks, commerce-app-business-config, commerce-app-admin-ui, or commerce-app-storage for that.

Add or modify webhook interceptors in an Adobe Commerce app. Use when the user wants to intercept Commerce operations to validate input, append data, or modify behavior — before or after execution. Requires a base app initialized with commerce-app-init.

Migrate an Adobe Commerce App Builder project from the Integration Starter Kit or Checkout Starter Kit to the new App Management approach. Run from the root of the App Builder project to be migrated. Pass --auto to skip confirmation prompts (suitable for CI or batch use) — auto mode prints a summary of all Q&A questions answered with their defaults. Pass --doc-scan-only to scan README.md and env.dist for outdated content without modifying any files. Use when the user wants to migrate an App Builder project from the Integration Starter Kit or Checkout Starter Kit to the App Management approach, or mentions upgrading their Adobe Commerce extension architecture.

Integrate App Builder Database Storage (@adobe/aio-lib-db) into an Adobe Commerce app and scaffold a runtime action that reads and writes documents. Use when the user wants persistent, queryable storage backing a Commerce app — either from a web action (HTTP-invokable) or from an event/webhook handler. Requires a base app initialized with commerce-app-init.

Write, update, and fix tests in S3Mock. Use when asked to add test coverage, create test cases, fix failing tests, or verify test correctness. Covers unit tests (*Test.kt in server/), controller slice tests (@WebMvcTest), and integration tests (*IT.kt in integration-tests/ against a live Docker container).

Generate and update S3Mock project documentation. Use when asked to document code, update CHANGELOG.md, update README.md, update AGENTS.md files, or fix formatting, wording, or style in any existing documentation file. Also invoked at the end of the implement skill workflow.

Fix code style issues and ensure linting CI gates pass in S3Mock. Use when ktlint or Checkstyle violations are reported, when asked to fix formatting, or as a required final step after any code change. Runs ktlint for Kotlin source files and Checkstyle for Java and XML files.

Implement features, fix bugs, and modify production source code in S3Mock. Use when asked to add functionality, change behavior, or modify source files in server/, integration-tests/, or testsupport/. Not for documentation-only or test-only changes. Orchestrates lint, test, and document skills as part of the complete workflow.

Improve code readability, enforce idiomatic Kotlin conventions, and enhance documentation quality in S3Mock without changing behavior. Use when asked to clean up code, improve naming, add KDoc, or align with Kotlin/project idioms. Also invoked by the implement and test skills before adding new code to messy areas.

Review code changes in pull requests or local diffs for S3Mock. Use when asked to review a PR, inspect changes, or provide structured feedback on correctness, conventions, test quality, and documentation. Outputs findings structured as Must fix / Should fix / Nit.

Reads a feature spec, locates the matching API spec, reads the project's backend service cards, and produces a Low Level Design (LLD) document describing all the backend implementation changes needed. Does not write code — outputs a structured engineering plan.

Reads an experience card, optionally fetches the Figma design if a URL is defined in the card, reads the project's UI service cards, and produces a Low Level Design (LLD) document describing all UI implementation changes an engineer needs to make. Does not write code — outputs a structured UI engineering plan.

Generate a complete UI Service Card set for any application by reading its codebase. Produces all 7 card files (UI_SERVICE_CARD, UI_MODULE_INDEX, ROUTES, DATA_LAYER, STATE_MANAGEMENT, UI_CODE_PATTERNS, UI_PLATFORM) filled with real project values. Works with any UI technology — JavaScript/TypeScript SPAs, Java JSP/Thymeleaf, C# Blazor/Razor, Python Django/Flask templates, Flutter, or others. Triggers on phrases like "generate service card", "create service card", "document this UI", or when a target app directory is provided with intent to generate cards.

Executes a pre-written LLD by reading the target repo's service cards for coding conventions, then writing all files specified in the LLD. Supports backend-only, UI-only, or full-stack generation via an optional mode argument. The LLD defines WHAT to build; the service cards define HOW to write it.

Audits a generated feature implementation against its LLD — checking every file in the Change Summary table, every bullet in every Change Required cell, wiring between frontend and backend, and experience card acceptance criteria. Read-only. Reports pass / partial / fail per file with specific gaps and fix guidance. Run after implement-feature or after manual edits.

Validate, query, resolve, diff, and author spec-conformant design tokens and components using the design-data MCP tools against a local dataset. Use when the user asks about design tokens, a design system, token lookup, spec-conformance, drift detection, or token authoring on custom data.

Look up Spectrum design tokens, component schemas, and design-system decisions when building with or extending Adobe Spectrum. Use when the user asks about token values, component options, naming conventions, or wants to validate/explore design-token data. Also triggers when a .design-data.toml config is involved or the user mentions the design-data CLI.

Look up Spectrum 2 (S2) component documentation, design guidelines, and usage patterns when building with React Spectrum or Spectrum Web Components. Use when the user mentions Spectrum, S2, React Spectrum, RSP, Spectrum Web Components, or SWC, or names a Spectrum component (Button, Picker, ComboBox, TextField, ActionButton, etc.). Helps prevent drift from documented S2 design decisions during prototyping.

Enhances auto-generated spectrum-design-data PRs from spectrum-tokens-studio-data sync (branch tokens-sync/patch-spectrum2-from-main, author mrcjhicks). Diagnoses CI failures, suggests fixes, creates changesets with token-changeset-generator, updates PR title/body, and attributes the original Tokens Studio implementer. Use when fixing sync PRs, PRs from tokens-sync, enhance-sync-pr workflow gaps, or missing changesets on studio syncs.

Query AEM Edge Delivery Services Real User Monitoring (RUM) data via the Operational Telemetry (OpTel) bundler API. Covers page views, web vitals, traffic breakdowns, and domain key management. Use when investigating site performance, checking page view trends, analyzing Core Web Vitals, or exploring RUM data for an EDS domain. Triggers on requests like "how many page views", "check web vitals", "RUM data for", "traffic for", "oversight status", "mint a domain key", or "what's the LCP on".

Interact with Adobe On-Call (ServiceNow-based pagerduty replacement) — list active on-call incidents, acknowledge, check who is on-call, view your upcoming shifts, and manage incident state. Use when the user mentions on-call, pagerduty, OCINC, incidents, shift schedule, acknowledge incident, escalation, or wants to check on-call status.

Use this when writing postmortems, incident reports, RCA, root cause analysis, post-incident review, or incident documentation for AEM Edge Delivery Services. Covers the aem-status repo workflow: creating postmortem files, frontmatter spec, impact classification, timeline formatting, PR submission, and monday stand-up summaries. Triggers on: postmortem, incident report, RCA, root cause analysis, post-incident review, aem-status, incident documentation, AEM incident.

Use this when investigating CDN incidents, checking error rates, or drilling into AEM Edge Delivery Services logs via ClickHouse. Covers error breakdowns, time series, log inspection, and automated incident investigation. Triggers on requests like "check CDN errors", "what's failing", "investigate 5xx", "error rate", "klickhaus status", or when on-call and needing to understand traffic anomalies.

Sample skill that greets bar. Placeholder demonstrating the @adobe/data-ai skill-bundle wiring; replace with a real architecture skill.

Sample skill that greets foo. Placeholder demonstrating the @adobe/data-ai skill-bundle wiring; replace with a real architecture skill.

Reflective Thought Composition. Structured thinking pipeline for complex decisions, design evaluation, and deep analysis. Use when quality of reasoning matters more than speed of response.

Use when optimizing a hot path in @adobe/data — especially when an interface (Column, TypedBuffer, ManagedArray, etc.) has many concrete instances created from closure-returning factories and is dispatched from a tight per-row loop. Provides the closure→class refactor pattern, the V8 hidden-class reasoning behind it, accept/reject criteria, and the discipline that keeps the public API closure-free even when implementations are class-based.

Stylesheet organization, design token usage, light/dark mode, and CSS conventions for Spectrum Hub. Use when adding global styles, creating block CSS, or structuring new stylesheet files.

Scaffold and implement a new EDS block for Spectrum Hub. Use when adding a new block — covers file structure, the init(el) function contract, template injection, CSS conventions, and when to use templates vs per-page authoring vs fragments.

Implement WCAG 2.2 compliant interfaces with mobile accessibility, inclusive design patterns, and assistive technology support. Use when auditing accessibility, implementing ARIA patterns, building for screen readers, or ensuring inclusive user experiences.

Create conventional commit messages following best conventions. Use when committing code changes, writing commit messages, or formatting git history. Follows conventional commits specification.

Interactive guide for adding telemetry instrumentation to an Adobe App Builder runtime action using @adobe/aio-lib-telemetry. Use when the user wants to: (1) decide what to instrument inside a runtime action, (2) add child spans with instrument() to trace internal functions, (3) add custom metrics with defineMetrics(), (4) add span attributes or events to enrich traces, (5) add structured logging correlated with traces, (6) choose between traces, metrics, and logs for an observability goal, (7) instrument outbound HTTP calls or cross-action propagation, or (8) get a guided assessment of what telemetry to add to a specific action. Prerequisite: general telemetry setup done (library installed, defineTelemetryConfig defined). Per-action steps like instrumentEntrypoint and ENABLE_TELEMETRY can be handled here. Triggers on: "instrument this action", "what should I trace", "add spans", "add metrics to my action", "what should I observe", "help me instrument", "add logging", "instrument my function".

Interactive setup guide for adding OpenTelemetry observability to Adobe App Builder runtime actions using @adobe/aio-lib-telemetry. Use when the user wants to: (1) add telemetry/observability to an App Builder action, (2) instrument runtime actions with traces, metrics, or logs, (3) configure an observability backend (Grafana, New Relic, Datadog, etc.) for App Builder, (4) set up distributed tracing across actions, (5) add Commerce event/webhook integrations, or (6) understand how to setup @adobe/aio-lib-telemetry. Triggers on: "add telemetry", "instrument my action", "set up tracing", "configure observability", "export traces/metrics/logs", "OpenTelemetry for App Builder".

Interactive troubleshooting for @adobe/aio-lib-telemetry issues in Adobe App Builder runtime actions. Use when a user reports: (1) telemetry not working, no data showing up, (2) missing traces, metrics, or logs, (3) broken distributed traces or disconnected spans, (4) errors from the telemetry library, (5) "works locally but not in production" issues, (6) backend-specific problems (New Relic, Grafana, etc.), (7) hot reload / dev mode telemetry issues, (8) configuration validation or review, or (9) any unexpected behavior related to @adobe/aio-lib-telemetry. Triggers on: "telemetry not working", "no traces", "missing spans", "export failed", "telemetry error", "debug telemetry", "traces not showing", "broken traces", "check my config", "validate configuration".