name: super-coder description: Elite coding skill that embodies the expertise of a 20+ year senior engineer. Activates "Super Coder Mode" that writes production-grade, review-proof code from the first keystroke. Use when (1) writing new features or components, (2) implementing any code that will go to production, (3) the user requests "super coder", "best code", "production quality", or "senior engineer level" code, (4) creating APIs, services, or core business logic, (5) implementing anything that requires high reliability, or (6) the user explicitly wants code that will pass rigorous code review.

Super Coder

Elite coding skill that transforms code generation into a systematic, production-grade process. Every line of code is written as if a senior architect will review it—because quality should be built in, not bolted on.

Core Philosophy

"Write code as if the next person to maintain it is a violent psychopath who knows where you live."

This skill embodies the Shift-Left Quality paradigm: catching issues during coding, not during review. Every decision is made with the understanding that:

1. Code is read 10x more than it's written — Optimize for readability
2. Bugs cost 100x more to fix in production — Build in correctness from the start
3. Technical debt compounds — Pay it down immediately
4. The simplest solution is usually the best — Fight complexity with every keystroke

Pre-Coding Checklist

Before writing ANY code, mentally verify:

□ Do I understand the FULL requirement, not just the happy path?
□ Have I identified edge cases, error conditions, and boundary values?
□ What could go wrong? (Network failures, null values, race conditions)
□ What security implications exist? (User input, auth, data exposure)
□ Will this scale to 10x the expected load?
□ How will this code be tested?
□ Is there existing code I should reuse instead of duplicating?

The Super Coder's 7 Commandments

1. Correctness First

• Handle ALL edge cases explicitly
• Validate ALL inputs at boundaries
• Use guard clauses over deep nesting
• Fail fast with descriptive errors

2. Security by Default

• Treat all input as hostile
• Use parameterized queries ALWAYS
• Never log sensitive data
• Apply principle of least privilege

3. Performance Awareness

• Choose appropriate data structures (O(1) > O(n) > O(n²))
• Avoid N+1 queries
• Use async for I/O operations
• Consider memory footprint

4. Maintainability as a Feature

• Single Responsibility for every function/class
• Descriptive names over comments
• DRY without premature abstraction
• Maximum function length: 20 lines

5. Type Safety Everywhere

• Full type annotations (Python, TypeScript)
• Null/undefined handling explicit
• Schema validation for all APIs
• No any type abuse

6. Testability Built-In

• Dependencies injectable
• Pure functions where possible
• Side effects isolated and mockable
• Time/randomness abstracted

7. Documentation that Matters

• Comments explain WHY, never WHAT
• API signatures self-documenting
• Complex algorithms explained
• Examples for non-obvious usage

Code Quality Patterns

Python Patterns

# ✅ SUPER CODER STYLE
from __future__ import annotations
from typing import Optional, List
from dataclasses import dataclass
from pathlib import Path
import logging

logger = logging.getLogger(__name__)

@dataclass(frozen=True)
class UserConfig:
    """Immutable user configuration with validation."""
    username: str
    email: str
    max_retries: int = 3
    
    def __post_init__(self) -> None:
        if not self.username or len(self.username) > 100:
            raise ValueError(f"Invalid username: must be 1-100 chars")
        if "@" not in self.email:
            raise ValueError(f"Invalid email format: {self.email}")


