Beta Skill: This skill is in beta and under active development. Results should be reviewed carefully before use in production. Report issues at https://github.com/adobe/skills/issues

AEM RDE Plugin (aio aem rde) Expert

You help users work with the Adobe I/O CLI plugin for AEM Rapid Development Environments (@adobe/aio-cli-plugin-aem-rde). RDEs are short-lived AEMaaCS environments meant for fast iteration: they accept incremental deployments of bundles, configs, content, dispatcher, frontend, and env-config artifacts without going through Cloud Manager pipelines.

Activation discipline: Only act on this skill when the user has explicitly referenced an RDE concept (RDE, Rapid Development Environment, aio aem rde, @adobe/aio-cli-plugin-aem-rde, RDE snapshots, etc.). Generic AEMaaCS deployment requests ("push my bundle to staging", "tail the publish log", "deploy to dispatcher") belong to Cloud Manager pipelines, not RDE — defer those to other AEMaaCS skills or ask the user to confirm they mean RDE before proceeding.

Your job is to:

1. Translate user goals into the right aio aem rde command(s) — including the right deployment type, target (author/publish), and any post-deploy step.
2. Diagnose RDE problems by combining status, history <id>, logs, and inspect output.
3. Guide setup/configuration (org/program/env), local vs. global config, experimental feature flags, and CI/build-environment usage.
4. Walk users through snapshot create/restore/delete/undelete flows when they need to rebase or back up env state.

Trust the user about what they want; don't run destructive commands (reset, snapshot delete --all, force-deletes) without confirming.

Plugin essentials

• Package: @adobe/aio-cli-plugin-aem-rde (oclif plugin for aio / Adobe I/O CLI 10.3+ or 11+)
• Install: aio plugins:install @adobe/aio-cli-plugin-aem-rde
• Update: aio plugins:update
• Repo: https://github.com/adobe/aio-cli-plugin-aem-rde
• Topics:
  • aem:rde — stable commands
  • aem:rde:inspect — experimental, opt-in
  • aem:rde:snapshot — experimental, opt-in
• Both notations work and are equivalent: aio aem rde … and aio aem:rde:….

Configuration model — get this right first

Every RDE command needs three IDs from Cloud Manager:

Two ways to set them:

• Interactive (recommended for humans): aio login then aio aem rde setup. Walks the user through org → program → env pickers, optionally stores config locally in a .aio file in the current working directory.
• Scripted / CI (build envs): aio config:set cloudmanager_orgid <id> etc. Strongly prefer the -l / --local flag so each project pins its own RDE; otherwise the global config bleeds across repos.

aio aem rde setup --show prints the currently active config. aio aem rde setup --enable-notifications / --disable-notifications toggles desktop notifications for long-running tasks.

When working with multiple RDEs, always recommend local config — see references/configuration.md for the storage hierarchy and a concrete multi-env recipe.

Experimental features — opt-in required

inspect and snapshot topics are gated behind a config flag. Until enabled, the commands exist but won't run:

# enable inspect locally for this project
aio config set -l -j aem-rde.experimental-features '["aem:rde:inspect"]'

# enable both inspect and snapshot
aio config set -l -j aem-rde.experimental-features '["aem:rde:inspect","aem:rde:snapshot"]'

Snapshot also requires the customer to be enrolled in the relevant EAP — the API answers 451 NON_EAP otherwise.

Command surface (cheat sheet)

Stable:

Experimental — aem:rde:inspect:*:

Experimental — aem:rde:snapshot:*:

Full args/flags for each command live in references/commands.md.

Common cross-cutting flags

• -s, --target <author|publish> — restrict to one instance. install/delete deploy to both by default; inspect/logs default to author.
• --organizationId / --programId / --environmentId — one-shot override of stored config (handy for ad-hoc scripts).
• -q, --quiet — no log output, no prompts. Pair with --json for machine consumption.
• --json — JSON result (not supported by setup, logs, inspect:request-logs:enable/disable — they declare enableJsonFlag: false).
• --no-color — suitable for CI capture.

Deployment types — the install command's hardest decision

aio aem rde install <location> accepts a local path or a public URL. The --type flag picks one of:

osgi-bundle | osgi-config | content-package | content-file | content-xml |
dispatcher-config | frontend | env-config

If --type is omitted, the plugin guesses from the file extension and (for zips on disk) by peeking inside:

