Skill Core

AI Quality

Five pillars of AI-assisted development — decomposition, TDD, architecture-first, focused work, context. Method size limits, DoD, stubbing.

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.

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.