claude-code-workflows

Claude Code Workflows é uma coleção de plugins para o Claude Code que adiciona um processo de desenvolvimento estruturado em torno do agente. Seu objetivo declarado é a convergência: manter a ampla exploração do código pelo Claude direcionada ao resultado aprovado pelo usuário, em vez de deixar descobertas incidentais dominarem uma mudança. Como funciona O fluxo acorda o resultado pretendido e as exclusões antes do design, verifica os designs contra o repositório real, valida cada tarefa antes do commit e, para mudanças maiores, executa uma revisão independente da implementação finalizada. Dentro do escopo aprovado, espera-se que o Claude escolha detalhes de implementação a partir do próprio código. O README recomenda usar o Claude Code diretamente quando o resultado e a fronteira segura de implementação já estiverem claros, e usar estes fluxos quando uma mudança precisar de acordo de escopo, decisões de design duradouras, transferência entre contextos ou verificação independente. O roteamento depende do número de decisões de produto e design, não da contagem de arquivos: mudanças pequenas seguem um ciclo de tarefa direto com verificações focadas e de repositório, além de uma revisão de segurança; mudanças médias adicionam um Design Doc revisado (e UI Spec ou ADR quando necessário), prova de integração/E2E selecionada e um Work Plan revisado; mudanças grandes com múltiplos resultados de produto independentes adicionam um PRD revisado. Artefatos como UI Specs, ADRs e esqueletos de teste aparecem apenas quando suas decisões ou fronteiras de prova se aplicam. Instalação Requer uma versão do Claude Code com suporte a marketplace de plugins. Adicione o marketplace com /plugin marketplace add shinpr/claude-code-workflows e instale um plugin de fluxo: dev-workflows (backend/geral), dev-workflows-frontend (React/TypeScript) ou dev-workflows-fullstack. O README afirma que apenas um plugin de fluxo deve ser instalado, pois o plugin full-stack já contém os fluxos de backend e frontend. A instalação com escopo de projeto é suportada para equipes via .claude/settings.json. Receitas e plugins Todos os pontos de entrada usam o prefixo recipe-. Receitas de backend/geral incluem /recipe-implement, /recipe-design, /recipe-plan, /recipe-build, /recipe-review, /recipe-quality-profile, /recipe-diagnose, /recipe-reverse-engineer, /recipe-add-integration-tests e /recipe-update-doc. O plugin de frontend adiciona /recipe-front-design, /recipe-front-plan, /recipe-front-build, /recipe-front-adjust e /recipe-front-review, com arquitetura de componentes React, React Testing Library e verificações de TypeScript. Uma receita full-stack cobre mudanças que abrangem backend e frontend, usando fatias verticais para que a integração seja exercitada antes do final. Agentes e orientações Os plugins agrupam papéis de agente especializados: papéis compartilhados 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 e security-reviewer; papéis de backend como technical-designer, scope-discoverer, task-executor e quality-fixer; e papéis de frontend como ui-spec-designer, ui-analyzer, technical-designer-frontend, task-executor-frontend e quality-fixer-frontend. As orientações integradas cobrem princípios de codificação, princípios de teste, abordagem de implementação, padrões de documentação, contexto de recursos externos e contexto amigável a LLM. Um plugin separado, dev-skills, oferece as orientações sem o fluxo, e o README alerta contra instalá-lo junto com um plugin de fluxo devido a descrições de skills duplicadas. Contexto e artefatos Contextos novos são usados para que o raciocínio de uma fase não se torne silenciosamente a autoridade da fase seguinte. As tarefas do Work Plan citam as seções do Design Doc, ADR ou UI Spec e os critérios de aceitação que as restringem, e o plano só é considerado concluído quando toda obrigação necessária do Design Doc é coberta por pelo menos uma tarefa. PRDs, ADRs, UI Specs e Design Docs devem ser commitados; docs/plans/ é tratado como estado de trabalho efêmero e o README sugere adicioná-lo ao gitignore. O README também menciona um equivalente para Codex CLI, codex-workflows, e links para leitura de contexto sobre verificação por LLM e design de fluxos de trabalho de agentes.