Back to skills
SKILL.md
Coding Standards
ASecurityUniversal 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
Works with
Security analysis
100/100Pro scans all 2 files and shows the line behind each finding
npx -y skills add SkyyRoseLLC/DevSkyy --skill coding-standards --agent claude-codeAre you the author of Coding Standards?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/skyyrosellc-coding-standards)---
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.md
- agents/openai.yaml
Attribution
Comments
Loading comments…