QA Review

Purpose / When to Activate

Activate after implementation is complete. This is a hard quality gate.

No pass → no delivery.

---

Process

1. Story Compliance Check

• Parse Story YAML frontmatter
• Extract acceptance criteria
• Validate each criterion is demonstrably satisfied in code
• Any criterion unclear or unmet → FAIL immediately

2. Scope Integrity Check

• Only files within Story scope were modified
• No feature creep introduced
• No unrelated refactors included
• Unexpected changes → FAIL

3. Rule Enforcement

• Confirm compliance with each applicable rule
• Surface violations explicitly
• Any broken rule → FAIL

4. Regression Scan

• Broken tests → FAIL
• Behavior drift → FAIL
• Known risk patterns from memory → FAIL

5. Build / Type / Lint Integrity

Test runners that transpile (vitest, jest, ts-jest, swc, esbuild, babel) execute code WITHOUT type checking — a green test suite does not prove the code compiles. Static-type or linter errors in test files, fixtures, and adjacent modules will pass tests locally and only surface at deploy time.

Identify and run the project's full static-analysis gate for every workspace package whose files were modified (directly or via type/dep propagation):

• TypeScript:

  tsc --noEmit

  (or

  pnpm typecheck

  / equivalent script)
• For Cloudflare Workers projects: regenerate runtime types first (

  wrangler types

  ) — drift between

  worker-configuration.d.ts

  and

  wrangler.jsonc

  masks real errors
• Lint (if the project enforces it as a gate):

  eslint

  ,

  ruff

  ,

  clippy

  , etc.
• Other ecosystems:

  cargo check

  ,

  mypy

  ,

  go vet

  , etc.

If the project documents the exact command in

contexts/memory/patterns/conventions.md

or a delivery rules file, use that command verbatim — do not improvise.

Any error → FAIL. "Test files only" is not a mitigation: test files are part of the typecheck graph and break the deploy gate.

6. Quality Checks

• Error-prone operations lack error handling → FAIL
• External input enters functions without validation → FAIL
• Identifiers are ambiguous or non-descriptive → FAIL
• A function or module handles more than one responsibility without decomposition → FAIL
• Dead code or unreachable branches present → FAIL
• Tests were disabled or skipped to make the suite pass → FAIL

7. Memory Alignment (PASS only)

On PASS verdict, the skill MUST invoke

memory-alignment-check

(SKILL-MEMORY-ALIGNMENT-CHECK-001) before returning. The canonical schema for

{id}.memory-delta.md

is defined authoritatively in

memory-alignment-check/SKILL.md

Outputs section (lines 85–116). QA MUST NOT write or modify

{id}.memory-delta.md

directly — only

memory-alignment-check

writes the delta.

---

Outputs

If PASS:

status: PASS
validated_stories:
  - E01S01
notes:
  - All acceptance criteria satisfied
  - No rule violations
  - No regressions detected

If FAIL:

status: FAIL
blocking_issues:
  - Story E01S01: acceptance criterion #2 not satisfied
  - Rule code-style violated in services/api/user.ts
  - Unexpected file modified: services/payments/
recommended_actions:
  - Fix acceptance behavior
  - Revert out-of-scope change
  - Apply code rule formatting

---

Hard Rules

This skill must NEVER:

• Modify code
• Reinterpret Stories
• Negotiate acceptance criteria
• Approve partial conformance
• MUST NOT write or modify

  contexts/artefacts/memory-deltas/{id}.memory-delta.md

  directly. The delta is written exclusively by

  memory-alignment-check

  (invoked at Step 6). Free-form delta variants are a governance violation.

If it's not explicitly validated → it's broken. If it's broken → it doesn't ship.