菜单
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.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
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.
| name | config-authoring |
| description | 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. |
| license | Apache-2.0 |
| compatibility | Requires Dispatcher MCP configured for cloud variant (`AEM_DEPLOYMENT_MODE=cloud`). |
| allowed-tools | ["validate","lint","sdk","trace_request","inspect_cache","monitor_metrics","tail_logs"] |
| metadata | {"mcp-tool-contract":"core-7-tools"} |
Design minimal, deterministic changes for the Adobe Dispatcher Apache HTTP Server module and related HTTPD configuration in AEMaaCS, then verify with MCP evidence.
Use only these Dispatcher MCP tools:
validatelintsdktrace_requestinspect_cachemonitor_metricstail_logsCloud Config Progress
- [ ] 1) Confirm scope and acceptance criteria; if the repo layout is unclear, normalize it with `repo-layout-workflows.md`
- [ ] 2) Apply cloud guardrails (immutable files, required includes, symlink topology, required wildcard ServerAlias coverage, reserved probe paths, preserved cloud vhost defaults, CDN-vs-Dispatcher boundary)
- [ ] 3) Decompose target URLs (path/selectors/extension/suffix) and use that model for all URL-based rules—filters, cache rules, etc.—using `/path`, `/selectors`, `/extension`, `/suffix` or aligned globs (not raw `/url`) where applicable; then design complete section-level edits
- [ ] 4) Update config with least-privilege defaults (produce final merged section, not isolated rule snippets)
- [ ] 5) Run static checks: validate -> lint (deep/order-aware when filters changed)
- [ ] 6) Run SDK checks: `sdk({"action":"check-files","config_path":"<dispatcher src path>"})`, `sdk({"action":"diff-baseline","config_path":"<dispatcher src path>"})` as needed
- [ ] 7) Run runtime verification in container-backed environment
- [ ] 8) Return diff, evidence table, risk/rollback, and citations
Use the shared references to select the minimum evidence set:
Always include:
Permission-sensitive caching (/auth_checker) is end-to-end: it requires both Dispatcher config and an AEM servlet. When implementing Playbook G from scratch, create or verify the auth-check servlet in the project core bundle (path /bin/permissioncheck, HEAD/GET, 200 or 403) and allowlist it on publish; then add the /auth_checker block, filter allow for the endpoint, and /allowAuthorized "1" in /cache. See config-scenario-playbooks.md Playbook G and reference-snippets.md.
cloud-service-aemaacs-guardrails.md before proposing config edits.runtime-prompts-and-troubleshooting-scenarios.md when incident triage is needed.docker_run.sh, hot reload, and runtime env varssrc root and likely file families