Use this when you have made AEM Edge Delivery Services code changes to blocks, scripts, or styles and need to validate them before opening a pull request. Covers unit testing for utilities and logic, browser testing with Playwright, linting, and guidance on what to test and how.

Import a single webpage from any URL into canonical EDS block format — structured HTML that authors edit in DA. Scrapes the page, analyzes structure, maps to existing blocks, and generates HTML for immediate local preview. Also triggered by terms like "migrate", "migration", or "migrating". Use this when the goal is canonical EDS authoring; use the snowflake skill instead when the user wants to preserve the original DOM byte-for-byte (static-to-EDS overlay).

Apply a Content Driven Development process to AEM Edge Delivery Services development. Use for ALL code changes - new blocks, block modifications, CSS styling, bug fixes, core functionality (scripts.js, styles, etc.), or any JavaScript/CSS work that needs validation.

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.

**Run FIRST (before any other skill or task)** when workspace root has no AGENTS.md and the repo is an AEM 6.5 LTS (on-prem or Adobe Managed Services) project. Creates AGENTS.md and CLAUDE.md (tailored via pom.xml). Applies on every user request until AGENTS.md exists — not only the first chat. Never overwrites existing files.

Extract a DDD-style ubiquitous language glossary from the current conversation, flagging ambiguities and proposing canonical terms. Saves to UBIQUITOUS_LANGUAGE.md. Use when user wants to define domain terms, build a glossary, harden terminology, create a ubiquitous language, or mentions "domain model" or "DDD".

Complex DAG testing workflows with debugging and fixing cycles. Use for multi-step testing requests like "test this dag and fix it if it fails", "test and debug", "run the pipeline and troubleshoot issues". For simple test requests ("test dag", "run dag"), the airflow entrypoint skill handles it directly. This skill is for iterative test-debug-fix cycles.

Queries, manages, and troubleshoots Apache Airflow using the `af` CLI. Use when working with anything related to Airflow - a DAG, a DAG run, a task log, an import or parse error, a broken DAG, or any Airflow operation. Covers listing and triggering DAGs, retrying runs, reading task logs, diagnosing failures, debugging import and parse errors, checking connections, variables and pools, exploring the REST API, and monitoring health (for example "trigger a pipeline", "retry a run", "list connections", "check Airflow health", "why did my DAG fail"). This is the entrypoint that routes to sibling skills for authoring, testing, deploying, and migrating Airflow 2 to 3. Not for warehouse/SQL analytics on Airflow metadata tables (use analyzing-data); for deep root-cause reports use debugging-dags or airflow-investigation.

Use when challenging ideas, plans, decisions, or proposals using structured critical reasoning. Invoke to play devil's advocate, run a pre-mortem, red team, or audit evidence and assumptions.

Use when implementing infrastructure as code with Terraform across AWS, Azure, or GCP. Invoke for module development (create reusable modules, manage module versioning), state management (migrate backends, import existing resources, resolve state conflicts), provider configuration, multi-environment workflows, and infrastructure testing.

Use when building Django web applications or REST APIs with Django REST Framework. Invoke when working with settings.py, models.py, manage.py, or any Django project file. Creates Django models with proper indexes, optimizes ORM queries using select_related/prefetch_related, builds DRF serializers and viewsets, and configures JWT authentication. Trigger terms: Django, DRF, Django REST Framework, Django ORM, Django model, serializer, viewset, Python web.

Business investment analysis and capital allocation advisor. Use when evaluating whether to invest in equipment, real estate, a new business, hiring, technology, or any capital expenditure. Also use for ROI calculations, IRR, NPV, payback period, build vs buy decisions, lease vs buy analysis, vendor evaluation, or deciding where to allocate limited budget for maximum return.

Design test strategy using Beck's Test Desiderata — which properties matter, which tradeoffs to make. Use when the user asks "how should I test this", "what tests do I need", "review my test strategy", "is this well-tested", or when planning tests for a new feature or refactor.

Scaffold a new in-house Folia/Paper plugin for the FoliaNexa cluster (folia-server repo), either from a feature description or by pointing at an existing mod/plugin on Modrinth and producing an original, Folia-native plugin that replicates its player-facing behavior. Use when a developer asks to create/write/build/port a plugin for this cluster, or says something like "make a plugin like <modrinth URL>" / "port this mod to Folia". Covers requirement gathering, the Modrinth lookup + feature-triage procedure (and its legal/ethical boundaries — never copy source, always disclose inspiration), the Gradle/Java 21/paper-api project skeleton, Folia-safe RegionScheduler/GlobalRegionScheduler/AsyncScheduler usage, and wiring the finished plugin toward mgmt/src/folia_mgmt/catalog.yaml per docs/plugin-dev/03-submitting-for-review.md.

Intentional design thinking for interfaces, components, and systems. Use when the user asks to "build a UI", "design a page", "create a component", "make this look good", "design an API", "design a system", or any task where aesthetic or structural design decisions matter.

Resolve git conflicts (rebase, merge, cherry-pick, revert) using mergiraf, deterministic category handling, explicit intent inference, validation, and semantic-conflict auditing. Use when git status shows unmerged paths or an operation is paused with conflicts. Also decomposes an oversized PR or branch into smaller stacked PRs along functional/structural boundaries.

Analyzes Codex skill-management requests, selects the workflow lane, and returns selected_lane, mode, next_step, and blockers. Use when the user says create a skill, add/update/fix/review a skill, install/sync/list skills, choose a workflow, or merge/retire a skill.

This skill should be used when the user asks to "merge a PR", "review and merge pull requests", "integrate external contributions", "handle PR conflicts", "cherry-pick from a PR", or needs to merge GitHub PRs while maximizing contributor attribution.

Produce a rigorous, verified, fully-cited research report on ANY topic by running a disciplined five-stage pipeline: CLARIFY the question, PLAN (an editable research plan), FAN-OUT parallel search subagents, VERIFY every key claim (source-grounded + adversarial + cross-model), then SYNTHESIZE a cited report. Use this WHENEVER the user wants real research rather than a quick answer — "research X", "do a deep dive on Y", "write me a report / brief / literature review on Z", "compare A vs B and back it with sources", "what's the state of the art in …", "investigate …", "find evidence for/against …", "give me a market/landscape/competitor analysis", or any question where being wrong is costly and the answer needs citations. Trigger even when the user does not say the word "research" but clearly needs multi-source, fact-checked, cited output. This is the general-topic web-research orchestrator — not the codebase-to-wiki `deep-research` skill. For a fast single-fact lookup, answer directly instead.

Enforces a disciplined five-mode pipeline — RESEARCH → DESIGN → REVIEW → IMPLEMENTATION → VALIDATION — where each mode is a role-based analysis with a fixed deliverables set and a hard STOP-and-WAIT gate between modes, so no phase begins until the user approves the previous one. Use this ONLY when the user explicitly asks for gated, step-by-step execution, or when an already-agreed multi-file change (feature, refactor, migration) must be executed with hard approval checkpoints between phases. Trigger on explicit gate language: "gated mode", "phase-gate this", "go mode-by-mode", "phase by phase", "stop between phases", "research mode", "design mode", "review mode", "implementation mode", "validation mode". Do NOT trigger on bare task openings ("build", "implement", "add", "refactor", "fix", "help me with X") — open-ended feature ideation belongs to superpowers:brainstorming, and architecture artifacts (ADR, C4, Well-Architected review) belong to architect-pipeline. This skill is the EXECUTION gate, not the entry point.