Quality Checks

.\test\check-code-quality.ps1

Use the Bash runner when working in a Unix-like shell and you need to verify that wrapper:

./test/check-code-quality.sh

Workflow

1. If the user asks to run all quality checks, start with the Docker Compose quality stack.
2. If the task changes the PowerShell or Bash wrapper behavior, also run the affected wrapper directly after the Compose run.
3. If the task changes instruction or documentation validation only, it is acceptable to run the narrower wrapper invocation first, for example .\test\check-code-quality.ps1 -Instructions -Documentation, but finish with the broader flow when the change touches shared quality infrastructure.
4. Report whether the Compose flow passed, whether wrapper-specific flows passed, and any intentional differences between them.
5. After a feature or fix is ready, run the relevant automated tests before finishing. At minimum, for quality-infrastructure changes, run the Docker Compose quality flow and any affected wrapper flow.
6. When you learn something non-obvious and repo-specific while working, update .agents/project-lessons.md so the next pass does not have to rediscover it.
7. When you discover instruction drift or a docs regression pattern, update test/check-instructions.mjs so the quality pipeline can catch it automatically next time.

Narrow Runs

Common targeted PowerShell checks:

.\test\check-code-quality.ps1 -PurgeCSS
.\test\check-code-quality.ps1 -Instructions -Documentation

Common targeted Bash checks:

./test/check-code-quality.sh --purgecss
./test/check-code-quality.sh --instructions --documentation

For the canonical commands and expected usage, see references/commands.md.