[ ] Consistent naming style (camelCase, PascalCase, snake_case)
[ ] Descriptive names (not x, tmp, data)
[ ] Boolean variables prefixed (is, has, should, can)
[ ] Functions are verbs (get, set, create, update, delete)
[ ] Constants are UPPER_SNAKE_CASE
[ ] Private members prefixed/suffixed (_, $)
[ ] Abbreviations used consistently

// ❌ Bad: Inconsistent naming
const UserData = "john";        // PascalCase for variable
function GetUser() {}           // PascalCase for function
const is_active = true;         // snake_case
const MAX_users = 100;          // Mixed case

// ✅ Good: Consistent naming
const userName = "john";        // camelCase
function getUser() {}           // camelCase
const isActive = true;          // camelCase, boolean prefix
const MAX_USERS = 100;          // UPPER_SNAKE_CASE

[ ] Consistent file naming (kebab-case or camelCase throughout)
[ ] Component files match component name
[ ] Test files follow naming convention (*.test.*, *.spec.*)
[ ] Index files used consistently
[ ] Directory structure follows project pattern

[ ] Classes are PascalCase
[ ] Interfaces prefixed or suffixed consistently (I or Interface)
[ ] Types are PascalCase
[ ] Enums are PascalCase
[ ] Generic type parameters are single uppercase or descriptive

// ❌ Bad: Inconsistent class/type naming
class userService {}            // Should be PascalCase
interface user {}               // Should be PascalCase
type paymentStatus = string;    // Should be PascalCase
enum order_status {}            // Should be PascalCase

// ✅ Good: Consistent naming
class UserService {}
interface IUser {}              // Or just User
type PaymentStatus = 'pending' | 'complete';
enum OrderStatus { Pending, Shipped, Delivered }

[ ] Consistent indentation (2 or 4 spaces, never mixed)
[ ] Consistent quote style (single or double, not mixed)
[ ] Consistent semicolon usage (always or never)
[ ] Consistent brace style (same line or new line)
[ ] Consistent spacing around operators
[ ] Consistent line length (80, 100, 120 chars)
[ ] Consistent trailing commas
[ ] Consistent import ordering

# Use Prettier for automatic formatting
npm install --save-dev prettier

# .prettierrc
{
  "semi": true,
  "singleQuote": true,
  "tabWidth": 2,
  "trailingComma": "es5"
}

# Format all files
npx prettier --write "src/**/*.{js,ts,jsx,tsx}"

[ ] Consistent import ordering (external, internal, types)
[ ] Consistent import style (named vs default)
[ ] No unused imports
[ ] Consistent path aliases (@/, ~/, etc.)
[ ] Grouped by type (libraries, components, utils)

// ❌ Bad: Random import order
import { Button } from './Button';
import React from 'react';
import type { User } from './types';
import axios from 'axios';

// ✅ Good: Organized imports
// 1. External libraries
import React from 'react';
import axios from 'axios';

// 2. Internal components/modules
import { Button } from './Button';

// 3. Types
import type { User } from './types';

