Mnthe Hardworker Marketplace 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:

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

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

Project Vocabulary Consistency

ultrawork Example

Standard vocabulary (from CLAUDE.md):

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

Converted and distributed by TomeVault — claim your Tome and manage your conversions.