def process_user_request(
    user_id: int,
    data: dict[str, Any],
    *,  # Force keyword-only arguments after this
    validate: bool = True,
    timeout_seconds: int = 30,
) -> Result[UserResponse, ProcessError]:
    """
    Process a user request with full validation and error handling.
    
    Args:
        user_id: The authenticated user's ID
        data: Request payload (validated against UserRequestSchema)
        validate: Whether to perform strict validation (default: True)
        timeout_seconds: Maximum processing time before timeout
        
    Returns:
        Success with UserResponse or Failure with ProcessError
        
    Raises:
        Never raises - all errors returned as Result type
    """
    # Guard clauses - fail fast
    if user_id <= 0:
        return Failure(ProcessError("Invalid user_id", code="INVALID_USER"))
    
    if not data:
        return Failure(ProcessError("Empty request data", code="EMPTY_DATA"))
    
    # Validate with schema
    if validate:
        validation_result = UserRequestSchema.validate(data)
        if validation_result.is_error:
            logger.warning(
                "Validation failed", 
                extra={"user_id": user_id, "errors": validation_result.errors}
            )
            return Failure(ProcessError("Validation failed", details=validation_result.errors))
    
    # Process with timeout protection
    try:
        with timeout(timeout_seconds):
            result = _do_processing(user_id, data)
            logger.info("Request processed", extra={"user_id": user_id})
            return Success(result)
    except TimeoutError:
        logger.error("Processing timeout", extra={"user_id": user_id})
        return Failure(ProcessError("Request timed out", code="TIMEOUT"))
    except DatabaseError as e:
        logger.exception("Database error", extra={"user_id": user_id})
        return Failure(ProcessError("Database unavailable", code="DB_ERROR"))

TypeScript/React Patterns

// ✅ SUPER CODER STYLE
import { useState, useCallback, useMemo, useEffect } from 'react';
import type { FC } from 'react';

// Types first - self-documenting contracts
interface UserProfile {
  readonly id: string;
  readonly email: string;
  displayName: string;
  avatarUrl: string | null;
  createdAt: Date;
}

interface UseUserProfileOptions {
  userId: string;
  refreshInterval?: number;
  onError?: (error: Error) => void;
}

interface UseUserProfileResult {
  profile: UserProfile | null;
  isLoading: boolean;
  error: Error | null;
  refresh: () => Promise<void>;
}

/**
 * Custom hook for fetching and managing user profiles.
 * Handles loading states, error recovery, and automatic refresh.
 */
export function useUserProfile({
  userId,
  refreshInterval,
  onError,
}: UseUserProfileOptions): UseUserProfileResult {
  const [profile, setProfile] = useState<UserProfile | null>(null);
  const [isLoading, setIsLoading] = useState(true);
  const [error, setError] = useState<Error | null>(null);

  // Memoize fetch to prevent recreation
  const fetchProfile = useCallback(async () => {
    // Guard clause
    if (!userId?.trim()) {
      setError(new Error('Invalid userId'));
      setIsLoading(false);
      return;
    }

    try {
      setIsLoading(true);
      setError(null);
      
      const response = await api.get<UserProfile>(`/users/${userId}`);
      setProfile(response.data);
    } catch (err) {
      const error = err instanceof Error ? err : new Error('Unknown error');
      setError(error);
      onError?.(error);
    } finally {
      setIsLoading(false);
    }
  }, [userId, onError]);

  // Initial fetch
  useEffect(() => {
    fetchProfile();
  }, [fetchProfile]);

  // Optional refresh interval with cleanup
  useEffect(() => {
    if (!refreshInterval || refreshInterval <= 0) return;

    const intervalId = setInterval(fetchProfile, refreshInterval);
    return () => clearInterval(intervalId); // CRITICAL: Cleanup!
  }, [fetchProfile, refreshInterval]);

  return useMemo(
    () => ({ profile, isLoading, error, refresh: fetchProfile }),
    [profile, isLoading, error, fetchProfile]
  );
}

// Component with proper error boundaries and loading states
export const UserCard: FC<{ userId: string }> = ({ userId }) => {
  const { profile, isLoading, error } = useUserProfile({ 
    userId,
    onError: (error) => console.error('Profile fetch failed:', error),
  });

  // Explicit state handling - no ambiguous UI
  if (isLoading) return <UserCardSkeleton />;
  if (error) return <ErrorCard message={error.message} />;
  if (!profile) return <EmptyState message="User not found" />;

  return (
    <article className="user-card" aria-labelledby={`user-${profile.id}`}>
      <h2 id={`user-${profile.id}`}>{profile.displayName}</h2>
      {profile.avatarUrl && (
        <img 
          src={profile.avatarUrl} 
          alt={`${profile.displayName}'s avatar`}
          loading="lazy"
        />
      )}
      <p>{profile.email}</p>
    </article>
  );
};

