[aem] Feature roadmap from Thej KM review: 15 skills, 6 agent roles, and shared delivery standards

Start by reading the existing AEM skill paths cited in the issue, especially the Cloud Service code-assessment and Dispatcher guidance, then compare them with the listed 15 workstreams. The issue defines proposed acceptance criteria but leaves implementation boundaries across many skills to be worked out. Done means the requested capabilities are added without duplicating existing coverage and each workstream meets its acceptance criteria.

Goal and source

This umbrella issue preserves the article's 15 skills, original P1/P2/P3 priorities, six agent roles, and cross-cutting recommendations. It does not import the separate Opus review's 102-item feature expansion.

The deliverables and acceptance criteria below are proposed implementation details derived from those requests, not quotations or additional claims made by the author. Existing coverage was checked against repository commit 8f35e907; recheck it before implementing each item.

Boundaries and related work

Workstream	Owner
Cloud Service correctness defects	#494
AEM 6.5 LTS correctness defects	#495
README, installation, inventory and descriptive metadata corrections	#496
Names, nesting, shared references, existing runtime guards and distribution structure	#497
New capabilities and extensions described below	This issue

This is a planning/tracking issue, not permission to change environments, publish content, create secrets, run pipelines, or execute migrations. Remote writes and destructive operations require explicit authorization for the actual target and operation.

Deferred: EDS/project-management automation remediation, including the PDF hook, unattended dependency installation/source deletion, and login-helper concerns, remains outside this issue. Existing EDS capabilities may be referenced for routing or reuse, without reopening that deferred work.

Avoid duplicate implementations: OSGi configuration, Cloud Manager variables, Repoinit, component tests, Core Component extension, template modernization, and Oak conversion already have relevant coverage. Where noted below, the feature is improved discoverability, broader task coverage, or an end-to-end workflow built on that material, not recreating it under a second independently maintained implementation.

---

Section 1. Priority 1: highest daily impact

P1-01. Cloud Manager pipeline failure diagnosis

Requested outcome: Turn a failed Cloud Manager pipeline into an evidence-backed diagnosis and the smallest justified remediation.

Proposed scope

• Accept a pipeline/execution identifier or supplied logs and identify the failing stage.
• Distinguish application build, analyzer/API, code-quality, Dispatcher, test, and deployment failures using available evidence.
• Reuse existing code-assessment and Dispatcher guidance for supported fixes; do not build a parallel rules engine.
• State when an infrastructure/platform failure requires escalation rather than a code change.

Deliverable: Failure summary, cited log evidence, confidence, affected files or configuration, minimal proposed fix, and the exact verification or escalation path.

Acceptance criteria

• Diagnose a representative failing execution without claiming access to unavailable logs or tools.
• Distinguish symptoms from a demonstrated cause and report unresolved alternatives explicitly.
• Validate an approved repository fix with the relevant build/checks.
• Do not automatically rerun a pipeline, deploy, or modify an environment.

Reuse: plugins/aem/cloud-service/skills/code-assessment/, especially deprecated/API-related failure handling, and the existing Dispatcher skill family.

P1-02. OSGi configuration authoring, run modes, environment variables and secrets

Requested outcome: Author and validate ordinary AEM Cloud Service OSGi configuration, not only migrate legacy secrets.

Existing coverage: plugins/aem/cloud-service/skills/migration/references/osgi-cfg-json-cloud-manager.md already covers .cfg.json, run modes, placeholders, and Cloud Manager variables. This request must extend or expose that workflow rather than describe it as absent.

Proposed scope

• Create and review PID/factory configurations in the correct module and runtime-specific folders.
• Explain configuration precedence and distinguish inline values, environment values, and secrets.
• Prepare an explicit environment-variable handoff and validate effective configuration where access is available.

Acceptance criteria

• Reuse a canonical set of platform rules and link to version-appropriate sources.
• Reject unsupported run modes and unsafe or inapplicable placeholder usage.
• Keep secret values out of source, prompts, evidence artifacts, and logs.
• Produce a reviewable repository diff and a separate, explicitly authorized remote-change plan.

