Code consistency and pattern adherence review skill. Naming conventions, style consistency, pattern usage, and project standards validation. Use during VERIFICATION to ensure codebase uniformity and maintainability.
Reviews code for naming conventions, style consistency, and pattern adherence across the codebase.
npx claudepluginhub mnthe/hardworker-marketplaceThis skill inherits all available tools. When active, it can use any tool Claude has access to.
Code consistency and project standards validation for ultrawork verification phase.
Systematic approach to checking:
During VERIFICATION phase:
During PLANNING phase:
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
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 |
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 }
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}"
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';
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);
}
}
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;
}
}
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();
Checklist:
[ ] Consistent validation library (Zod, Joi, Yup)
[ ] Validation at consistent layer (routes, services, models)
[ ] Error messages follow same format
[ ] Validation schemas colocated
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', () => {});
});
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
Checklist:
[ ] New files in correct directories
[ ] Directory structure matches project pattern
[ ] No files in wrong layers
[ ] Feature folders organized consistently
Checklist:
[ ] Environment variables named consistently
[ ] Configuration files follow project format
[ ] Secrets management consistent
[ ] Default values handled uniformly
| Category | Weight | Score Range |
|---|---|---|
| Naming | 30% | 0-10 |
| Style | 25% | 0-10 |
| Patterns | 25% | 0-10 |
| Documentation | 20% | 0-10 |
Overall Score = Weighted Average
# Linting
npm run lint
# Formatting check
npx prettier --check "src/**/*.{js,ts}"
# Type checking (TypeScript)
npm run type-check
Compare new code against existing patterns:
# Find similar files for comparison
find src -name "*Service.ts" | head -5
find src -name "*.test.ts" | head -5
Check:
Review all new identifiers:
| 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 |
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 |
# Search for non-standard terms
grep -r "criterias\|proof\|done\|complete\|passed" src/
# Should use: criteria, evidence, resolved, PASS
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"
# 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"
]
}
}
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"
}
Workers should:
Verifier should:
# 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"
Must-have consistency:
Quick checks:
npm run lintnpx prettier --check .When in doubt:
Activates when the user asks about AI prompts, needs prompt templates, wants to search for prompts, or mentions prompts.chat. Use for discovering, retrieving, and improving prompts.
Search, retrieve, and install Agent Skills from the prompts.chat registry using MCP tools. Use when the user asks to find skills, browse skill catalogs, install a skill for Claude, or extend Claude's capabilities with reusable AI agent components.
This skill should be used when the user wants to "create a skill", "add a skill to plugin", "write a new skill", "improve skill description", "organize skill content", or needs guidance on skill structure, progressive disclosure, or skill development best practices for Claude Code plugins.