coding-guidelines
Coding Guidelines — Ejemplos y Anti-patrones
Los principios core (Simplicity First, Surgical Changes, Goal-Driven Execution) viven en ~/.claude/CLAUDE.md global, y aplican siempre.
Este skill es el deep dive: ejemplos concretos y anti-patrones para casos dudosos.
Inspirado en las observaciones de Andrej Karpathy sobre errores comunes de LLMs.
Fuente original vendorizada en references/karpathy-original.md.
Aplicacion por Lenguaje
references/typescript.md- TypeScript strict mode, testing, estructurareferences/python.md- Type hints, mypy, pytest, ruff
Ejemplos: Pensar Antes de Codear
Ejemplo 1: Feature de logging
Usuario: "Agrega logging a este servicio"
MAL (sin consultar):
import winston from 'winston';
const logger = winston.createLogger({...});
BIEN (consultar primero):
Antes de agregar logging, necesito entender:
1. Que libreria de logging prefieren? (winston, pino, console estructurado)
2. A donde van los logs? (stdout, archivo, servicio externo)
3. Que nivel de detalle? (solo errores, debug incluido)
4. Hay un formato estandar en el proyecto?
Vi que ya usan console.log en otros lugares. Prefieren mantener
consistencia o migrar todo a una libreria?
Ejemplo 2: Refactor grande
Usuario: "Este archivo esta muy largo, refactorizalo"
MAL (hacer todo):
// Extraer todo a archivos separados, agregar types, cambiar naming...
BIEN (proponer opciones con trade-offs):
El archivo tiene 450 lineas. Opciones:
A) Extraer helpers a utils/helpers.ts (reduce a ~300 lineas)
B) Separar por dominio: user.ts, auth.ts, session.ts
C) Solo extraer la funcion mas larga (validateUserSession, 80 lineas)
Cual preferis? Recomiendo C porque es el cambio minimo
que mejora legibilidad sin reestructurar todo.
Ejemplo 3: Validacion ambigua
Usuario: "Agrega validacion al form de registro"
MAL (asumir):
import { z } from 'zod';
const userSchema = z.object({...});
BIEN (preguntar scope):
Que tipo de validacion necesitas?
1. Solo frontend (mostrar errores en el form)
2. Solo backend (retornar 400 con errores)
3. Ambos (schema compartido)
Vi que el proyecto usa yup en otros forms.
Sigo con yup o preferis otra libreria?
Anti-patrones
Saltar a codear sin discutir
// Usuario: "Agrega cache"
// Inmediatamente:
import Redis from 'ioredis';
const redis = new Redis(); // Quien pidio Redis?
Problema: Se asumio Redis cuando podria ser in-memory, localStorage, o un servicio externo.
Features "por las dudas"
// Te pidieron: agregar un boton de logout
// Agregaste:
<Button onClick={logout}>Logout</Button>
<ConfirmModal /> {/* Nadie pidio confirmacion */}
<SessionTimeoutWarning /> {/* Nadie pidio esto */}
Problema: Features no solicitadas = codigo extra que mantener.
Refactorizar de paso (violacion de Surgical Changes)
// Te pidieron: corregir bug en calculateTotal()
// Se hizo:
- function calculateTotal(items) {
+ function calculateTotal(items: CartItem[]): Money { // Tipos nuevos
// ... fix del bug ...
}
+ // Tambien se renombraron variables para mayor claridad - NO
+ // Y se extrajo la logica de descuentos - NO
Problema: El PR tiene cambios mezclados, dificil de revisar. Cada linea tocada debe trazarse al pedido original.
Over-engineering (violacion de Simplicity First)
// Te pidieron: guardar preferencia de tema (dark/light)
// Se hizo:
class ThemeManager implements IThemeProvider {
private strategy: ThemeStrategy;
private observers: ThemeObserver[] = [];
constructor(config: ThemeConfig) { ... }
}
// Cuando bastaba:
localStorage.setItem('theme', 'dark');
Problema: Complejidad innecesaria. Un boolean no necesita patron Observer. Regla: "¿un senior engineer diria que esto esta overcomplicado?".
Asumir en vez de investigar
// Usuario: "No funciona el login"
// Se empezo a reescribir el auth flow completo...
// Cuando el bug era:
- if (password = storedHash) // typo: = en vez de ===
+ if (password === storedHash)
Problema: Investigar primero, preguntar que error ven, antes de reescribir.
Tarea vaga sin objetivo verificable (violacion de Goal-Driven)
Usuario: "Arregla el bug del carrito"
Claude: *empieza a tocar codigo random del carrito*
BIEN:
Para arreglar el bug necesito:
1. Reproducirlo: que pasos llevan al bug?
2. Escribir un test que falle mostrando el bug
3. Hacerlo pasar con el fix minimo
4. Verificar que el resto de tests siguen verdes
Podes darme los pasos de reproduccion?
More from testacode/llm-toolkit
claude-md-writer
Escribe y mejora archivos CLAUDE.md siguiendo best practices de Anthropic. Este skill se activa cuando el usuario dice "crear CLAUDE.md", "mejorar CLAUDE.md", "actualizar CLAUDE.md", "revisar CLAUDE.md", "escribir instrucciones del proyecto", "create CLAUDE.md", "improve CLAUDE.md", "review CLAUDE.md", "write project instructions", "optimize docs for Claude", "auditar CLAUDE.md", "audit CLAUDE.md", "limpiar CLAUDE.md", "dead weight", o configura un nuevo repositorio.
53doc-writer
Este skill se usa para crear documentos tecnicos organizados en /docs (specs, planes de implementacion, ADRs, documentacion de referencia). Se activa cuando el usuario dice "crear documento", "escribir spec", "documentar esto", "creame una spec", "escribime documentacion", "hacer documentacion", "write a spec", "create documentation", "write an ADR", o quiere agregar documentacion tecnica al proyecto.
44llms-txt-generator
This skill generates llms.txt documentation optimized for AI/LLM consumption. It should be used when the user says "crear llms.txt", "generate llms.txt", "documentar para AI", "document for AI", "crear documentacion para LLMs", "generate docs for LLMs", "make repo readable for Claude", or wants to create structured machine-readable documentation following the llms.txt standard.
40doc-organizer
Este skill se usa cuando el usuario pide "organizar docs", "ordenar documentacion", "mover documentos a carpetas", "categorizar archivos md", "reorganizar documentacion", o cuando hay archivos .md sueltos en docs/ que necesitan ser movidos a subcarpetas tematicas. Organiza y categoriza documentos tecnicos en la estructura correcta del proyecto.
28feature-planner
Planifica features con entrevista estructurada y crea tareas. Este skill se activa cuando el usuario dice "quiero agregar", "planificar feature", "nueva funcionalidad", "implementar esto", "crear plan", "planificar antes de codear", "disenar feature", "como deberia implementar esto", "pensar la arquitectura", o quiere alinear antes de escribir codigo.
27nextjs-project-starter
Creates Next.js projects with a configurable stack (Mantine, Supabase, Zustand, Zod). This skill should be used when the user says "create a Next.js project", "new web project", "bootstrap fullstack app", "start new app", "crear proyecto Next.js", "nuevo proyecto web", "empezar app fullstack", or wants to scaffold a new personal project from scratch.
25