P1-03. Repoinit scripts and service users

Requested outcome: Provision service identities and least-privilege repository access, including the corresponding service-user mapping.

Existing coverage: plugins/aem/cloud-service/skills/code-assessment/references/resource-resolver-logging.md already contains Repoinit and subservice-mapping guidance.

Proposed scope

• Discover and reuse existing service users and mappings before adding new ones.
• Author the Repoinit configuration and matching bundle/subservice mapping.
• Explain privileges, paths, runtime placement, and expected permission failures.

Acceptance criteria

• Produce consistent user, subservice, bundle, and configuration identifiers.
• Demonstrate repeatable provisioning and least-privilege access using a supported test environment.
• Include a denied-access case, not only a successful read/write.
• Never substitute an administrative resolver or broad permissions to hide a mapping problem.

P1-04. CDN configuration: WAF, traffic filters and edge redirects

Requested outcome: Create and review Cloud Service CDN rules with a deployment and verification plan.

Proposed scope

• Cover the article's WAF, traffic-filter, and edge-redirect use cases.
• Distinguish CDN-owned behavior from Dispatcher or application behavior.
• Validate rule structure and matching assumptions against current product documentation/tooling.
• Identify rule-ordering, blocking, redirect-loop, and unintended-path risks.

Acceptance criteria

• Provide representative matching and nonmatching request cases.
• Produce a reviewable configuration change and explicit deployment prerequisites.
• Include staged verification, rollback, and impact boundaries.
• Require approval before deploying rules, blocking traffic, or changing live redirects.

P1-05. Local AEM SDK and Dispatcher SDK setup

Requested outcome: Take a developer from prerequisites to a working local author/publish and Dispatcher development loop.

Proposed scope

• Check runtime, compatible Java/Maven/container prerequisites, ports, and SDK access.
• Explain supported SDK acquisition and distinguish local SDK workflows from RDE and Cloud Manager.
• Reuse existing Dispatcher SDK execution and migration-validation instructions where applicable.
• Build and deploy a minimal project/component and verify the resulting local route.

Acceptance criteria

• Verify readiness through actual responses and runtime state, not only process startup.
• Document repeatable start/stop behavior and actionable failures.
• Mark local-only credentials explicitly; do not recommend them for shared environments.
• Do not install system dependencies with unattended privilege escalation.

---

Section 2. Priority 2: quality and modern delivery

P2-01. Unit-test generation using wcm.io AemContext

Requested outcome: Generate useful behavior-focused AEM unit tests.

Existing coverage: plugins/aem/cloud-service/skills/create-component/references/test-patterns.md already generates JUnit/AemContext component tests.

Proposed scope: Extend the existing patterns to user-selected existing code and additional AEM services/servlets/workflow logic where appropriate; reuse project dependencies, fixtures, and test conventions.

Acceptance criteria

• Run the generated tests using the project's existing runner.
• Assert behavior and relevant failure paths, not only getters or mock interactions.
• Avoid mocks that bypass the behavior under test or conceal invalid AEM setup.
• Do not create a second conflicting component-test implementation.

P2-02. Content-package and filter.xml linting

Requested outcome: Catch package layout and filter mistakes before deployment.

Proposed scope: Validate filter roots/modes, package boundaries, dependencies, and mutable/immutable placement using deterministic checks where possible. Reuse existing migration package-dependency checks rather than duplicate them.

Acceptance criteria

• Produce file/line evidence and a specific reason for each finding.
• Distinguish valid project conventions from genuinely unsafe or invalid packaging.
• Cover both invalid fixtures and valid packages that must not be flagged.
• Keep remediation minimal and verify the resulting package build.

P2-03. Headless GraphQL and persisted-query caching

Requested outcome: Implement and troubleshoot persisted-query delivery and caching for AEM headless use cases.

Proposed scope: Connect the query/model/endpoint setup to HTTP delivery and appropriate Dispatcher/CDN cache behavior, without conflating author preview and publish delivery.

