QA Check

Skill: qa-check (Global)

When to Use

Run /qa-check on any web project to audit for Accessibility (WCAG 2.2 AA), Performance, and Code Quality issues. This skill auto-detects the tech stack and adapts its checks accordingly.

Use $ARGUMENTS to scope the audit to a specific directory or file pattern (e.g., /qa-check src/components/). If empty, audit the entire project.

Do NOT fix issues - only report them. Present findings as structured Markdown tables.

Method

Phase 0: Stack Detection

Before running any checks, detect the project's tech stack by scanning the working directory for marker files. Report what was detected before proceeding.

Detection Rules

Scan in this order. A project can match multiple stacks (e.g., WordPress with Node build tools).

Detection Output

Print a summary before running checks:

## Stack Detection

| Stack | Detected | Markers Found |
|---|---|---|
| WordPress/PHP | Yes/No | wp-config.php, style.css (Theme Name: ...) |
| Python | Yes/No | requirements.txt, manage.py |
| Node/JS | Yes/No | package.json (express, react) |
| Static Web | Yes/No | index.html, styles.css |

Then determine which template/view files to scan:

• WordPress: *.php in theme directory, template-parts/, templates/, inc/
• Python (Flask): templates/**/*.html, app/templates/**/*.html
• Python (Django): **/templates/**/*.html, **/templatetags/*.py
• Node (Next.js): pages/**/*.{js,jsx,tsx}, app/**/*.{js,jsx,tsx}, components/**/*.{js,jsx,tsx}
• Node (Express): views/**/*.{ejs,pug,hbs,html}, public/**/*.html
• Node (React/Vue/Svelte): src/**/*.{jsx,tsx,vue,svelte}
• Static Web: *.html, src/**/*.html

Also scan: all *.css files, all *.js or *.ts files in source directories, config files (.env*, *.config.*).

Pillar 1: Accessibility (WCAG 2.2 AA)

Goal: Confirm output pages meet WCAG 2.2 AA requirements. These checks apply to all stacks - scan every file that produces HTML output.

Stack-Specific A11y Checks

• WordPress: Check that wp_nav_menu() outputs use <nav> wrapper. Check the_post_thumbnail() calls for alt text support. Check get_template_part() partials for orphaned interactive elements.
• React/JSX: Check for <img> without alt prop. Check onClick on non-interactive elements (<div onClick>) without role, tabIndex, and onKeyDown. Check for autoFocus usage.
• Vue: Check v-html usage (potential a11y bypass - content may lack proper semantics). Check :alt bindings on images.

Report: PASS / WARN / FAIL per check.

Pillar 2: Performance

Goal: Identify performance issues. Checks are adapted per detected stack.

Stack-Specific Performance Checks

WordPress:

• Check for wp_enqueue_script() / wp_enqueue_style() usage vs raw <script> / <link> tags (should use enqueue system).
• Flag query_posts() usage - should use WP_Query or get_posts() instead.
• Flag missing wp_cache_get() / wp_cache_set() on expensive queries.
• Check if wp_deregister_script('jquery') is used properly (common source of breakage).
• Flag get_posts() / WP_Query calls without 'no_found_rows' => true when pagination isn't needed.

Python (Flask/Django):

• Check for select_related() / prefetch_related() usage in Django views with related model access.
• Flag Flask routes that open database connections without connection pooling.
• Check for missing @cache decorators on expensive view functions.

Node/JS:

• Flag synchronous file operations (readFileSync, writeFileSync) in request handlers.
• Check for node_modules files accidentally served to the client.
• Flag missing compression middleware in Express.

Report: PASS / WARN / FAIL per check.

Pillar 3: Code Quality

Goal: Identify security issues, code smells, and quality problems. Checks are adapted per detected stack.

Security (All Stacks)

Stack-Specific Security

WordPress / PHP:

