
Cc Skill Coding Standards
Give your coding agent consistent TypeScript, JavaScript, React, and Node naming and design principles on every change.
Overview
cc-skill-coding-standards is a journey-wide agent skill that enforces universal TypeScript, JavaScript, React, and Node readability and design principles—usable whenever a solo builder needs consistent code quality befor
Install
npx skills add https://github.com/sickn33/antigravity-awesome-skills --skill cc-skill-coding-standardsWhat is this skill?
- Four code-quality pillars: Readability First, KISS, DRY, and YAGNI with explicit anti-patterns
- TypeScript/JavaScript naming rules with good vs bad examples for variables and functions
- Verb-noun function naming and descriptive boolean prefixes (is/has/can)
- Universal standards meant to apply across all projects, not one framework fork
- Community antigravity skill tagged for cross-stack agent sessions
- Four documented code-quality principles: Readability, KISS, DRY, YAGNI
Adoption & trust: 478 installs on skills.sh; 40.1k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Agent-generated TS/JS drifts into unclear names, over-engineering, and copy-paste logic because each chat starts without shared engineering principles.
Who is it for?
Solo builders using Claude Code, Cursor, or Codex across multiple JS/TS repos who want one lightweight standards skill loaded in every session.
Skip if: Teams that already enforce the same rules via strict ESLint/BIOME configs only and do not want overlapping agent guidance, or pure non-JS stacks with no TS/JS surface.
When should I use this skill?
Universal coding standards, best practices, and patterns for TypeScript, JavaScript, React, and Node.js development.
What do I get? / Deliverables
New and edited code follows shared KISS, DRY, YAGNI, and naming conventions so reviews are faster and refactors stay small.
- Code edits that follow documented naming and simplicity rules
- Reduced duplicate logic via extracted helpers or components
Recommended Skills
Journey fit
Useful at every journey phase - explore requirements and options before committing to a direction.
Where it fits
Spike a landing-page script without building a premature abstraction layer thanks to explicit YAGNI guidance.
Implement React components with is/has/can boolean names and verb-noun async fetch helpers.
Ask the agent to re-read changed files against DRY and readability rules before you merge.
Keep small Node content pipelines maintainable with shared utility extraction instead of copy-paste.
Refactor a hotfix branch with KISS so production patches stay easy to read under pressure.
How it compares
Journey-wide prose standards for the agent—not a formatter config or a single-framework component library skill.
Common Questions / FAQ
Who is cc-skill-coding-standards for?
Indie and solo developers shipping React or Node products who want agents to default to readable, simple code instead of one-off clever solutions.
When should I use cc-skill-coding-standards?
Before implementing features in Build, when cleaning up tech debt in Operate/iterate, during Ship review on a PR, or at Validate prototype spikes when you still want sane naming and YAGNI guardrails.
Is cc-skill-coding-standards safe to install?
It is documentation-only coding guidance with community source metadata; check the Security Audits panel on this Prism page and your org policy before auto-loading third-party skills.
SKILL.md
READMESKILL.md - Cc Skill Coding Standards
# Coding Standards & Best Practices Universal coding standards applicable across all projects. ## 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) us