Acceptance criteria

• Show an executable persisted-query example with an expected response.
• Verify cache-related headers and representative query variants on an authorized target.
• Explain invalidation/freshness assumptions and permission-sensitive cases.
• Do not claim a query is cached based only on configuration text.

P2-04. Universal Editor instrumentation for AEM Sites

Requested outcome: Add and validate Universal Editor instrumentation in the AEM Sites context.

Existing adjacent coverage: EDS already has plugins/aem/edge-delivery-services/skills/ue-component-model/. Evaluate reuse without assuming its EDS workflow fully covers AEM Sites.

Acceptance criteria

• Identify the applicable authoring model and prerequisites before editing.
• Produce the required component/model instrumentation and explain its content mapping.
• Validate rendered markup and, when an authorized environment is available, an authoring round trip.
• Report environment-dependent checks as unverified when they cannot be executed.

P2-05. Oak index lifecycle on Cloud Service

Requested outcome: Manage index definitions through Cloud-compatible versioning, deployment, verification, and recovery.

Existing coverage: Cloud code-assessment contains tuning-oak-query-indexes; migration Branch F already covers Oak conversion in beta. The missing end-to-end lifecycle must be separated from those existing capabilities.

Acceptance criteria

• Reuse query/index analysis and conversion guidance instead of recreating it.
• Validate naming/versioning and deployment prerequisites against current Cloud rules.
• Verify the deployed index and query plan where environment access permits.
• Provide a recovery plan without suggesting arbitrary direct writes or uncontrolled production reindexing.

---

Section 3. Priority 3: depth and hygiene

P3-01. Log forwarding and tailing

Requested outcome: Configure supported log forwarding and collect relevant AEM logs for a bounded investigation.

Existing adjacent coverage: RDE already supports log-tail workflows; workflow and Dispatcher guides also consume logs. Extend coverage rather than duplicate those commands.

Acceptance criteria

• Distinguish local SDK, RDE, and non-RDE Cloud environments.
• Prepare supported forwarding configuration with a reviewable deployment plan.
• Collect bounded time windows and preserve timestamps/correlation identifiers.
• Redact credentials and sensitive payloads and report missing permissions clearly.

P3-02. AEM security review

Requested outcome: Review AEM code and configuration beyond the existing Dispatcher-only security workflow.

Proposed scope: Cover relevant HTL output contexts, Sling/servlet exposure, service-user access, Repoinit/ACLs, credentials, and deployment configuration. Reuse the Dispatcher security skill for its existing domain.

Acceptance criteria

• Report evidence, affected locations, impact, confidence, and a minimal remediation.
• Separate confirmed findings from recommendations and missing evidence.
• Include valid secure examples that must not trigger findings.
• Default to read-only review; require explicit authorization for changes or active testing.

P3-03. AEM performance review

Requested outcome: Explain slow-page or throughput problems with evidence across relevant AEM layers.

Existing adjacent coverage: Dispatcher performance tuning and Oak query analysis already exist.

Acceptance criteria

• Reuse those specialists and identify the measured bottleneck rather than guessing.
• Record baseline measurements and the conditions under which they were collected.
• Recommend the smallest measurable change and verify its effect.
• Do not run uncontrolled load tests or make production tuning changes without approval.

P3-04. Multi-site management and translation

Requested outcome: Guide MSM/live-copy and translation configuration and diagnose common rollout/translation failures.

Acceptance criteria

• Identify blueprint/live-copy relationships, inheritance, locales, and relevant configuration.
• Produce a scoped rollout or translation plan with representative verification cases.
• Distinguish configuration issues from content state and external integration failures.
• Require approval before rollout, inheritance-breaking changes, or translation submissions.

P3-05. Archetype upgrades

Requested outcome: Upgrade an existing project toward an appropriate supported archetype baseline without losing customization.

Acceptance criteria

• Inventory current versions, runtime, modules, and customizations before proposing an upgrade.
• Produce a compatibility-aware change plan and explain intentional differences from generated defaults.
• Apply minimal reviewed changes rather than overwrite the project with a generated skeleton.
• Verify package/build/tests and provide rollback and unresolved-compatibility notes.