• $wpdb->prepare() must be used for all $wpdb->query() / $wpdb->get_results() calls with variables.
• All output must use esc_html(), esc_attr(), esc_url(), or wp_kses() as appropriate.
• Forms must include wp_nonce_field() and handlers must verify with wp_verify_nonce() or check_admin_referer().
• User input must use sanitize_text_field(), absint(), sanitize_email(), etc.
• Flag extract() usage (variable injection risk).
• Flag eval(), assert(), preg_replace() with e modifier.

Python:

• Parameterized queries required for all database calls (no string formatting in SQL).
• No eval(), exec(), or __import__() with user-controlled input.
• No bare except: - must catch specific exceptions.
• Check for pickle.loads() on untrusted data.
• Check for DEBUG = True in production config.
• Check for SECRET_KEY hardcoded in settings.

Node / JS:

• No eval(), Function(), or child_process.exec() with user input.
• Check for helmet or manual security headers in Express apps.
• Check for cors configuration (not origin: '*' in production).
• Check for --unhandled-rejections=none or missing error handlers.
• Check package.json for "engines" field (Node version pinning).
• Flag npm audit issues if package-lock.json is present.

General Code Quality

Report: PASS / WARN / FAIL per check.

Output Format

Present results as Markdown tables. Use this exact structure:

## QA Audit - <date>

### Stack Detection

| Stack | Detected | Markers Found |
|---|---|---|
| WordPress/PHP | Yes/No | ... |
| Python | Yes/No | ... |
| Node/JS | Yes/No | ... |
| Static Web | Yes/No | ... |

**Files scanned:** <count> files across <directories>

---

### Summary

| Pillar | Status | Pass | Warn | Fail |
|---|---|---|---|---|
| Accessibility | PASS/WARN/FAIL | <n> | <n> | <n> |
| Performance | PASS/WARN/FAIL | <n> | <n> | <n> |
| Code Quality | PASS/WARN/FAIL | <n> | <n> | <n> |

Overall pillar status: FAIL if any check is FAIL, WARN if any check is WARN, PASS otherwise.

---

### Findings

#### Pillar 1: Accessibility

| # | Check | Status | Detail |
|---|---|---|---|
| 1 | Semantic HTML | PASS/WARN/FAIL | ... |
| 2 | Image alt text | PASS/WARN/FAIL | ... |
| ... | | | |

#### Pillar 2: Performance

| # | Check | Status | Detail |
|---|---|---|---|
| 1 | Image optimization | PASS/WARN/FAIL | ... |
| 2 | Asset loading | PASS/WARN/FAIL | ... |
| ... | | | |

#### Pillar 3: Code Quality

| # | Check | Status | Detail |
|---|---|---|---|
| 1 | SQL injection | PASS/WARN/FAIL | ... |
| 2 | XSS | PASS/WARN/FAIL | ... |
| ... | | | |

---

### Action Items

Numbered list of issues requiring attention, ordered by severity:

1. **[FAIL]** <description> - `<file>:<line>`
2. **[FAIL]** <description> - `<file>:<line>`
3. **[WARN]** <description> - `<file>:<line>`
...

Rules

• Do NOT fix issues. Report only. The user decides what to fix.
• Do NOT skip checks. Run every applicable check for every detected stack. If a check is not applicable to the detected stack, mark it N/A in the table.
• Be specific. Include file paths and line numbers in findings where possible.
• Avoid false positives. If you're uncertain whether something is an issue, mark it WARN with an explanation, not FAIL.
• Respect project conventions. If a CLAUDE.md or equivalent project config exists, use its rules for formatting/naming checks instead of generic defaults.
• Stack-specific checks are additive. Always run the generic checks. Stack-specific checks are additional - they don't replace the generic ones.
• Scan depth. Scan all source files relevant to the detected stack. Do not scan node_modules/, vendor/, venv/, .venv/, __pycache__/, dist/, build/, .git/, or other dependency/build/cache directories.