Skip to content
Back to skills

Coding Standards

ASecurity

Universal coding standards, best practices, and patterns for TypeScript, JavaScript, React, and Node.js development. Use when writing or reviewing TS/JS/React/Node code, setting up ESLint/Prettier/tsc tooling, or enforcing naming, immutability, error-handling, and structural conventions. Do NOT use for Python (python-patterns), Go (golang-patterns), or WordPress theme PHP (skyyrose-wp-platform owns phpcs and the .min build).

  • 3 stars
  • 0 votes
  • 0 copies
  • 0 views
  • Added September 11, 2026
developmentjavascripttypescriptpythongojavaphpbashreactnextjsnode

Works with

  • cli
  • api

Security analysis

A100/100

Pro scans all 2 files and shows the line behind each finding

Scanned September 11, 2026

npx -y skills add SkyyRoseLLC/DevSkyy --skill coding-standards --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Coding Standards?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Coding Standards
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/skyyrosellc-coding-standards/badge)](https://www.skillsdirectory.com/skills/skyyrosellc-coding-standards)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: coding-standards
description: Universal coding standards, best practices, and patterns for TypeScript, JavaScript, React, and Node.js development. Use when writing or reviewing TS/JS/React/Node code, setting up ESLint/Prettier/tsc tooling, or enforcing naming, immutability, error-handling, and structural conventions. Do NOT use for Python (python-patterns), Go (golang-patterns), or WordPress theme PHP (skyyrose-wp-platform owns phpcs and the .min build).
origin: ECC
---

# Coding Standards & Best Practices

Universal coding standards applicable across all projects.

## When to use

- Starting a new project or module
- Reviewing code for quality and maintainability
- Refactoring existing code to follow conventions
- Enforcing naming, formatting, or structural consistency
- Setting up linting, formatting, or type-checking rules
- Onboarding new contributors to coding conventions

**When NOT to use:**

- Python code — `python-patterns` owns PEP 8, type hints, and Pythonic idioms
- Go code — `golang-patterns` owns Go conventions
- WordPress theme PHP — `skyyrose-wp-platform` owns phpcs, escaping/nonce rules, and the `.min` build
- Repo-wide policy (STOP-AND-SHOW, deploy gates, git discipline) — that lives in `CLAUDE.md`, not here

## Inputs

Required before applying any standard:

- **The target files, read this session.** Never grade or refactor code you have not opened — apply standards to what the file actually contains, not what you assume it contains.
- **The owning workspace's lint/type config.** This repo has two separate TS workspaces:
  - `frontend/` — Next.js dashboard: `npm run lint` (`eslint .`), `npm run type-check` (`tsc --noEmit`)
  - repo root — `npm run lint` (`eslint src/**/*.{ts,tsx,js,jsx}`), `npm run type-check` (`tsc --project config/typescript/tsconfig.json --noEmit`)
- **Installed dependencies for that workspace.** If `node_modules/.bin/eslint` is absent there, the gate cannot execute — stop and install first. Do not proceed on an unrunnable gate and report it clean (fail-open, bug-230).

If any input is absent: stop and name what's missing. Never proceed with a guessed config or an unread file.

## Procedure

1. Read the code you are about to write against or review (`Read`/`Grep`) — quote `file:line` for every finding.
2. Identify the owning workspace (`frontend/` vs root `src/`) so the right ESLint/tsc config judges the code. Never mix `frontend/node_modules` with root.
3. Apply the standards in this file in order: naming → immutability → error handling → type safety → structure → tests.
4. Grep the diff for banned patterns before running tools: `: any`, direct mutation of shared state (`obj.key =`, `.push(`), empty `catch` blocks, magic numbers.
5. Run the owning workspace's lint and type-check (see Verification). Fix the cause of each finding — never silence it with `eslint-disable` or `@ts-ignore` to get green.
6. Report findings with `file:line` and severity. Violations in code you did not touch are flagged, not fixed unasked (surgical-changes rule).

## Verification

Run the owning workspace's own gates — these are the real scripts in this repo's `package.json` files `[repo]`:

```bash
cd frontend && npm run lint          # frontend workspace: eslint .
cd frontend && npm run type-check    # frontend workspace: tsc --noEmit
npm run lint                         # root workspace: eslint src/**/*.{ts,tsx,js,jsx}
npm run type-check                   # root workspace: tsc --project config/typescript/tsconfig.json --noEmit
grep -n ": any" <changed .ts/.tsx files>   # diff-scoped hard gate, blocking even when eslint exits 0
```

- **PASS (lint):** exits 0. Observed 2026-07-29: `cd frontend && npm run lint` exits 0 in this worktree — existing `no-explicit-any` / `no-unused-vars` findings are warning-severity, so exit 0 does NOT mean zero violations. `[repro]`
- **PASS (type-check):** exits 0 with no diagnostics. `[test]`
- **PASS (diff grep):** zero matches on lines you added. `[repo]`
- A gate that dies (missing binary, config error, OOM) is an artifact, not a pass — fix the environment and re-run; never read an errored run as clean (bug-230).

## Worked example

Real invocation in this repo, 2026-07-29 — grepping a workspace lib against the Type Safety standard:

```bash
grep -rn ": any" frontend/lib/vercel --include="*.ts" | head -5
```

Observed output:

```
frontend/lib/vercel/deployment-manager.ts:26:  aliasError?: any
frontend/lib/vercel/deployment-manager.ts:34:    info?: any
frontend/lib/vercel/deployment-manager.ts:93:    const body: any = {
frontend/lib/vercel/deployment-manager.ts:177:    const body: any = {
frontend/lib/vercel/deployment-manager.ts:208:    const params: any = { ...options }
```

Five violations of the Type Safety standard (`any` in API payload shapes) `[repro]`. The same day, `cd frontend && npm run lint` exited 0 while reporting `@typescript-eslint/no-explicit-any` across 41+ files — the rule is warning-severity in this config, which is exactly why the diff-scoped grep is the blocking check for new code. The correct fix is a typed interface for the Vercel deployment payloads, not an `eslint-disable`.

## Failure modes

| Failure | What it looks like | Rule |
|---|---|---|
| Silencing instead of fixing | `eslint-disable-next-line`, `@ts-ignore`, `as any` added to get green | Same defect as weakening a test to pass it — fix the cause |
| Warning-severity lulling | lint exits 0, so "zero violations" gets claimed | Exit 0 ≠ clean (observed above) — grep the diff for banned patterns |
| Gate dies, read as pass | eslint crashes on a missing binary/config and the empty output is treated as clean | Fail-open (bug-230, ×6) — a gate that dies is not a gate that passed |
| Wrong workspace | root ESLint config judging `frontend/` code, or mixed `node_modules` trees | Two separate workspaces — never mix (`CLAUDE.md` §5) |
| Standards applied to unread code | findings without `file:line`, refactors of assumed content | If you haven't read it, you don't know it |
| Cross-language leakage | these TS/React rules applied to Python or theme PHP | Route to `python-patterns` / `skyyrose-wp-platform` instead |

## Code Quality Principles

### 1. Readability First
- Code is read more than written
- Clear variable and function names
- Self-documenting code preferred over comments
- Consistent formatting

### 2. KISS (Keep It Simple, Stupid)
- Simplest solution that works
- Avoid over-engineering
- No premature optimization
- Easy to understand > clever code

### 3. DRY (Don't Repeat Yourself)
- Extract common logic into functions
- Create reusable components
- Share utilities across modules
- Avoid copy-paste programming

### 4. YAGNI (You Aren't Gonna Need It)
- Don't build features before they're needed
- Avoid speculative generality
- Add complexity only when required
- Start simple, refactor when needed

## TypeScript/JavaScript Standards

### Variable Naming

```typescript
// ✅ GOOD: Descriptive names
const marketSearchQuery = 'election'
const isUserAuthenticated = true
const totalRevenue = 1000

// ❌ BAD: Unclear names
const q = 'election'
const flag = true
const x = 1000
```

### Function Naming

```typescript
// ✅ GOOD: Verb-noun pattern
async function fetchMarketData(marketId: string) { }
function calculateSimilarity(a: number[], b: number[]) { }
function isValidEmail(email: string): boolean { }

// ❌ BAD: Unclear or noun-only
async function market(id: string) { }
function similarity(a, b) { }
function email(e) { }
```

### Immutability Pattern (CRITICAL)

```typescript
// ✅ ALWAYS use spread operator
const updatedUser = {
  ...user,
  name: 'New Name'
}

const updatedArray = [...items, newItem]

// ❌ NEVER mutate directly
user.name = 'New Name'  // BAD
items.push(newItem)     // BAD
```

### Error Handling

```typescript
// ✅ GOOD: Comprehensive error handling
async function fetchData(url: string) {
  try {
    const response = await fetch(url)

    if (!response.ok) {
      throw new Error(`HTTP ${response.status}: ${response.statusText}`)
    }

    return await response.json()
  } catch (error) {
    console.error('Fetch failed:', error)
    throw new Error('Failed to fetch data')
  }
}

// ❌ BAD: No error handling
async function fetchData(url) {
  const response = await fetch(url)
  return response.json()
}
```

### Async/Await Best Practices

```typescript
// ✅ GOOD: Parallel execution when possible
const [users, markets, stats] = await Promise.all([
  fetchUsers(),
  fetchMarkets(),
  fetchStats()
])

// ❌ BAD: Sequential when unnecessary
const users = await fetchUsers()
const markets = await fetchMarkets()
const stats = await fetchStats()
```

### Type Safety

```typescript
// ✅ GOOD: Proper types
interface Market {
  id: string
  name: string
  status: 'active' | 'resolved' | 'closed'
  created_at: Date
}

function getMarket(id: string): Promise<Market> {
  // Implementation
}

// ❌ BAD: Using 'any'
function getMarket(id: any): Promise<any> {
  // Implementation
}
```

## React Best Practices

### Component Structure

```typescript
// ✅ GOOD: Functional component with types
interface ButtonProps {
  children: React.ReactNode
  onClick: () => void
  disabled?: boolean
  variant?: 'primary' | 'secondary'
}

export function Button({
  children,
  onClick,
  disabled = false,
  variant = 'primary'
}: ButtonProps) {
  return (
    <button
      onClick={onClick}
      disabled={disabled}
      className={`btn btn-${variant}`}
    >
      {children}
    </button>
  )
}

// ❌ BAD: No types, unclear structure
export function Button(props) {
  return <button onClick={props.onClick}>{props.children}</button>
}
```

### Custom Hooks

```typescript
// ✅ GOOD: Reusable custom hook
export function useDebounce<T>(value: T, delay: number): T {
  const [debouncedValue, setDebouncedValue] = useState<T>(value)

  useEffect(() => {
    const handler = setTimeout(() => {
      setDebouncedValue(value)
    }, delay)

    return () => clearTimeout(handler)
  }, [value, delay])

  return debouncedValue
}

// Usage
const debouncedQuery = useDebounce(searchQuery, 500)
```

### State Management

```typescript
// ✅ GOOD: Proper state updates
const [count, setCount] = useState(0)

// Functional update for state based on previous state
setCount(prev => prev + 1)

// ❌ BAD: Direct state reference
setCount(count + 1)  // Can be stale in async scenarios
```

### Conditional Rendering

```typescript
// ✅ GOOD: Clear conditional rendering
{isLoading && <Spinner />}
{error && <ErrorMessage error={error} />}
{data && <DataDisplay data={data} />}

// ❌ BAD: Ternary hell
{isLoading ? <Spinner /> : error ? <ErrorMessage error={error} /> : data ? <DataDisplay data={data} /> : null}
```

## API Design Standards

### REST API Conventions

```
GET    /api/markets              # List all markets
GET    /api/markets/:id          # Get specific market
POST   /api/markets              # Create new market
PUT    /api/markets/:id          # Update market (full)
PATCH  /api/markets/:id          # Update market (partial)
DELETE /api/markets/:id          # Delete market

# Query parameters for filtering
GET /api/markets?status=active&limit=10&offset=0
```

### Response Format

```typescript
// ✅ GOOD: Consistent response structure
interface ApiResponse<T> {
  success: boolean
  data?: T
  error?: string
  meta?: {
    total: number
    page: number
    limit: number
  }
}

// Success response
return NextResponse.json({
  success: true,
  data: markets,
  meta: { total: 100, page: 1, limit: 10 }
})

// Error response
return NextResponse.json({
  success: false,
  error: 'Invalid request'
}, { status: 400 })
```

### Input Validation

```typescript
import { z } from 'zod'

// ✅ GOOD: Schema validation
const CreateMarketSchema = z.object({
  name: z.string().min(1).max(200),
  description: z.string().min(1).max(2000),
  endDate: z.string().datetime(),
  categories: z.array(z.string()).min(1)
})

export async function POST(request: Request) {
  const body = await request.json()

  try {
    const validated = CreateMarketSchema.parse(body)
    // Proceed with validated data
  } catch (error) {
    if (error instanceof z.ZodError) {
      return NextResponse.json({
        success: false,
        error: 'Validation failed',
        details: error.errors
      }, { status: 400 })
    }
  }
}
```

## File Organization

### Project Structure

```
src/
├── app/                    # Next.js App Router
│   ├── api/               # API routes
│   ├── markets/           # Market pages
│   └── (auth)/           # Auth pages (route groups)
├── components/            # React components
│   ├── ui/               # Generic UI components
│   ├── forms/            # Form components
│   └── layouts/          # Layout components
├── hooks/                # Custom React hooks
├── lib/                  # Utilities and configs
│   ├── api/             # API clients
│   ├── utils/           # Helper functions
│   └── constants/       # Constants
├── types/                # TypeScript types
└── styles/              # Global styles
```

### File Naming

```
components/Button.tsx          # PascalCase for components
hooks/useAuth.ts              # camelCase with 'use' prefix
lib/formatDate.ts             # camelCase for utilities
types/market.types.ts         # camelCase with .types suffix
```

## Comments & Documentation

### When to Comment

```typescript
// ✅ GOOD: Explain WHY, not WHAT
// Use exponential backoff to avoid overwhelming the API during outages
const delay = Math.min(1000 * Math.pow(2, retryCount), 30000)

// Deliberately using mutation here for performance with large arrays
items.push(newItem)

// ❌ BAD: Stating the obvious
// Increment counter by 1
count++

// Set name to user's name
name = user.name
```

### JSDoc for Public APIs

```typescript
/**
 * Searches markets using semantic similarity.
 *
 * @param query - Natural language search query
 * @param limit - Maximum number of results (default: 10)
 * @returns Array of markets sorted by similarity score
 * @throws {Error} If OpenAI API fails or Redis unavailable
 *
 * @example
 * ```typescript
 * const results = await searchMarkets('election', 5)
 * console.log(results[0].name) // "Trump vs Biden"
 * ```
 */
export async function searchMarkets(
  query: string,
  limit: number = 10
): Promise<Market[]> {
  // Implementation
}
```

## Performance Best Practices

### Memoization

```typescript
import { useMemo, useCallback } from 'react'

// ✅ GOOD: Memoize expensive computations
const sortedMarkets = useMemo(() => {
  return markets.sort((a, b) => b.volume - a.volume)
}, [markets])

// ✅ GOOD: Memoize callbacks
const handleSearch = useCallback((query: string) => {
  setSearchQuery(query)
}, [])
```

### Lazy Loading

```typescript
import { lazy, Suspense } from 'react'

// ✅ GOOD: Lazy load heavy components
const HeavyChart = lazy(() => import('./HeavyChart'))

export function Dashboard() {
  return (
    <Suspense fallback={<Spinner />}>
      <HeavyChart />
    </Suspense>
  )
}
```

### Database Queries

```typescript
// ✅ GOOD: Select only needed columns
const { data } = await supabase
  .from('markets')
  .select('id, name, status')
  .limit(10)

// ❌ BAD: Select everything
const { data } = await supabase
  .from('markets')
  .select('*')
```

## Testing Standards

### Test Structure (AAA Pattern)

```typescript
test('calculates similarity correctly', () => {
  // Arrange
  const vector1 = [1, 0, 0]
  const vector2 = [0, 1, 0]

  // Act
  const similarity = calculateCosineSimilarity(vector1, vector2)

  // Assert
  expect(similarity).toBe(0)
})
```

### Test Naming

```typescript
// ✅ GOOD: Descriptive test names
test('returns empty array when no markets match query', () => { })
test('throws error when OpenAI API key is missing', () => { })
test('falls back to substring search when Redis unavailable', () => { })

// ❌ BAD: Vague test names
test('works', () => { })
test('test search', () => { })
```

## Code Smell Detection

Watch for these anti-patterns:

### 1. Long Functions
```typescript
// ❌ BAD: Function > 50 lines
function processMarketData() {
  // 100 lines of code
}

// ✅ GOOD: Split into smaller functions
function processMarketData() {
  const validated = validateData()
  const transformed = transformData(validated)
  return saveData(transformed)
}
```

### 2. Deep Nesting
```typescript
// ❌ BAD: 5+ levels of nesting
if (user) {
  if (user.isAdmin) {
    if (market) {
      if (market.isActive) {
        if (hasPermission) {
          // Do something
        }
      }
    }
  }
}

// ✅ GOOD: Early returns
if (!user) return
if (!user.isAdmin) return
if (!market) return
if (!market.isActive) return
if (!hasPermission) return

// Do something
```

### 3. Magic Numbers
```typescript
// ❌ BAD: Unexplained numbers
if (retryCount > 3) { }
setTimeout(callback, 500)

// ✅ GOOD: Named constants
const MAX_RETRIES = 3
const DEBOUNCE_DELAY_MS = 500

if (retryCount > MAX_RETRIES) { }
setTimeout(callback, DEBOUNCE_DELAY_MS)
```

**Remember**: Code quality is not negotiable. Clear, maintainable code enables rapid development and confident refactoring.

Files in this skill

  • SKILL.md16.9 KB
  • agents/openai.yaml261 B

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…