<skill id="quality">
<purpose>
AI code is 1.7x buggier. These 5 checks catch 80% of issues.
Load this skill for any review, validation, or implementation work.
</purpose>
<reference>
Verbose research: skills/quality/reference/quality-research.md
</reference>
<big5>
<check id="1" name="input_validation" detection="grep -r 'req\.body' | grep -v 'parse\|validate\|z\.'">
Every endpoint has Zod/Pydantic schema. Parameterized queries only.
</check>
<check id="2" name="edge_cases" detection="search for array access without length check">
Handle: null, empty array, zero-length string, timeout, unicode.
</check>
<check id="3" name="error_handling" detection="grep -r 'catch.*{}'">
No empty catch. Errors logged with context. User messages generic.
Silent swallowing is the worst variant: a catch/onError that returns a masked or
generic body without first logging method/path/cause hides the root failure behind
a 500 and costs a full re-diagnosis per incident. Every handler logs the cause
before it masks. Missing config/dependency is a NAMED condition in the response
(which var, which service), never a generic error.
</check>
<check id="4" name="duplication" detection="jscpd or manual review">
Same logic in 3+ places = extract to utility.
</check>
<check id="5" name="complexity" detection="eslint complexity rule">
Functions under 30 lines. No nested ternaries > 2 levels.
</check>
<check id="6" name="gate_integrity" detection="seed a known violation and confirm the gate goes red">
A gate nobody has seen fail is not a gate. Before trusting any check you ship or run:
- Prove it red. Seed the exact violation it claims to catch, watch it fail, then unseed.
A gate that has only ever printed PASS is measuring nothing.
- The checker re-derives its evidence. A hash, a "PASS" string, a file that merely exists,
or a count supplied by the thing being checked is an assertion, not evidence. Read the
bytes, run the command, fetch the remote.
- Exit 0 with empty or blank output is a failure, not a pass. Never pipe a gate to
`tail`/`head`; the pipe reports the pager's exit code.
- A gate that stays green after you delete the code it guards is blind. Delete-and-rerun
is the cheapest mutation test there is.
- Randomness in a gate makes it a coin flip. Pin the seed or pin the input.
- Absence of a run is red, not pending.
</check>
</big5>
<quick_checks>
# 1. Missing validation
grep -r "req\.body" --include="*.ts" --include="*.js" | grep -v "parse\|validate\|z\." | head -5
# 2. Empty catch blocks
grep -r "catch.*{}" --include="*.ts" --include="*.js" | head -5
# 3. String concat in queries (SQL injection)
grep -rE "SELECT.*\$\{|INSERT.*\$\{" --include="*.ts" --include="*.js" | head -5
</quick_checks>
<data_correctness>
For any pipeline that extracts or transforms figures (financial, metrics, counts):
- Parse deterministically (a real parser, regex, typed loader). The LLM never
generates, transforms, or "fixes" numeric values.
- Units are explicit at parse time (percent vs fraction, counts vs currency);
a value never crosses unit categories through arithmetic.
- Tie-out gate: derived aggregates must reproduce the source's own totals before
any output is shown downstream. A delta between your output and the source is
assumed to be YOUR normalization bug until proven otherwise.
- Silent-empty guard: "no findings" produced from an empty parse is a failure of
the parse, not a finding.
</data_correctness>
<verdict>
Any Big 5 violation = NOT READY
Fix before commit. No exceptions.
</verdict>
<on_complete>
agentdb write-end '{"skill":"quality","big5_checked":true,"violations":N}'
</on_complete>
</skill>