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:
- •Code is read 10x more than it's written — Optimize for readability
- •Bugs cost 100x more to fix in production — Build in correctness from the start
- •Technical debt compounds — Pay it down immediately
- •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
anytype 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:
- •Read the requirement twice — Ensure complete understanding
- •Ask clarifying questions — Don't assume; clarify ambiguity
- •Consider the full lifecycle — Creation, updates, deletion, errors
- •Write tests mentally first — What would break this?
- •Code with intent — Every line has a purpose
- •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.