Sobre el proyecto
Claude Code Workflows es una colección de plugins para Claude Code que añade un proceso de desarrollo estructurado alrededor del agente. Su objetivo declarado es la convergencia: mantener la exploración amplia del código por parte de Claude apuntada al resultado que el usuario aprobó, en lugar de dejar que hallazgos incidentales dominen un cambio.
Cómo funciona
El flujo acuerda el resultado previsto y las exclusiones antes del diseño, verifica los diseños contra el repositorio real, valida cada tarea antes del commit y, para cambios más grandes, ejecuta una revisión independiente de la implementación final. Dentro del alcance aprobado, se espera que Claude elija los detalles de implementación desde el propio código. El README aconseja usar Claude Code directamente cuando el resultado y el límite seguro de implementación ya están claros, y usar estos flujos cuando un cambio necesita acuerdo de alcance, decisiones de diseño duraderas, traspaso entre contextos o verificación independiente.
El enrutamiento depende del número de decisiones de producto y diseño, no del recuento de archivos: los cambios pequeños siguen un ciclo de tareas directo con comprobaciones enfocadas y del repositorio más una revisión de seguridad; los cambios medianos añaden un Documento de Diseño revisado (y Especificación de UI o ADR cuando sea necesario), una prueba de integración/E2E seleccionada y un Plan de Trabajo revisado; los cambios grandes con múltiples resultados de producto independientes añaden un PRD revisado. Artefactos como Especificaciones de UI, ADRs y esqueletos de pruebas aparecen solo cuando sus decisiones o límites de prueba aplican.
Instalación
Requiere una versión de Claude Code con soporte de marketplace de plugins. Añade el marketplace con /plugin marketplace add shinpr/claude-code-workflows, luego instala un plugin de flujo: dev-workflows (backend/general), dev-workflows-frontend (React/TypeScript) o dev-workflows-fullstack. El README indica que solo se debe instalar un plugin de flujo, ya que el plugin full-stack ya contiene los flujos de backend y frontend. La instalación a nivel de proyecto está soportada para equipos mediante .claude/settings.json.
Recetas y plugins
Todos los puntos de entrada usan el prefijo recipe-. Las recetas de backend/general incluyen /recipe-implement, /recipe-design, /recipe-plan, /recipe-build, /recipe-review, /recipe-quality-profile, /recipe-diagnose, /recipe-reverse-engineer, /recipe-add-integration-tests y /recipe-update-doc. El plugin de frontend añade /recipe-front-design, /recipe-front-plan, /recipe-front-build, /recipe-front-adjust y /recipe-front-review, con arquitectura de componentes React, React Testing Library y comprobaciones de TypeScript. Una receta full-stack cubre cambios que abarcan backend y frontend, usando rebanadas verticales para que la integración se ejercite antes del final.
Agentes y guías
Los plugins incluyen roles de agente especializados: roles compartidos como requirement-analyzer, prd-creator, codebase-analyzer, code-verifier, work-planner, task-decomposer, acceptance-test-generator, integration-test-reviewer, code-reviewer, document-reviewer, design-sync, investigator, verifier, solver y security-reviewer; roles de backend como technical-designer, scope-discoverer, task-executor y quality-fixer; y roles de frontend como ui-spec-designer, ui-analyzer, technical-designer-frontend, task-executor-frontend y quality-fixer-frontend. La guía integrada cubre principios de codificación, principios de prueba, enfoque de implementación, estándares de documentación, contexto de recursos externos y contexto amigable para LLM. Un plugin separado dev-skills ofrece la guía sin el flujo, y el README advierte contra instalarlo junto a un plugin de flujo debido a descripciones de habilidades duplicadas.
Contexto y artefactos
Se usan contextos nuevos para que el razonamiento de una fase no se convierta silenciosamente en la autoridad de la siguiente. Las tareas del Plan de Trabajo citan secciones del Documento de Diseño, ADR o Especificación de UI y criterios de aceptación que las restringen, y el plan se considera terminado solo cuando cada obligación necesaria del Documento de Diseño está cubierta por al menos una tarea. Los PRDs, ADRs, Especificaciones de UI y Documentos de Diseño están destinados a ser commiteados; docs/plans/ se trata como estado de trabajo efímero y el README sugiere ignorarlo con git. El README también menciona una contraparte para Codex CLI, codex-workflows, y enlaza lecturas de fondo sobre verificación de LLM y diseño de flujos de agente.
Comments
0 people shared their preference · Deer Point appears after 10 participants
Sign in to join the discussion.