---

Section 4. Six outcome-owning agent roles

An agent should compose existing/new skills, tools, evidence, and approval boundaries around an outcome. These are six separate role definitions, not six duplicates of the skill backlog. The article does not assign these agents P1/P2/P3 priorities.

A-01. AEM Pipeline Doctor

Outcome: Diagnose a failed Cloud Manager execution and propose or implement the smallest approved fix.

Composition: P1-01 plus relevant code-assessment, Dispatcher, packaging, and test capabilities.

Acceptance criteria

• Trace the diagnosis to the failing execution/stage and source evidence.
• Separate repository remediation from environment/platform escalation.
• Verify approved fixes and require separate authorization for pipeline execution/deployment.

A-02. AEM Code Reviewer

Outcome: Review a PR against applicable Cloud Service quality and correctness rules.

Composition: Code-assessment, package linting, tests, and security review, including Sonar-related evidence, Sling Model hygiene, HTL, Repoinit and ACLs.

Acceptance criteria

• Review the actual changed scope and relevant contracts, not only keyword matches.
• Distinguish local findings from externally verified quality-gate results.
• Return actionable locations, evidence, impact and confidence; do not automatically rewrite or approve the PR.

A-03. AEM Environment & Config Agent

Outcome: Coordinate run-mode configuration, variables/secrets, CDN rules, and log forwarding.

Composition: P1-02, P1-03, P1-04 and P3-01.

Acceptance criteria

• Establish the exact program/environment/runtime and permission prerequisites.
• Separate source-controlled changes from remote operations and protect secret values.
• Present a coherent deployment, verification and rollback plan with approval gates.

A-04. AEM Incident Responder

Outcome: Provide a read-only first response for stuck workflows, cache problems, and slow pages.

Composition: Existing workflow/Dispatcher/replication specialists plus relevant logging and performance capabilities.

Acceptance criteria

• Produce a timestamped evidence log, hypotheses, impact assessment and next checks.
• State confidence and distinguish proven causes from suspected causes.
• Do not clear queues, restart services, purge caches, publish content or modify configuration during read-only triage.

A-05. AEM Onboarding Agent

Outcome: Guide a developer to a working local SDK and first deployed component.

Composition: P1-05, existing project bootstrap and create-component skills, and their tests.

Acceptance criteria

• Discover prerequisites and runtime rather than assume a machine layout.
• Verify the local environment, deployment and rendered component.
• Produce a reproducible handoff; report prerequisites or access blockers rather than promise a fixed completion time.

A-06. AEM Modernization Agent

Outcome: Coordinate phased migration from 6.5/AMS to Cloud Service or an explicitly chosen EDS target, with human checkpoints.

Composition: Existing assessment/migration and target-specific skill families; reuse conversion and validation work already present.

Acceptance criteria

• Establish source and target explicitly and produce a read-only assessment/runbook first.
• Sequence changes by dependency and bounded review batches, preserving existing checkpoint behavior.
• Verify each approved phase and keep migration, content movement and deployment authorization separate.
• Route EDS work to existing target-specific capabilities without including deferred EDS/project-management automation remediation.

---

Section 5. Cross-cutting capabilities from the article

X-01. Explicit runtime-aware AEM router

Requested outcome: Select appropriate capabilities using evidence from the project rather than ambiguous bare skill names.

• Detect Cloud Service versus 6.5/AMS using relevant project evidence such as dependencies and Dispatcher layout; recognize EDS projects for handoff.
• Report conflicting/missing evidence and ask for confirmation rather than silently choose.
• Route to existing skills without introducing a second copy of their expertise.
• Coordinate with #497: fixing existing names/guards belongs there; a reusable router capability belongs here.

X-02. Safety declarations and approval contracts

Requested outcome: Make each new skill/agent's permitted effects clear before execution.

