Claude Development

¿Qué hace Claude Development?

Resumen

Domina la secuencia de desarrollo a nivel de tarea en Claude Code: implementa el cambio solicitado, ejecuta sus verificaciones y, si se solicita, obtén una revisión independiente de Codex antes de la entrega. Aplica tanto a solicitudes en lenguaje natural como a trabajos iniciados a través de otra skill. Se trata de una orquestación basada en instrucciones; la selección automática de skills y su finalización no son garantías impuestas por el host.

Uso

Usa /claude-development <tarea> o aplícalo a una solicitud de desarrollo autorizada de Claude, por ejemplo: Corrige este error y entrega el cambio verificado. Incluye cambios de configuración declarativos incluso si no necesitan TDD. La planificación, explicación y revisión por sí solas no autorizan ninguna implementación.

Una solicitud de implementación autoriza las correcciones locales necesarias para lograr el resultado solicitado, incluyendo la corrección acotada por Codex de defectos demostrados dentro de ese ámbito. Respeta los límites más estrictos del usuario. Los commits, pushes, publicación de PRs, aprobaciones y fusiones mantienen sus requisitos de autorización existentes. Otras skills poseen sus pasos especializados; esta skill determina cuándo termina el desarrollo.

Pasos

1. Establecer la tarea y los prerrequisitos. Lee las instrucciones del repositorio, el estado actual de Git, las fuentes relevantes y los ADRs. Identifica los requisitos, archivos permitidos, cambios existentes y el límite de verificación. Resuelve solo las incógnitas importantes con requirements-clarification. Verifica que las comprobaciones necesarias estén disponibles. Si se solicita una revisión independiente de Codex, verifica code-review-fix y su tiempo de ejecución declarado antes de esa etapa. Mantén desactivadas las puertas de revisión automática Stop; la falta de herramientas de revisión opcionales no bloquea la implementación ni la entrega ordinaria.
2. Respetar el flujo de trabajo envolvente. Para una tarea de Linear, deja que linear-start y linear-workflow gestionen la elegibilidad, la rama, el tracker y el estado del PR. Otros flujos de trabajo especializados mantienen su propia autoridad y límites. Cuando esta tarea repara un PR abierto, usa el flujo de trabajo autorizado pr-fix para la reparación y la revisión independiente; no inicies un bucle de reparación local concurrente. La implementación local ordinaria permanece aquí incluso si no se ha invocado otra skill.
3. Implementar el resultado acordado. Conserva el trabajo no relacionado. Aplica tdd para el comportamiento ejecutable propio y la validación nativa o existente para cambios declarativos. Usa las skills de dominio relevantes sin convertir cada prueba, llamada a herramienta o subtarea en una etapa de entrega separada. Registra el delta completo de la tarea y cualquier cambio excluido intencionalmente.
4. Ejecutar las comprobaciones relevantes. Indexa los nuevos archivos previstos antes de formatear, lint y typecheck. Ejecuta la barrera del repositorio adecuada al cambio real, con entorno y límites nombrados. Las comprobaciones fallidas son desarrollo no terminado, no un permiso para debilitar las aserciones. Corrige solo los fallos autorizados y mantén explícita la evidencia esencial faltante.
5. Ejecutar la revisión independiente solicitada una vez. La revisión de Codex es opcional; una solicitud de implementación por sí sola no la exige. Cuando el usuario solicita revisión y correcciones acotadas, activa code-review-fix sobre el delta local completo con requisitos, identidad del candidato y evidencia de comprobación en bruto. Suspende las escrituras de Claude mientras se ejecuta el flujo de trabajo autorizado. Una solicitud de solo revisión no autoriza correcciones y usa code-review. No reinicies ninguna de las dos secuencias dentro de una corrección delegada. Si pr-fix posee la reparación y revisión, conserva su ámbito en lugar de crear un segundo bucle.
6. Entregar el resultado observado. Informa el candidato final, el comportamiento cambiado, las disposiciones de los hallazgos, las comprobaciones reales, el entorno y los límites restantes. Una revisión solicitada faltante, desactualizada o incompleta sigue siendo un límite explícito; una revisión no solicitada no es un requisito previo para la entrega. No digas que el desarrollo está terminado solo porque se escribió código, las comprobaciones pasaron, se devolvió un hijo o se marcó la tarea como completada. Conserva cualquier punto de control de publicación y aprobación existente en el flujo de trabajo envolvente.

Advertencias

• Una solicitud simple omite las skills especializadas — la verificación puede desaparecer; este flujo de trabajo se aplica al desarrollo de Claude independientemente de cómo comenzó la tarea.
• TDD se convierte en el flujo de trabajo externo — una prueba verde termina la entrega demasiado pronto; verifica la tarea completa y realiza cualquier revisión solicitada después de que terminen la implementación y las comprobaciones.
• Cada hijo inicia la secuencia de finalización — las revisiones se repiten y el contador de pases se reinicia; solo el propietario del desarrollo externo invoca la etapa final.
• Una edición de configuración salta TDD — saltar una prueba de valor también puede saltar la revisión por error; usa validación nativa y realiza una revisión independiente cuando se solicite.
• Una reparación de PR existente obtiene un segundo bucle — escritores en competencia y veredictos divergen; conserva el propietario de pr-fix y su revisión independiente final.

Restricciones

• Nunca inicies implementación, reparación o publicación desde una solicitud de solo planificación o revisión.
• Nunca informes una revisión no realizada como completada ni exijas una revisión Codex no solicitada.
• Nunca anules los límites del usuario ni te expandas más allá del resultado solicitado y las correcciones confirmadas.
• Nunca dupliques el bucle code-review-fix o pr-fix dentro de una corrección delegada.
• Nunca actives una puerta de revisión Stop ni presentes la selección automática de skills como técnicamente forzada.
• Nunca instales tiempos de ejecución faltantes ni reemplaces evidencia faltante con un resultado que parezca exitoso.