adobe

Reference for the Adobe AEM CLI (@adobe/aem-cli, formerly the helix-cli npm package; commands `aem up`, `aem import`, `aem content`) — installation, the local Edge Delivery dev server, .env / AEM_* configuration, HTTPS/TLS, proxy & certificate trust, content sync with da.live, and troubleshooting. Use when installing, running, or configuring the aem/hlx CLI, when `aem up` fails (port conflicts, cert errors, proxy 404s, pipeline vs. local-file confusion), or when migrating from the old helix-cli package. Do NOT use for da.live content-format rules or the DA Source API contract (use da-content); do NOT use for writing EDS block code (use content-driven-development).

Import a single webpage from any URL into canonical EDS block format — structured HTML that authors edit in DA. Scrapes the page, analyzes structure, maps to existing blocks, and generates HTML for immediate local preview. Also triggered by terms like "migrate", "migration", or "migrating". Use this when the goal is canonical EDS authoring; use the snowflake skill instead when the user wants to preserve the original DOM byte-for-byte (static-to-EDS overlay).

Apply a Content Driven Development process to AEM Edge Delivery Services development. Use for ALL code changes - new blocks, block modifications, CSS styling, bug fixes, core functionality (scripts.js, styles, etc.), or any JavaScript/CSS work that needs validation.

Static-to-EDS conversion that preserves the original design while making content authorable in Document Authoring. Two modes — page-level (overlay template with slot markers) and block-level (each section becomes an independent EDS block). Use when converting an AI-generated static HTML page (Stardust, Mobirise, Relume, Lovable, v0, Figma-derived hand-coded, etc.) into an Edge Delivery Services page. Triggers on "convert this page to EDS", "static-to-EDS overlay", "convert to EDS blocks", "next experimentation", "next run", "start run", or when a user provides a source URL and asks to make it editable in DA while keeping the original design intact. Do NOT use for canonical EDS block-rewrite migrations — that's the page-import skill.

Reference for producing Adobe Document Authoring (DA, da.live) and Edge Delivery Services (EDS, aka aem.live/Helix) compatible content. Use whenever generating HTML for DA upload, uploading media binaries to DA, publishing to aem.live, or driving the DA admin API (auth, source PUT, preview/publish). Covers block HTML format (canonical div-class form and accepted table alternate), section structure, page/section metadata, icons, links, images, default content, document skeleton constraints, block cell content normalization, the DA Source API contract, IMS auth, media storage, supported formats, Media Bus vs Content Bus delivery, and silent-failure rules that corrupt content.

Obtains a valid Adobe IMS access token for the DA (Document Authoring) API. Use this skill as a prerequisite step whenever another skill needs to call admin.da.live — for example, before pushing HTML content, listing documents, or triggering a DA preview. Do NOT use this skill if you already have a valid DA_TOKEN in scope from a previous step in the same session.

Single entry point for all AEM 6.5 LTS 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 JMX, Splunk, direct log access, thread pool analysis, and Sling Job diagnostics for the Granite Workflow Engine.

Debug AEM Workflow issues on AEM 6.5 LTS and AMS 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 AEM 6.5 LTS or AMS, asks why a workflow is stuck or failed, needs step-by-step troubleshooting, or provides thread dumps, configuration status dumps, or Sling Job console output for analysis.

Use when creating a per-component migration guide for application developers upgrading from Spectrum 1 Web Components to Spectrum 2 components.

Phase 7 of 1st-gen to 2nd-gen component migration. Use to write JSDoc, Storybook stories, and usage docs so the component is usable and understandable by others.

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 2 of 1st-gen to 2nd-gen component migration. Use to create the 2nd-gen file and folder structure, wire up exports, and confirm the build passes before implementation begins.

Sub-task after Phase 6 of 1st-gen to 2nd-gen component migration. Use to verify all migrated files conform to the project style guides, run linters, and surface any guideline gaps as PR comment notes.

Phase 4 of 1st-gen to 2nd-gen component migration. Use to implement WCAG-aligned semantics, ARIA, keyboard support, and focus management, and document accessibility behavior.

Phase 8 of 1st-gen to 2nd-gen component migration. Use to run final checks, verify lint/tests/build/Storybook, update the workstream status table, and open a PR.

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.

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.

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.

Import a single webpage from any URL to structured HTML content for authoring in AEM Edge Delivery Services. Scrapes the page, analyzes structure, maps to existing blocks, and generates HTML for immediate local preview. Also triggered by terms like "migrate", "migration", or "migrating".

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.

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.

Investigate and triage runtime incidents involving the Adobe Dispatcher Apache HTTP Server module and related HTTPD configuration in AEM as a Cloud Service environments only, using runtime-backed MCP evidence.

Optimize performance of the Adobe Dispatcher Apache HTTP Server module and related HTTPD configuration for AEMaaCS cloud workflows only, with cloud-specific baseline and runtime verification.

Perform security audits for the Adobe Dispatcher Apache HTTP Server module and Apache HTTPD in AEMaaCS cloud workflows only, with cloud-specific hardening verification.

Single entry point for all AEM as a Cloud Service Dispatcher skills. Covers config authoring, technical advisory, incident response, performance tuning, security hardening, and full lifecycle orchestration for the Adobe Dispatcher Apache HTTP Server module and its HTTPD/dispatcher configuration.

Provide advisory guidance for the Adobe Dispatcher Apache HTTP Server module and related HTTPD configuration in AEMaaCS cloud workflows only, with public-doc citations and cloud-specific MCP verification plans. Use for conceptual questions such as `statfileslevel`, filter rules, URL decomposition, cache invalidation behavior, rewrite behavior, and security headers.

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.

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.

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.

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.

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).

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, or commerce-app-business-config 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). 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.

Validate, query, resolve, diff, and author spec-conformant design tokens and components using the design-data CLI 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.

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.

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.

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".

Review code for AEM Edge Delivery Services projects. Use for self-review before committing, or to review pull requests with one-click GitHub suggestions.

Generate Adobe Firefly image prompts for AEM tools website (tools.aem.live) tool card thumbnails. Use when creating or updating thumbnail images for tools, or when a new tool needs a card image. Triggers on requests like "create an image for the X tool", "generate a tool thumbnail", "make a Firefly prompt for this tool".

Generate accessible color themes using @adobe/leonardo-contrast-colors. Use when the user needs help building contrast-based color palettes, checking WCAG accessibility, creating adaptive themes, or using the Leonardo API.

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.