The ai-quality Skill — Five Pillars That Keep AI Code From Drifting
How Datarim's ai-quality skill enforces decomposition, test-first, and architecture review at every pipeline stage to cut bugs by 40–50%.
AI assistants write code fast. The problem is that speed without structure accumulates problems: methods grow long, tests arrive after the fact, and a vague task brief leads to output that solves something slightly different from what was intended. The ai-quality skill exists to prevent that drift by applying five consistent constraints at every stage of the Datarim pipeline.
What it does
The skill organizes AI-assisted development around five pillars. The first is decomposition: every method stays under 50 lines, every function has one responsibility, and no more than seven to nine objects live in working memory at once. The second pillar is test-first — tests are written before code, because tests are the primary filter against hallucinated logic. The third is architecture-first: a skeleton with stubs gets reviewed before a single method is implemented.
The fourth pillar is focused work. Each review covers one method at a time, and the scope of a task explicitly states what is out of scope — that boundary prevents scope creep that compounds across a long session. The fifth pillar is context management: requirements are gathered before any code starts, and datarim artifacts are structured hierarchically so the right context is available at the right stage.
Beyond the pillars, the skill also provides specific patterns for cross-cutting problems. When a task changes an output format across many files, the spec-first-with-golden-fixtures pattern applies: write a canonical specification, create reference fixtures, write regression tests, then propagate. When an acceptance criterion asserts an HTTP status code, the skill requires tracing the full middleware chain before locking in a literal status — any upstream layer can short-circuit and return a different code.
One concrete example
A task adds validation to an API endpoint. A naive implementation writes the handler first, then adds tests. Under ai-quality, the sequence is reversed: first define the done criteria and corner cases, then write tests that cover the empty-body path and the oversized-payload path, then implement the handler. The method stays under 50 lines by extracting the validation logic into a separate function. When /dr-qa runs, the stage-rule mapping tells the reviewer to check the done criteria against the tests — not to re-read the entire feature.
When it loads
The skill is loaded automatically at every pipeline stage — /dr-init, /dr-plan, /dr-design, /dr-do, /dr-qa, and /dr-archive. Each stage has its own subset of the rules. The /dr-do stage enforces TDD and the 50-line limit. The /dr-qa stage checks done criteria and reviews one method at a time. The /dr-archive stage uses the skill's iterative-verification rule to confirm the process was followed, not just the output.
Read about what Datarim is for the broader context, or see how the /dr-do command puts these rules into practice at the implementation stage.