consistency-review

Consistency Review

Code consistency and project standards validation for ultrawork verification phase.

What This Skill Provides

Systematic approach to checking:

• Naming conventions across the codebase
• Code style consistency
• Pattern adherence and repetition
• Project-specific standards
• Documentation consistency

When to Use This Skill

During VERIFICATION phase:

• After workers complete tasks
• Before marking tasks as complete
• When multiple workers contribute to same feature
• Before final approval

During PLANNING phase:

• Validating design document format
• Ensuring task naming consistency
• Checking for adherence to project patterns

Naming Conventions

1. Variable and Function Names

Checklist:

[ ] 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

Examples:

// ❌ 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

2. File and Directory Names

Checklist:

[ ] 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

Common Patterns:

Language/Framework	Convention	Example
JavaScript/Node	kebab-case	user-service.js
React Components	PascalCase	UserProfile.jsx
TypeScript	camelCase or kebab-case	userService.ts
Tests	Same as source + suffix	user-service.test.js

3. Class and Type Names

Checklist:

[ ] 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

Examples:

// ❌ 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 }

Code Style Consistency

1. Formatting

Checklist:

[ ] 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

Tool Integration:

# 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}"

2. Import Statements

Checklist:

[ ] 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)

Examples:

// ❌ 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';

3. Comments and Documentation

Checklist:

[ ] 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)

Examples:

// ❌ 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);
  }
}

Pattern Adherence

1. Error Handling Patterns

Checklist:

[ ] 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

Examples:

// ❌ 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;
  }
}

2. Async Patterns

Checklist:

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

Examples:

// ❌ 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();

3. Data Validation Patterns

Checklist:

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

4. Testing Patterns

Checklist:

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

Examples:

// ❌ 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', () => {});
});

Project-Specific Standards

1. CLAUDE.md Adherence

Checklist:

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

How to Check:

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

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

2. Directory Structure

Checklist:

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

3. Configuration Patterns

Checklist:

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

Consistency Scoring

Category Weights

Category	Weight	Score Range
Naming	30%	0-10
Style	25%	0-10
Patterns	25%	0-10
Documentation	20%	0-10

Overall Score = Weighted Average

• 9-10: Excellent consistency, matches project standards
• 7-8: Good consistency, minor deviations
• 5-6: Fair consistency, notable inconsistencies
• 0-4: Poor consistency, major refactoring needed

Review Process

Step 1: Automated Checks

# Linting
npm run lint

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

# Type checking (TypeScript)
npm run type-check

Step 2: Pattern Analysis

Compare new code against existing patterns:

• Find similar components
• Check if patterns are replicated
• Verify naming matches conventions
• Ensure structure aligns

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

Step 3: Documentation Review

Check:

• README updated if needed
• API docs consistent with changes
• Comments follow project style
• CHANGELOG updated

Step 4: Naming Audit

Review all new identifiers:

• Variables follow convention
• Functions follow convention
• Classes follow convention
• Files follow convention

Common Inconsistencies

Inconsistency	Impact	Fix
Mixed naming styles	Confusion, hard to search	Choose one style, apply everywhere
Inconsistent imports	Hard to read	Enforce import ordering
Mixed error handling	Unpredictable behavior	Standardize error pattern
Different test styles	Maintainability issues	Pick one test structure
Varied formatting	Merge conflicts	Use Prettier/ESLint
Mixed quotes	Visual noise	Configure auto-formatter

Project Vocabulary Consistency

ultrawork Example

Standard vocabulary (from CLAUDE.md):

Use ✅	Avoid ❌
evidence	proof, confirmation
criterion (singular)	criteria (singular)
criteria (plural)	criterias, criterions
resolved	complete, done, closed
PASS / FAIL	passed / failed
exit code 0	return code 0, status 0

Checking Vocabulary

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

# Should use: criteria, evidence, resolved, PASS

Evidence Collection

When reviewing consistency:

# 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"

Tools and Automation

Linters and Formatters

# 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

Pre-commit Hooks

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

Configuration Files

ESLint (.eslintrc.json):

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

Prettier (.prettierrc):

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

Integration with Ultrawork

During Task Execution

Workers should:

• Follow existing patterns
• Match naming conventions
• Use consistent style
• Check project CLAUDE.md

During Verification

Verifier should:

• Check consistency score
• Identify deviations
• Suggest corrections
• Block if major inconsistencies

# 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"

Quick Reference

Must-have consistency:

• Single naming convention throughout
• Consistent code formatting (use Prettier)
• Uniform error handling pattern
• Consistent test structure
• Follow project CLAUDE.md standards

Quick checks:

1. Run linter: npm run lint
2. Check formatting: npx prettier --check .
3. Compare to existing similar files
4. Verify project vocabulary usage
5. Check directory structure alignment

When in doubt:

• Look at existing code for patterns
• Check project CLAUDE.md
• Ask for clarification
• Prefer consistency over personal preference