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.