[ ] Consistent comment style (// vs /* */)
[ ] JSDoc for public APIs
[ ] Inline comments for complex logic only
[ ] No commented-out code
[ ] No TODO/FIXME without tickets
[ ] Comments explain "why", not "what"
[ ] Documentation format consistent (Markdown, JSDoc)

// ❌ Bad: Obvious comment, no context
// Loop through users
for (const user of users) {
  // Check if active
  if (user.isActive) {
    // Send email
    sendEmail(user);
  }
}

// ✅ Good: Explains why, not what
// Only notify active users to reduce spam complaints
for (const user of users) {
  if (user.isActive) {
    sendEmail(user);
  }
}

[ ] Consistent error handling (try/catch vs callbacks vs promises)
[ ] Error objects have consistent structure
[ ] Error messages follow same format
[ ] Error logging uses same method
[ ] Custom errors extend base Error class

// ❌ Bad: Inconsistent error handling
async function getUserA() {
  try {
    return await db.getUser();
  } catch (e) {
    console.error(e);
    return null;
  }
}

async function getUserB() {
  const user = await db.getUser();
  if (!user) throw new Error('Not found');
  return user;
}

// ✅ Good: Consistent error handling
async function getUser(id) {
  try {
    const user = await db.users.findById(id);
    if (!user) {
      throw new NotFoundError(`User ${id} not found`);
    }
    return user;
  } catch (error) {
    logger.error('Failed to get user', { id, error });
    throw error;
  }
}

[ ] Consistent async/await vs .then()/.catch()
[ ] Consistent Promise handling
[ ] Consistent error propagation
[ ] Consistent timeout handling

// ❌ Bad: Mixed patterns
const data1 = await fetch(url1);
fetch(url2).then(res => res.json()).then(data => process(data));

// ✅ Good: Consistent async/await
const data1 = await fetch(url1);
const response2 = await fetch(url2);
const data2 = await response2.json();

[ ] Consistent validation library (Zod, Joi, Yup)
[ ] Validation at consistent layer (routes, services, models)
[ ] Error messages follow same format
[ ] Validation schemas colocated

[ ] Consistent test structure (describe/it vs test)
[ ] Consistent assertion library
[ ] Consistent mocking approach
[ ] Test file naming consistent
[ ] Setup/teardown patterns consistent

// ❌ Bad: Inconsistent test structure
describe('UserService', () => {
  test('creates user', () => {});  // Using 'test'
});

describe('OrderService', () => {
  it('creates order', () => {});   // Using 'it'
});

// ✅ Good: Consistent structure
describe('UserService', () => {
  it('creates user', () => {});
  it('updates user', () => {});
});

describe('OrderService', () => {
  it('creates order', () => {});
  it('updates order', () => {});
});

[ ] Follows project conventions in CLAUDE.md
[ ] Adheres to defined coding standards
[ ] Uses project-specific patterns
[ ] Respects defined constraints
[ ] Matches project vocabulary

# Read project standards
Read("/path/to/project/CLAUDE.md")

# Check for violations
# - Compare code against stated standards
# - Verify pattern usage
# - Check terminology consistency

[ ] New files in correct directories
[ ] Directory structure matches project pattern
[ ] No files in wrong layers
[ ] Feature folders organized consistently

[ ] Environment variables named consistently
[ ] Configuration files follow project format
[ ] Secrets management consistent
[ ] Default values handled uniformly

# Linting
npm run lint

# Formatting check
npx prettier --check "src/**/*.{js,ts}"

# Type checking (TypeScript)
npm run type-check

# Find similar files for comparison
find src -name "*Service.ts" | head -5
find src -name "*.test.ts" | head -5

# Search for non-standard terms
grep -r "criterias\|proof\|done\|complete\|passed" src/

# Should use: criteria, evidence, resolved, PASS

# Add consistency assessment to evidence
bun "{SCRIPTS_PATH}/task-update.js" --session ${CLAUDE_SESSION_ID} --id verify \
  --add-evidence "Consistency Review: 8/10" \
  --add-evidence "- Naming conventions: ✓" \
  --add-evidence "- Style consistent: ✓" \
  --add-evidence "- Patterns followed: ✓" \
  --add-evidence "- Minor: Mixed quote style in test files"

# ESLint for linting
npm install --save-dev eslint

# Prettier for formatting
npm install --save-dev prettier

# Combine with husky for pre-commit hooks
npm install --save-dev husky lint-staged

// package.json
{
  "lint-staged": {
    "*.{js,ts,jsx,tsx}": [
      "eslint --fix",
      "prettier --write"
    ]
  }
}

{
  "extends": ["eslint:recommended"],
  "rules": {
    "camelcase": "error",
    "quotes": ["error", "single"],
    "semi": ["error", "always"]
  }
}

{
  "semi": true,
  "singleQuote": true,
  "tabWidth": 2,
  "trailingComma": "es5"
}

# Example: Block on consistency failure
bun "{SCRIPTS_PATH}/task-update.js" --session ${CLAUDE_SESSION_ID} --id verify \
  --status resolved \
  --add-evidence "VERDICT: FAIL - Consistency issues" \
  --add-evidence "Mixed naming: camelCase and snake_case in same file" \
  --add-evidence "Inconsistent error handling patterns"