drupal-site-test-suite

Evaluate and summarize accessibility (WCAG) findings on a Drupal 10 or 11 site; aggregating the a11y test lanes (axe-core, Siteimprove Alfa, pa11y, reflow at 320px, meta-viewport). Read-only: it gets findings (from `drush utest:alfa|axe|pa11y|reflow|meta-viewport` runs or existing JSON/HTML reports), normalizes and merges them, classifies each as legally-required (standard profile) vs aspirational (comprehensive AAA/best-practice), attributes it to custom code vs upstream core/contrib, and produces a prioritized, profile-aware accessibility audit. Use for "audit accessibility", "what WCAG issues does the site have", "summarize the axe/pa11y/Alfa report", "check accessibility compliance". Stops before changing files; hand off to drupal-accessibility-remediation to fix. Never claims full conformance.

Apply fixes for accessibility (WCAG) findings on the CUSTOM code of a Drupal 10 or 11 site, then re-verify. Consumes the audit from drupal-accessibility-audit, maps each page/selector finding back to the custom Twig template / theme CSS / content / config that produced it, proposes WCAG-correct fixes (reusing the a11y agent's WCAG 2.2 AA knowledge), dry-runs them, and applies only confirmed changes; prioritizing legally-required (WCAG A/AA) issues. Most a11y fixes need human judgment (alt text, ARIA, contrast) so it confirms before writing. Writes only to the working tree; never commits, never pushes. Never claims full conformance; human testing still required. Use for "fix the accessibility issues", "remediate the WCAG/axe/pa11y violations", "fix the a11y findings".

Evaluate and summarize code-quality / static-analysis findings on the CUSTOM code of a Drupal 10 or 11 site; PHPCS, PHPStan, ESLint, cspell, composer audit/validate, markdownlint, actionlint, deprecations, and related engines. Read-only: it gets findings (from a `drush utest:lint` run, an existing JSON/HTML report, or by evaluating custom code directly when no test suite exists), normalizes them, then groups, dedups, and prioritizes into an audit/triage report. Use for "audit the lint results", "what coding-standards issues does my custom module have", "summarize the static-analysis report", "evaluate my site's custom code for quality issues", "triage the findings". Stops before changing files; hand off to drupal-code-quality-remediation to fix.

Apply safe fixes to code-quality / linting findings on the CUSTOM code of a Drupal 10 or 11 site, then re-verify. Consumes the audit from drupal-code-quality-audit (its diagnostic agent), dry-runs the fixes, gets confirmation, and auto-applies ONLY high-confidence mechanical fixes (phpcbf, eslint --fix, stylelint --fix, markdownlint --fix, editorconfig); flagging everything else (PHPStan type errors, logic, security, deprecations) for human review. Use for "fix the lint errors", "apply the safe coding-standards fixes", "clean up the linting violations", "remediate the static-analysis report". Writes only to the working tree; it never commits and never pushes.

The shared modern coding + documentation standards for custom Drupal 10/11 code; Drupal 10.3+ idioms (constructor property promotion, PHP attributes not annotations, #config_target, OOP #[Hook] implementations, translatable strings, dependency injection), Doxygen doc-blocks and .api.php, README/documentation-file conventions, and secrets handling. Use when writing, editing, or reviewing any custom Drupal module/theme/profile code. The other drupal-* skills (module-scaffold, hook-update-n, phpunit-tests) follow this baseline; cite it rather than duplicating these rules.

Manage Drupal 10/11 configuration across environments, the config sync workflow (drush config:export / config:import), module config (config/install vs config/sync, required schema), environment-specific config via config_split, and site-specific overrides via config_ignore. Detects whether a site actually uses config management before applying. Use when exporting/importing config, setting up per-environment config, or diagnosing config drift. Vendor-neutral; follows drupal-coding-standards.

Write Drupal `hook_update_N` / `hook_post_update_NAME` functions for custom modules; config rewrites, module/theme machine-name renames, entity-bundle and field-storage changes, permission remaps, data backfills; plus the paired update-path test fixture. Use when an upstream/shared codebase ships a schema/config/data change that downstream sites must apply on update (mutating state that already exists on a running site). Vendor-neutral; follows drupal-coding-standards.

Scaffold a new Drupal 10/11 custom module from scratch; `.info.yml`, `.module`, `.install`, `.services.yml`, `.routing.yml`, `.permissions.yml`, `src/` service layout, `Plugin/` directories, `tests/` boilerplate, `composer.json`, `README.md`. Follows Drupal + DrupalPractice coding standards from the start, declares D10/D11 compatibility, and uses proper dependency injection (no `\Drupal::service()` in classes). Use when creating a new custom module, consolidating modules under a new name, or starting a module destined for drupal.org.

Write PHPUnit Unit and Kernel tests for custom Drupal modules; service behavior, classification/transition logic, config defaults, entity validation, access logic, route requirements, CSV/export ordering, uninstall cleanup. Use when adding or improving test coverage for custom code, especially to protect behavior before an upstream/shared change is pushed across downstream sites. Test classes live inside the module under test. Vendor-neutral; follows drupal-coding-standards.

Handle secrets (API keys, tokens, credentials) in custom Drupal 10/11 code without committing them, the Key module as the abstraction, reading keys at runtime via dependency injection, and provider setup (Pantheon Secrets, environment variables, file-based). Use when a custom module needs a credential at runtime, or when removing a hard-coded/committed secret. Vendor-neutral core with hosting-specific provider sections; follows drupal-coding-standards.

Scaffold a new custom Drupal 10/11 sub-theme from scratch; theme `.info.yml` (base theme, regions, libraries), `.libraries.yml`, `.breakpoints.yml`, `.theme` preprocess file, `templates/`, `theme-settings.php`, logo + screenshot, and CSS/JS wired through libraries. Prefers Drupal's Starterkit generator. Use when creating a new custom theme or sub-theme, not when editing an existing one. Vendor-neutral; follows drupal-coding-standards.