CtrlK
BlogDocsLog inGet started
Tessl Logo
PluginPublic

adobe/aem-cloud-service

All AEM as a Cloud Service skills: component development, Workflow model design, development, triggering, launchers, debugging, and triaging, Dispatcher config authoring, advisory, incident response, performance tuning, and security hardening, Rapid Development Environment (RDE) deployment, log inspection, snapshots, and troubleshooting via `aio aem rde`, Jackrabbit Oak query/index tuning (property, Lucene index definitions), and extracting/inventorying JCR queries (XPath, SQL2, QueryBuilder) across a codebase.

Quality

85%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Low

Low-risk findings worth noting

Overview
Quality
Evals
Security
Files

SKILL.mdskills/dispatcher/incident-response/

name:
incident-response
description:
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.
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"}

Dispatcher Runtime Incident Response (Cloud)

Investigate cloud runtime incidents involving the Adobe Dispatcher Apache HTTP Server module and related HTTPD configuration with an evidence-first workflow.

Variant Scope

  • This skill is cloud-service-only.
  • Scope is fixed by this skill directory; do not ask the user to choose deployment variant.

MCP Tool Contract

Use only these Dispatcher MCP tools:

  • monitor_metrics
  • tail_logs
  • trace_request
  • inspect_cache
  • validate
  • lint
  • sdk

Workflow

  1. Quantify impact (monitor_metrics).
  2. Classify whether issue belongs to Dispatcher layer or CDN/edge layer using cloud guardrails, including reserved probe-path behavior.
  3. Gather logs and traces (tail_logs, trace_request). To get the full log sequence for a specific request: use tail_logs to obtain entries (some include pid and tid from dispatcher debug lines), then call trace_request(pid=..., tid=...) to retrieve all log lines for that request. See mcp-tool-orchestration.md § Trace by pid:tid.
  4. Inspect cache behavior (inspect_cache).
  5. Correlate with static checks (validate, lint, sdk).
  6. Return containment + remediation + rollback.

Verification Scope Selection

Use shared references to select incident evidence depth:

Output Contract

Always return:

  • incident summary (symptom, impact window, blast radius)
  • evidence table (tool, input, finding)
  • selected test IDs and outcomes
  • probable cause + confidence level
  • containment, durable remediation, and rollback
  • open risks and missing evidence

Guardrails

  • Distinguish observations from inference.
  • Do not claim root-cause certainty without corroborating evidence.
  • Do not claim runtime verification if container/runtime prerequisites were missing.
  • Keep fixes reversible unless user explicitly requests high-risk change.
  • For cloud incidents, explicitly state when root cause is outside Dispatcher config scope (CDN/WAF/edge policy).

References

skills

dispatcher

README.md

SKILL.md

README.md

tile.json