AI Quality

Overview

AI Quality defines the five pillars that guide every AI-assisted development task in Datarim. Applying these pillars consistently yields 30-50% better code quality and 40-50% fewer bugs. The skill is loaded as a reference by the developer, planner, and reviewer agents at every pipeline stage.

The Five Pillars

1. Decomposition — break complex tasks into small, focused units. Max 50 lines per method, max 7-9 objects in working memory, one responsibility per function.
2. Test-First — tests are hallucination filters. Write tests before code, define "done" explicitly, cover corner cases upfront. Strict mocking: mock edges only, never fit data to tests.
3. Architecture-First — approve structure before coding. Create a skeleton with stubs, review the architecture, then implement one method at a time.
4. Focused Work — narrow context improves quality. Review one method at a time, define clear boundaries on what is out of scope, verify the AI can solve the problem before starting.
5. Context Management — right information at the right time. Gather requirements before coding, document transaction isolation, structure knowledge hierarchically, engineer prompts carefully.

A sixth practice, lint-on-the-spot, runs the project’s auto-detected linter after every TDD cycle during /dr-do and fixes findings immediately instead of deferring them to /dr-compliance.

When It's Used

AI Quality rules are mapped to specific pipeline stages. During /dr-plan, decomposition and boundary rules apply. During /dr-do, TDD and method size rules dominate. During /dr-qa, DoD verification and focused review take priority. Every agent that writes or reviews code loads this skill automatically.

Quality Checkpoint

• Is this task decomposed into small units?
• Do I have tests and a Definition of Done?
• Is the architecture approved?
• Am I focused on one thing?
• Do I have the right context?

If the answer to any question is "no," stop and address it before coding.

Advanced Patterns

• Incident-Narrative in Safety Guards — when adding safety controls (confirmation prompts, destructive-flag guards), cite the founding incident ID and quantify the cost in the runtime message. Two lines: what happens if you proceed, and why the guard exists.
• Operator-First Attribution — when a framework or vendor fails during integration, default attribution is operator error until a minimal API repro confirms otherwise. Vendor blame requires both a minimal repro failure AND docs that cannot fix it.
• Dependency Isolation — use venv (Python) or Docker for any service that installs ML libraries, runs as a systemd service, or shares a server with other services. Never use system-wide pip for production services.
• Scope Decision for Untracked Files — when a sweep touches untracked-but-load-bearing files, decide "promote now" or "defer" before staging, not during.