verify-quality-a

name	verify-quality-a
type	action
description	Quality verification framework — dimensions, severity levels, grading criteria
user-invocable	false

Action skill — Quality verification procedures: dimensions, severity grading, production readiness checks.

Quality Standards

Verification Dimensions

Design quality — Are abstractions earning their complexity? Dependencies pointing right? Module boundaries in the right places? Hidden coupling?

Code integrity — Is the code genuine or performative? Do tests verify real behavior? Does error handling actually handle errors?

Code cleanliness — Unnecessary defensive code? Over-engineered abstractions? Clear naming? Dead code?

Production readiness — Tests pass? No hardcoded secrets? Errors handled? Dependencies pinned?

Finding Severity

Critical (must fix) — Crashes, data loss, security vulnerabilities. Fake code that will fail in production. Missing error handling for common failure modes.

Warning (should fix) — Design issues that will cause problems at scale. Inconsistencies that will confuse future sessions. Tests that don't verify real behavior.

Suggestion (consider) — Readability improvements. Minor naming inconsistencies. Simplification opportunities.

Grading

• A: Clean, well-tested, good design. No critical or warning findings.
• B: Mostly clean. Minor warnings, no criticals.
• C: Functional but has warnings that should be addressed.
• D: Has critical issues or significant design concerns.
• F: Fake code, missing tests, or fundamental design problems.

Finding no issues is valid. Don't invent problems. Be specific — every finding needs path, line, description.

Production Readiness Checks

Every check follows: state what you're checking, run the actual command, show the output, render verdict with evidence.

• Functionality: Tests pass (run them), no skipped tests, critical paths traced
• Security: No hardcoded secrets (grep for password/secret/api_key/token), no debug endpoints, input validation present
• Stability: Errors handled not swallowed, no silent failures, appropriate logging
• Dependencies: Pinned versions, lock files present, audit for known vulnerabilities

Output Format

### [PASS|FAIL] {Check name}
COMMAND: what you ran
OUTPUT: what you saw
VERDICT: Pass/Fail — brief reason

Overall verdict: READY or NOT READY. Don't pass checks you didn't actually run.