/code-standards-checker

name: code-standards-checker
description: Run the right linting, formatting, and static-analysis commands after changing code, and check it against PHPCS, ESLint, WordPress Coding Standards, or Drupal Coding Standards. Reads the scripts blocks in composer.json and package.json to find the project's own commands, runs auto-fix before check-only and verifies after, and picks the most specific level (theme, plugin, module, or project root) covering the changed files. Invoke when the user mentions "coding standards", "code style", "linting", "lint", "PHPCS", "phpcbf", "PHPStan", "Rector", "ESLint", "stylelint", "twig-lint", asks what to run after editing PHP, Twig, JS, SCSS, or CSS, or asks whether code follows conventions.

Code Standards Checker

Run the project's own standards tooling against the code that changed, then report what is left. Discover the commands by reading the project. Do not recall them.

When to Use This Skill

• After finishing a set of edits to any code the project has tooling for. Step 1

discovers what that is; step 2 maps the changed files to jobs.

• Before committing and before opening a pull request.
• When the user asks "does this follow standards?", "what should I run?", or names a

tool (PHPCS, PHPStan, Rector, ESLint, stylelint, twig-lint).

Not for logic review. `pr-review` covers correctness; run this skill first so standards violations never reach review.

When to Skip

Dependency-only updates need no standards run. This tooling grades custom code, and a version bump changes none of it.

• Composer or npm dependency version bumps
• Drupal module and WordPress plugin updates
• Lockfile updates (`composer.lock`, `package-lock.json`, `yarn.lock`)
• Dependency metadata changes

**Exception:** if a dependency is being patched, forked, or overridden as part of the work — a `cweagans/composer-patches` entry, a committed patch file, a vendor override — that changed code is custom code. Map it in step 2 and run the full pass against it.

Name the files you classified as dependency-only, then move on. In particular, do not run `format` against a `composer.json` version bump on the strength of the JSON row in step 2's table.

Workflow

1. Detect the Project's Own Commands

Script aliases are project-defined. Read them; never assume a name exists.

# Every level that could own the changed files
jq -r '.scripts | keys[]' composer.json
jq -r '.scripts | keys[]' package.json
jq -r '.scripts | keys[]' web/themes/custom/*/package.json          # Drupal theme
jq -r '.scripts | keys[]' public/wp-content/themes/*/package.json   # WordPress theme
jq -r '.scripts | keys[]' public/wp-content/plugins/*/package.json  # block plugin

# What an alias actually does — many are aggregates of other aliases
composer run-script --list
jq -r '.scripts["code-fix"]' composer.json

Then check two things:

• **DDEV**: if `.ddev/` exists, prefix every composer, npm, and wp-cli command with

`ddev` (`ddev composer phpcbf`, `ddev npm run lint:js`).

• **Config files**, which tell you a tool is configured even when no alias wraps it:

`.phpcs.xml.dist`, `phpstan.neon`, `rector.php`, `.twig-cs-fixer.php`, `.eslintrc*`, `.stylelintrc*`.

If no alias covers the job, use the raw invocation from the table below. If neither the alias nor the binary exists, say so rather than inventing a command.

2. Map Changed Files to Jobs

| Changed | Job | Sequence | Raw fallback | |---|---|---|---| | PHP (`.php`, `.module`, `.inc`, `.install`, `.theme`, `.profile`) | Coding standards | `phpcbf` then `phpcs` | `vendor/bin/phpcbf --standard=Drupal,DrupalPractice <path>` (Drupal), `--standard=WordPress` (WordPress), or `--standard=./.phpcs.xml.dist` when the project ships one | | PHP with logic changes | Static analysis | `phpstan` (no auto-fix) | `vendor/bin/phpstan analyse --memory-limit=-1 <paths>` | | PHP after a refactor | Modernization | dry run, then apply | `vendor/bin/rector process <path> --dry-run`, then without `--dry-run` | | Twig templates | Twig standards | fix then lint | `vendor/bin/twig-cs-fixer lint --fix <path>`, then without `--fix` | | JavaScript | Format, then lint | `format` then `lint:js` | `npx wp-scripts format`, `npx wp-scripts lint-js` or `npx eslint <path>` | | SCSS / CSS | Style lint | `lint:css` | `npx wp-scripts lint-style "**/*.scss"` or `npx stylelint --fix "**/*.scss"` | | JSON, HTML, config | Format | `format` | `npx wp-scripts format` | | Any asset in a compiled theme | Build | `build` after the lint pass | `npx wp-scripts build` |

Rector is the one inversion: preview with `--dry-run` first, then apply. Everything else auto-fixes first and verifies after.

3. Common Script Aliases

A lookup, not a command list. Confirm the name in step 1 before running it.

| Alias | Job | Commonly seen in | |---|---|---| | `code-fix` / `code-sniff` | phpcbf then phpcs across custom modules and themes | Kanopi Drupal starter | | `code-fix-modules`, `code-fix-themes`, `code-sniff-modules`, `code-sniff-themes` | Same, scoped to one area | Kanopi Drupal starter | | `code-check` | Aggregate: phpstan, rector dry run, code-sniff | Kanopi Drupal starter | | `phpcbf` / `phpcs` | Auto-fix then check against `.phpcs.xml.dist` | Kanopi WordPress starter, vanilla PHP | | `phpstan` | Static analysis | Both starters, vanilla PHP | | `rector-check` / `rector-fix` | Dry run, then apply | Both starters | | `twig-fix` / `twig-lint` | twig-cs-fixer with and without `--fix` | Kanopi Drupal starter | | `lint-php` | `php -l` syntax check | Kanopi Drupal starter | | `format` | `wp-scripts format` | Any wp-scripts theme or block plugin | | `lint:js` / `lint-js` | `wp-scripts lint-js` | Any wp-scripts theme or block plugin | | `lint:css` / `lint-style` | `wp-scripts lint-style` | Any wp-scripts theme or block plugin | | `build` / `start` | Production build, watch mode | Any wp-scripts theme or block plugin |

Alias names drift from the tool names they wrap: a theme may exp