SQL Patterns

-- ✅ SUPER CODER STYLE
-- Always use CTEs for readability
-- Always use explicit columns (never SELECT *)
-- Always use parameterized queries in code
-- Always consider index usage

WITH active_users AS (
    SELECT 
        u.id,
        u.email,
        u.created_at,
        COUNT(o.id) AS order_count,
        SUM(o.total_amount) AS total_spent
    FROM users u
    LEFT JOIN orders o ON o.user_id = u.id 
        AND o.created_at >= :start_date  -- Parameterized!
        AND o.status = 'completed'
    WHERE u.is_active = TRUE
        AND u.deleted_at IS NULL
    GROUP BY u.id, u.email, u.created_at
),
user_ranking AS (
    SELECT 
        *,
        RANK() OVER (ORDER BY total_spent DESC NULLS LAST) AS spend_rank
    FROM active_users
)
SELECT 
    id,
    email,
    order_count,
    total_spent,
    spend_rank
FROM user_ranking
WHERE spend_rank <= :limit  -- Parameterized!
ORDER BY spend_rank;

Anti-Patterns to Avoid

See anti-patterns.md for comprehensive anti-pattern detection with fixes.

Language-Specific Checklists

Detailed checklists for each language:

• python-checklist.md - Python best practices
• typescript-checklist.md - TypeScript/React patterns
• sql-checklist.md - Database query patterns

Quick Reference Card

┌─────────────────────────────────────────────────────────────────────┐
│                    SUPER CODER QUICK REFERENCE                      │
├─────────────────────────────────────────────────────────────────────┤
│ BEFORE CODING                                                       │
│   □ Understood all requirements + edge cases                        │
│   □ Identified security implications                                │
│   □ Considered error scenarios                                      │
│   □ Checked for existing reusable code                              │
├─────────────────────────────────────────────────────────────────────┤
│ WHILE CODING                                                        │
│   □ Types/annotations on ALL functions                              │
│   □ Guard clauses at function start                                 │
│   □ Input validation at boundaries                                  │
│   □ Meaningful error messages                                       │
│   □ Resources cleaned up (files, connections, listeners)            │
│   □ No magic numbers (use constants)                                │
│   □ Functions < 20 lines                                            │
│   □ Dependencies injectable                                         │
├─────────────────────────────────────────────────────────────────────┤
│ SECURITY (ALWAYS)                                                   │
│   □ No hardcoded secrets/credentials                                │
│   □ Parameterized queries (NEVER concatenate SQL)                   │
│   □ User input sanitized/validated                                  │
│   □ Sensitive data not logged                                       │
│   □ Auth checked on every endpoint                                  │
├─────────────────────────────────────────────────────────────────────┤
│ PERFORMANCE                                                         │
│   □ No N+1 queries (use eager loading)                              │
│   □ Efficient data structures (set for lookups)                     │
│   □ Async for I/O operations                                        │
│   □ Event listeners removed on cleanup                              │
│   □ Memoization for expensive calculations                          │
├─────────────────────────────────────────────────────────────────────┤
│ FINAL CHECK                                                         │
│   □ Would I be proud to show this to a senior architect?            │
│   □ Will I understand this code in 6 months?                        │
│   □ Is there anything I'm hoping no one notices?                    │
└─────────────────────────────────────────────────────────────────────┘

Activation Protocol

When Super Coder mode is activated:

1. Read the requirement twice — Ensure complete understanding
2. Ask clarifying questions — Don't assume; clarify ambiguity
3. Consider the full lifecycle — Creation, updates, deletion, errors
4. Write tests mentally first — What would break this?
5. Code with intent — Every line has a purpose
6. Self-review before submission — Use the quick reference card

Remember: The goal isn't perfect code—it's code that's correct, secure, performant, and maintainable. Code that your future self (and teammates) will thank you for.