lucasaguiar11/workflow-kit

Limpa comentários ruído do código: remove // GET /path, banners de seção, JSDoc que só repete o nome, paráfrase da linha seguinte, TODO sem dono e código morto comentado. Mantém só gotcha/invariante e header curto de módulo (papel + why). Default = remover. Roda no fim da entrega de feature (Post-execution) no diff da feature, ou standalone. Use when: "limpar comentários", "comentários em excesso", "código sem comentários óbvios", "strip comments", "clean comments", ou /clean-comments. Alias legado: /comment-docs.

Code review multi-eixo (correção, legibilidade, arquitetura, segurança, performance) de qualquer mudança antes do merge — Pull/Merge Request (GitHub ou GitLab) ou diff local sem PR aberto. Use sempre que o usuário pedir para revisar um PR/MR, analisar mudanças de código, fazer code review, avaliar um pull/merge request, revisar uma branch, ou avaliar código escrito por outro agente/modelo antes de entrar na main. Também se aplica quando o usuário mencionar "revisar PR", "code review", "review PR", "analisa esse PR", "olha esse pull request", "revisa essa branch", "revisa esse diff", ou fornecer um link de PR/MR. Alias legado: pr-review. Inclui análise de padrões da codebase, validação de uso de libs via context7, e geração de comentários prontos para postar (somente o subconjunto aprovado pelo usuário).

Cria commits seguindo o padrão Conventional Commits em português. Divide mudanças em commits pequenos e atômicos. Use quando quiser fazer commit das alterações.

Create an Architectural Decision Record (ADR) document for AI-optimized decision documentation.

Create a new implementation plan file for new features, refactoring existing code or upgrading packages, design, architecture or infrastructure.

Revisão de código em pt-BR do diff desde um ponto fixo (commit, branch, tag ou merge-base) em dois eixos: Padrões (a mudança mantém a estrutura atual e segue as convenções que o repo já usa?) e Enxugamento (ponytail-review: o que dá pra cortar?). Só reporta o que tem evidência no código; zero findings é resultado válido. Tem modo rápido (passada única no agente diff-reviewer, modelo haiku). Use quando o usuário pedir em português para revisar branch, diff, PR ou trabalho em andamento, perguntar se a mudança segue os padrões ou se está over-engineered.

Decide quando delegar e coordena subagents com contexto pronto, checkpoints por papel, cancelamento seguro e validação centralizada. Use antes de lançar Workers, Scouts, Reviewers ou Validators.

Orchestrate lightweight feature delivery for new or existing projects using feature briefs, optional PRDs, optional ADRs, implementation plans, review gates, ownership boundaries, wave-based subagent launch/handoff, and Integration Coordinator execution for parallel human/AI work.

Generate high-quality Product Requirements Documents (PRDs) for software systems and AI-powered features. Includes executive summaries, user stories, technical specifications, and risk analysis.

Investigate an ambiguous bug/feature request, converge on a design with the user, then hand off a plan for approval — no docs/features.md, ADR, or plan file required. Use when the request has more than one plausible design (e.g. "we have two ways X can happen, what should we do") and a wrong guess would be expensive to unwind. Skip for single-file, unambiguous changes.

Revisa documentos de plano/implementação em loop até não encontrar problemas. Verifica consistência, ordem, referências cruzadas, e completude. Use quando quiser validar um plano antes de executar.

Executa handoffs cross-repo com contrato verificável, escopo rígido e proteção contra sobrescrita acidental. Use ao consumir um handoff de outra aplicação.

Review changed code for reuse, quality, and efficiency, then fix any issues found. Use after implementing a feature, before commit/PR.

Fold one or more old/superseded features into the new feature that replaced them — condense the relevant history into the successor's brief, mark the old ones deprecated with superseded_by, and git rm their dead plans (which stay recoverable in git history). Use when features are obsolete, replaced, ultrapassadas, antigas, or when a new feature supersedes earlier ones.

Audit and design useful tests for this project. Use when writing tests, reviewing test quality, deciding unit vs integration vs E2E, avoiding placebo tests, or when feature-delivery review/execute touches domain rules, persistence, validation, or API behavior.

Update an existing implementation plan file with new or update requirements to provide new features, refactoring existing code or upgrading packages, design, architecture or infrastructure.

Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always