OrcaCl
UserUna brújula necesaria para perderle el miedo a trabajar "junto" a Claude Code y desarrollar con confianza, control y buenas prácticas.
Categories
Indexed Skills (12)
brain-adr
Disciplina de trabajo con el sistema brain/ (registros de decisión — ADR, INT, NOC, DEP, REF/REFX) para proyectos que usan la estructura completa. Úsala siempre que se vaya a tomar una decisión de arquitectura, una decisión sobre cómo el humano y Code trabajan juntos, documentar un hallazgo de riesgo mixto, retirar una herramienta o patrón, o registrar material de referencia (propio o de otro proyecto); al cerrar una sesión o checkpoint en un proyecto con brain/; o cuando un proyecto con estructura simple muestre señales de necesitar escalar a brain/. También aplica al crear un bug report o feature proposal hacia un sistema externo.
code-simplicity
Principios de simplicidad de código para todo desarrollo dentro de proyectos Suplemento Estrella — KISS, DRY y evitar sobreingeniería salvo que sea inevitable. Usar siempre que se esté diseñando una solución nueva, evaluando si abstraer código repetido, decidiendo entre una función directa y un patrón de diseño, o revisando si una implementación es más compleja de lo que el problema requiere. Aplica a Python, SQL, JavaScript, CSS y cualquier otro lenguaje del proyecto.
depuracion-sistematica
Disciplina de encontrar la causa raíz de un bug ANTES de intentar cualquier arreglo. Cuatro fases obligatorias — investigación, análisis de patrón, hipótesis, implementación — sin saltarse ninguna. Úsala siempre que aparezca un bug, un test que falla, comportamiento inesperado, un problema de rendimiento, o una falla de build/integración — antes de proponer o escribir un fix. Especialmente bajo presión de tiempo, cuando "un arreglo rápido" parece obvio, o cuando ya se intentaron varios fixes sin éxito.
disenar-antes-de-implementar
Disciplina de diseño colaborativo antes de escribir código — clasificar el tamaño del trabajo, entender la intención real, proponer enfoque(s), y obtener aprobación explícita del humano antes de cualquier acción de implementación. Úsala siempre que se vaya a crear una feature, construir un componente, agregar funcionalidad, o modificar comportamiento existente — antes de tocar código, antes de entrar a modo plan, y antes de invocar cualquier skill de implementación. También cuando una tarea que parecía chica revela complejidad oculta a mitad de camino.
documentation-convention
Convención de registro de cambios en la documentación del proyecto — commits de código frecuentes según avanza el trabajo, pero registro de brain/ y SPEC.md diferido hasta un checkpoint explícito (invocado por el humano) o hasta el cierre de sesión (obligatorio). Úsala siempre que estés por hacer un commit, cuando el humano diga "checkpoint" o pida cerrar la sesión, o cuando cambie la versión de cualquier plugin de Claude Code instalado en el proyecto.
frontend-conventions
Convenciones de frontend para proyectos con renderizado server-side (templates + CSS + JS) — atomicidad de archivos por componente, nomenclatura BEM, y el puente data-* para pasar datos del servidor a JavaScript sin mezclar sintaxis del motor de templates dentro de archivos .js. Úsala siempre que se esté creando o modificando un componente de UI, un archivo CSS, un archivo JavaScript, o un template que necesite pasar datos al cliente. El ejemplo de referencia usa Jinja2/Flask, pero la regla aplica a cualquier motor de templates server-side (Blade, EJS, etc.).
planificacion-por-fases
Disciplina de escribir un plan de implementación detallado y por fases ANTES de tocar código, para cualquier tarea de varios pasos. El plan documenta qué archivos toca cada tarea, el código, cómo se prueba, y deja cada tarea como una unidad chica con su propio ciclo de test. Úsala cuando ya hay un diseño o spec aprobado (viene de disenar-antes-de-implementar) y la tarea tiene varios pasos o toca varios archivos — antes de empezar a implementar.
raw-data-audit-trail
Convención de auditoría para toda tabla que persiste datos provenientes de una fuente externa (Excel, API, CSV, KML, u otro import). Úsala siempre que se esté diseñando o modificando un modelo de base de datos que reciba datos importados, al crear un serializador o endpoint de API que exponga una tabla con datos importados, o al configurar un explorador de base de datos de desarrollo (Datasette u otro). Define cuándo agregar la columna raw_data y cómo ocultarla correctamente en los puntos de acceso externos sin perder su valor de auditoría.
sequential-mode
Regla de modo de trabajo por defecto — ejecución secuencial, una tarea a la vez, CERO subagentes por defecto. Cualquier excepción requiere que Code se la pida explícitamente al humano y reciba aprobación puntual para esa tarea específica — nunca una decisión autónoma de Code. Úsala siempre que estés por considerar dividir una tarea en subagentes paralelos, cuando el usuario pida "hazlo rápido" o "en paralelo", o cuando un plugin de flujo de trabajo (como Superpowers) sugiera dispatching-parallel-agents o subagent-driven-development por defecto — incluyendo el momento exacto en que `writing-plans` presenta su menú de "Execution Handoff" o `executing-plans` recomienda subagentes al abrir. Esta skill decide si esa sugerencia aplica o se anula para este proyecto, sin importar que esté redactada como "recommended" o "REQUIRED SUB-SKILL".
spec-driven-development
Disciplina de trabajo diario con SPEC.md y la carpeta spec/ como fuente de verdad del proyecto. Úsala siempre que el usuario pida una tarea de desarrollo nueva, al iniciar cualquier sesión de trabajo (leer SPEC.md primero), al completar una tarea o breakthrough (actualizar SPEC.md y spec/ de inmediato), o cuando haya que decidir en qué archivo va cada pieza de información. También aplica cuando spec/historial.md empieza a crecer demasiado y hay que evaluar si el proyecto necesita escalar a brain/ ADR.
tdd-workflow
Disciplina de TDD estricto (red-green) con ejecución de tests QUIRÚRGICA por defecto — solo el test directamente relacionado al cambio actual. Correr una suite más amplia (módulo completo, o la suite entera) requiere preguntar al humano primero, nunca es una escalada automática de Code. Úsala siempre que se vaya a implementar una feature o corregir un bug, antes de escribir cualquier código de implementación, o al decidir qué comando de test correr después de un cambio.
tooling-roles
Tabla de roles funcionales de herramientas (gestor de paquetes, ORM+migraciones, config tipada, cliente HTTP, CLI, testing, auditoría de dependencias) con el stack Python de referencia como preset por defecto, y equivalentes conocidos en JavaScript/TypeScript y PHP. Úsala al inicializar un proyecto nuevo que no sea Python, al elegir una librería para una responsabilidad ya cubierta en otro proyecto Suplemento Estrella, o cuando falte decidir qué herramienta usar para un rol funcional específico.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.