codebase-conformity

Codebase Conformity

Overview

AI assistants "innovate" when they should conform. They introduce new patterns, rename conventions, restructure layouts, and use different error handling — all in the same codebase. This skill forces the AI to read before writing, match before creating, and verify before claiming done.

Core principle: The existing codebase is the specification. Read it. Match it. Don't improve it in the same commit.

The Iron Law

EVERY NEW FILE, FUNCTION, AND FEATURE MUST CONFORM TO EXISTING CODEBASE PATTERNS. NO EXCEPTIONS. NO INNOVATIONS. NO "BETTER WAYS."

When to Use

Mandatory (always active):

• Adding a new file, component, page, route, or endpoint
• Adding a new function, hook, service, or utility
• Modifying existing code as part of a feature
• After any AI-generated code (including your own)
• Implementing any task from a plan

Recommended:

• Before reviewing code (check conformity first)
• After a refactoring (verify patterns held)
• When onboarding to an existing codebase

When NOT to Use

• Greenfield projects with no existing code (there's nothing to conform TO)
• When explicitly refactoring patterns to a NEW standard (use refactoring-safely)
• When migrating architecture (use writing-plans → executing-plans)
• When the existing pattern IS the bug (fix the pattern separately, then conform)

Anti-Shortcut Rules

YOU CANNOT:
- Write code before reading at least 3 sibling files in the same directory — you don't know the pattern yet
- Introduce a new library, utility, or abstraction that doesn't already exist in the codebase — conform, don't innovate
- Use a different naming convention than the existing files — even if you prefer it
- Use a different error handling pattern than existing code — consistency > elegance
- Use a different import style or order than existing files — match them exactly
- Use a different component structure than existing components — structure is a pattern too
- Say "this is a common best practice" to justify deviating — the codebase's practice is the only practice
- Claim conformity without side-by-side comparison — "it looks right" is not verification
- Change an existing pattern while adding a feature — one concern per commit
- Skip double verification — context window amnesia is real, verify twice