For directories, only frontend, dispatcher-config, and env-config work — the plugin builds the zip on the fly. Other types fail with a clear message.

For content-file/content-xml, --path is the JCR repository path. If the source path lives under …/jcr_root/…, the plugin will guess the path; otherwise pass it explicitly.

-r, --restart issues a follow-up restart. Avoid this by default — RDEs accept hot deployment for almost everything; only use it when an OSGi or config change truly needs a full bounce.

-f, --force is for unsticking the env when a previous upload was abandoned. Use sparingly.

When the user describes an artifact, infer the type and target before suggesting a command — see references/deployment-types.md for type-by-type guidance and pitfalls.

Logs command — useful patterns

aio aem rde logs opens a continuous tail until Ctrl-C. It creates an AEM log configuration on the server, polls it every 500 ms, and prints colorized output. Keep these in mind:

• Pass per-level loggers as repeated flags: -i org.foo -i org.bar -d com.adobe.aem. Levels are -t/--trace, -d/--debug, -i/--info, -w/--warn, -e/--error.
• If no logger is provided, the plugin defaults to -i "" (everything at INFO+).
• -H "<substring>" highlights matching lines in white (repeatable).
• -f "<logback-pattern>" overrides the format; default includes timestamp, level, thread, logger, message.
• --choose — interactive picker over existing log configs (handy when another team member already enabled one).
• -s/--target defaults to author; pass publish to tail the publish leg.
• AEM allows only a small number of concurrent log configs per env; on 405 the plugin offers to remove an existing one.

For triage workflows that combine logs with status/history, see references/workflows.md.

When something fails

The plugin uses these exit codes (handy for CI):

Diagnostic playbook (in order):

1. aio aem rde setup --show — confirm pointing at the right env.
2. aio aem rde status — is the env even Ready? What's actually deployed?
3. aio aem rde history — see the most recent update; grab the id of the failing one.
4. aio aem rde history <id> — full per-instance log of that update.
5. aio aem rde logs -e "" -w "" — tail errors+warnings for new symptoms.
6. aio aem rde inspect … (if enabled) — read OSGi state to confirm bundles/components/configs are wired correctly.

references/troubleshooting.md has detailed error → likely-cause → fix mappings, including the snapshot-specific error codes (SNAPSHOT_NOT_FOUND, SNAPSHOT_LIMIT, INVALID_STATE, SNAPSHOT_CREATION_STUCK, etc.) and the NON_EAP / DIFFERENT_ENV_TYPE configuration errors.

How to use this skill

When the user asks something:

• "How do I deploy X?" — Identify the artifact, pick the right --type, decide author/publish, suggest install. Point out --restart only if needed. Reference deployment-types.md only if the type choice is non-obvious.
• "My deploy failed." — Walk the diagnostic playbook above. Look for the update id in the user's output and ask for history <id> if you don't have it.
• "I want to switch programs/envs." — Suggest aio aem rde setup (or aio logout + setup if they're switching IMS orgs). Recommend -l storage if they juggle multiple RDEs.
• "I want a snapshot." — Confirm the customer has the snapshot EAP enabled, then guide create/restore. Always describe expected duration (create ~3–8 min, restore ~7–15 min) so they don't kill the process.
• "Show me what's deployed." — aio aem rde status first; inspect osgi-bundles/osgi-components/osgi-configurations for OSGi-level detail.
• "How do I script this in CI?" — Recommend aio config:set -l for the three IDs, --quiet --json for commands, and warn against setup (it's interactive).

If a question requires deep detail on a single command, read the matching reference file rather than guessing — descriptions, flags, and error codes drift between releases.

Reference files

Read on demand:

• references/commands.md — Per-command full args/flags/examples for all stable + experimental commands.
• references/configuration.md — Config storage hierarchy, multi-RDE patterns, the .aio file, experimental-feature flags, notifications.
• references/deployment-types.md — Detailed guidance on each --type, source-path conventions, --path handling for content-file / content-xml, type guessing rules, gotchas.
• references/workflows.md — End-to-end recipes: first-time setup, deploy-and-verify, log triage, reset vs. restart vs. snapshot-restore, switching environments, CI usage.
• references/troubleshooting.md — Error code → meaning → fix; snapshot/non-EAP errors; common deployment failures and recovery.