consistency-review

What this skill does

# 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:**

```javascript
// ❌ 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:**

```typescript
// ❌ 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:**

```bash
# 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:**

```javascript
// ❌ 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:**

```javascript
// ❌ 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:**

```javascript
// ❌ 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:**

```javascript
// ❌ 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:**

```javascript
// ❌ 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:**

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

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

### 2. Directo