L’interface est localisée ; les présentations et documents des Skills sont traduits automatiquement par IA dans votre langue. Le code, les commandes, chemins et termes techniques restent en version originale, et le document de l’auteur fait foi.
Explorer les Skills
Développement · SKILL.md

config-authoring

config-authoring

Create, modify, review, and harden configuration for the Adobe Dispatcher Apache HTTP Server module and Apache HTTPD in AEM 6.5 LTS environments only. Use for `.any`, vhost, rewrite, cache, and filter changes.

Independent GitHub snapshot · Automated classification · Original documentation governs

Aadobe / skillsApache-2.0

Documentation de la Skill

GitHub

name: config-authoring description: Create, modify, review, and harden configuration for the Adobe Dispatcher Apache HTTP Server module and Apache HTTPD in AEM 6.5 LTS environments only. Use for .any, vhost, rewrite, cache, and filter changes. license: Apache-2.0 compatibility: Requires Dispatcher MCP for AMS (AEM_DEPLOYMENT_MODE=ams) or AMS Dispatcher MCP SDK (pre-set to ams). allowed-tools: validate lint sdk trace_request inspect_cache monitor_metrics tail_logs metadata: mcp-tool-contract: core-7-tools

Dispatcher Config Authoring (AMS)

Design minimal, deterministic changes for the Adobe Dispatcher Apache HTTP Server module and related HTTPD configuration in AEM 6.5/AMS, then verify with MCP evidence.

Variant Scope

  • This skill is AMS-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:

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

Workflow

AMS Config Progress
- [ ] 1) Confirm scope and acceptance criteria; if the repo layout is unclear, normalize it with `repo-layout-workflows.md`
- [ ] 2) Apply AMS 6.5 guardrails for tier routing, variables, flush ACL, and immutable boundaries
- [ ] 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 host-path/log environment
- [ ] 8) Return diff, evidence table, risk/rollback, and citations

Verification Scope Selection

Use the shared references to select the minimum evidence set:

Output Contract

Always include:

  • files changed + intent
  • exact insertion location and final merged section content for each edited block
  • checks executed + evidence
  • selected test IDs
  • risk/rollback plan
  • residual risks and next checks

Feature cross-boundary (Playbook G: auth_checker)

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.

Guardrails

  • Do not weaken deny-by-default security posture without explicit user approval.
  • Do not claim runtime verification if host-path/log prerequisites were missing.
  • Keep changes minimal and scoped.

References

Skills enregistrées