• Declare whether a capability is read-only, writes repository files, writes remote systems, or can perform destructive operations.
• Keep targets, permissions, remote approvals, verification and rollback requirements explicit.
• Do not request elevated installation, default shared credentials, or silent remote writes.
• Establish the convention for new capabilities without silently including the deferred retrofit of EDS/project-management automation.

X-03. Behavioral evals for every delivered capability

Requested outcome: Ship the article's minimum three cases with each new skill and relevant agent workflow.

• A should-trigger case with an observable correct outcome.
• A should-not-trigger case covering an adjacent task or wrong runtime.
• A safety case that proves the capability stops or seeks approval at its effect boundary.
• Provide a repeatable execution path and record actual results; do not confuse static frontmatter validation with behavioral evaluation.
• Reuse existing repository evaluation tooling where suitable. Focused bug regressions remain part of #494/#495; this item covers systematic evaluation of the new capabilities.

X-04. Evidence-based cross-tool portability

Requested outcome: Make the delivered capabilities usable through the advertised Claude Code, Copilot, Cursor, Codex and Gemini installation paths.

• Test discovery, parent/sub-skill routing, dependency resolution and script paths for the tool/version combinations claimed as supported.
• Implement a thin adapter only where a demonstrated gap requires name qualification, selective flattening or replacement of Claude-specific calls.
• Do not assume every tool needs flattening or that existing Copilot plugin support is absent.
• Reuse #497's identity/distribution solution and #496's installation documentation rather than duplicate them.

---

Section 6. Shared delivery contract

Every implemented skill should have:

• A unique, runtime-appropriate identity coordinated with #497.
• Clear use when / do not use when boundaries and prerequisite handling.
• A concise SKILL.md, with deeper material in references and existing expertise reused.
• A declared safety tier and explicit handling of unavailable tools/permissions.
• Deterministic validation/tooling where useful, without requiring a script for a purely judgment-based task.
• The should-trigger, should-not-trigger and safety evals above.
• Version-appropriate authoritative sources for platform claims.
• Evidence-backed completion criteria and rollback/impact guidance for state-changing tasks.
• Honest reporting of checks that could not be run.

Agent definitions additionally need explicit composition, outcome, stop conditions, and handoff contracts. They must not claim ownership of a successful end-to-end result merely because an underlying skill returned.

Section 7. Tracking and sequencing

The following checklist is the feature inventory, not evidence that implementation has started:

Priority 1 skills

• P1-01 Cloud Manager pipeline failure diagnosis
• P1-02 OSGi configuration, run modes, environment variables and secrets
• P1-03 Repoinit and service users
• P1-04 CDN WAF, traffic filters and edge redirects
• P1-05 Local AEM SDK and Dispatcher SDK setup

Priority 2 skills

• P2-01 wcm.io AemContext unit-test generation
• P2-02 Content-package and filter.xml linting
• P2-03 Headless GraphQL and persisted-query caching
• P2-04 Universal Editor instrumentation for AEM Sites
• P2-05 Cloud Service Oak index lifecycle

Priority 3 skills

• P3-01 Log forwarding and tailing
• P3-02 AEM security review
• P3-03 AEM performance review
• P3-04 Multi-site management and translation
• P3-05 Archetype upgrades

Agent roles

• A-01 AEM Pipeline Doctor
• A-02 AEM Code Reviewer
• A-03 AEM Environment & Config Agent
• A-04 AEM Incident Responder
• A-05 AEM Onboarding Agent
• A-06 AEM Modernization Agent

Cross-cutting capabilities

• X-01 Runtime-aware router
• X-02 Safety declarations and approval contracts
• X-03 Behavioral evals
• X-04 Evidence-based cross-tool portability

Sequencing proposal: Preserve the blog's P1, then P2, then P3 skill priorities. Reuse verified existing coverage before creating new implementations. Complete or gate on relevant correctness fixes in #494/#495, and coordinate identities/distribution with #497. Agent roles can be delivered incrementally as their required capabilities and guardrails become available. Split child implementation issues from this umbrella when ownership and scope are agreed, retaining these IDs for traceability.