cstrlcs/skills

Developer

Entrega el comportamiento solicitado con el cambio coherente más pequeño que se ajuste al proyecto.

Entender

Establece el comportamiento esperado y la ruta de llamada afectada antes de editar. Para errores, reproduce la falla antes de corregirla cuando sea práctico.

Lee las referencias cuando su rama aplique:

• Tareas grandes con flujos de trabajo de implementación independientes: sigue delegación cuando haya subagentes disponibles; mantén las tareas pequeñas o estrechamente acopladas con el agente principal.
• Escribir o cambiar pruebas: lee pruebas primero; sigue su flujo de trabajo primero-pruebas cuando el usuario solicite desarrollo guiado por pruebas.
• Causa no clara, corrección fallida, error intermitente o regresión de rendimiento: sigue depuración, estableciendo su bucle de retroalimentación antes de formar hipótesis.
• Construir o cambiar una interfaz de usuario (páginas, pantallas, marcado, estilos, texto de interfaz, manejo de enfoque o entrada): lee frontend y UI antes de escribirla, luego los archivos de la rama que enlaza.
• APIs, persistencia, migraciones, eventos, flujos de trabajo distribuidos, trabajo en segundo plano, integraciones o cambios en tiempo de ejecución: servicios y datos.

Implementar

• Usa cláusulas guarda: maneja cada caso de salida primero con un retorno temprano o un lanzamiento de excepción, luego escribe la ruta principal sin sangría. Aplica esto incluso cuando la ruta principal sea una sola sentencia, para que cada función se lea de la misma manera: las condiciones que la detienen al principio, el trabajo debajo. Un ternario o else que elige entre resultados es la forma que se debe reemplazar.
• Escribe una expresión de un solo uso en línea en su punto de llamada. Extrae una función nombrada solo cuando se reutiliza, envuelve lógica demasiado larga para leer en el lugar, o se prueba por sí misma, porque un envoltorio de una línea envía al lector a otro lado para aprender lo que la expresión ya dice. Agrega abstracciones solo para comportamiento compartido existente, un límite real o una necesidad de prueba demostrada.
• Nombra un valor según el parámetro o propiedad que llena cuando ese nombre aún lo describe, y pásalo con notación abreviada: const base = … luego { base }, no const projectsBase = … luego base: projectsBase. Agrega un calificador solo para información que el código circundante no proporciona, como distinguir dos valores en el mismo ámbito, porque un alias obliga al lector a asignar dos nombres a una sola cosa.
• Estas reglas de estilo rigen las líneas que escribes. Deja el código circundante y sus comentarios existentes como están a menos que tu cambio los haga incorrectos, porque reestilizar código no tocado entierra el cambio en el diff.
• Valida la entrada no confiable en su límite y confía en ella más allá de ese punto; maneja errores solo donde pueden ocurrir y un invocador puede actuar sobre ellos, preservando el contexto del error y la limpieza.
• Cuando un cambio necesite una nueva dependencia, confirma el paquete exacto en su registro (nombre, editor, antigüedad, scripts de instalación) y fíjalo a través del archivo de bloqueo, porque los agentes son propensos a nombres de paquetes alucinados y con typo-squatting.
• Actualiza los contratos afectados, ejemplos de configuración y documentación.

Verificar y entregar

Ejecuta las comprobaciones relevantes del proyecto: formato, lint, tipos, pruebas y compilación. Antes de finalizar, confirma que cada línea cambiada se remonta a la solicitud o a una expansión de alcance declarada. Para criterios de aceptación explícitos, mapea cada uno a la verificación que demuestra que se cumple; pasar comprobaciones generales por sí solas no establece la aceptación. Termina cuando el comportamiento esté verificado, o indica exactamente qué queda sin verificar y por qué.

Informa el comportamiento resultante, las interpretaciones que elegiste cuando la solicitud era ambigua, cualquier expansión de alcance y por qué, las comprobaciones que ejecutaste y las limitaciones materiales.