Implementa um item do WiseWork — uma task, uma feature ou um bug. Você passa a referência; o comando busca o item, assume (coloca no seu nome e move para “em andamento”), constrói a implementação e mantém o item atualizado com comentários e status.
O item do WiseWork é a fonte da verdade e o próprio acompanhamento: o comando não cria plano nem checklist paralelos no seu repositório.
Uso
/ww:implement #1234
/ww:implement 3f2a1c9e-... --status done
/ww:implement "sistema de autenticação de usuários"
/ww:implement "reformulação do checkout" --type feature
Argumentos
| Argumento | Obrigatório? | Descrição |
|---|
<ticket|id|title> | Sim | O item a implementar: número do ticket (#1234), identificador colado ou um pedaço do título. Se mais de um item bater com o título, o comando pergunta qual você quis. |
--type task|feature | Opcional | Força o tipo do item quando a referência serve para os dois. Use feature para trabalhar a feature inteira, pelas tasks filhas. |
--status <key> | Opcional | Onde o item termina. Sem isso, ele vai para revisão. |
Notas
O comando nunca implementa algo que não buscou no WiseWork. Numa feature, ele trabalha as tasks filhas, uma a uma.
Quando você vai começar a trabalhar em algo que já está registrado no WiseWork e quer que o registro acompanhe o trabalho sozinho.
- Número do ticket —
#1234 ou só 1234.
- Identificador colado — funciona para task e para feature.
- Um pedaço do título — “sistema de autenticação de usuários”. Se houver mais de um item parecido, o comando pergunta qual você quis; se não houver nenhum, ele para e diz.
Antes de escrever código, o comando assume o item: coloca no seu nome, move para “em andamento” e publica um comentário de abertura dizendo que começou e qual é a abordagem. Numa feature, ele faz isso com cada task filha que vai implementar e move a feature para “em andamento”.
Durante o trabalho, ele entende o requisito pelos critérios de aceite e pelo código, segue os guias de estilo de ~/.claude/style-guides/ que se aplicam às tecnologias envolvidas (o /ww:config:style-guides traz os da galeria do WiseWork para essa pasta), implementa, revisa o que fez e publica comentários de progresso nos marcos que importam — não a cada tecla.
Quando o item mexe na interface (página, rota, componente, formulário, estilo, tradução), o comando carrega antes as regras de trabalho de frontend do plugin; quando mexe no servidor (endpoint, serviço, consulta, migration, permissão, job, integração), as de backend. Um item que cobre os dois lados usa as duas. Essas regras já chegam com a stack e os scripts de verificação do projeto levantados.
No fim, valida os arquivos alterados: verifica os tipos com o verificador que o projeto já usa (detectado automaticamente), roda o lint quando o projeto tem um e o build só quando não há verificação de tipos. Num trabalho de interface ou de servidor, somam-se as verificações que as regras daquele lado pedem, como testes. Os erros novos são corrigidos; os que já existiam em outros arquivos são relatados, não corrigidos.
Depois, anexa ao item a evidência que o trabalho gerou no projeto — capturas das telas validadas, relatórios de teste, logs, documentos — em vez de colar o conteúdo no comentário. Arquivos com credenciais ou acima de 20 MB ficam de fora, e o relatório avisa. Por fim, publica um comentário final com escopo, arquivos, decisões, resultado da validação e os anexos, e devolve o item com o status certo.
Ao terminar, você recebe o relatório: item, arquivos criados e alterados, anexos enviados, resultado da validação e o status final de cada task.
Por padrão, o item termina em revisão. Com --status, você escolhe outro status do seu produto.
Quando o destino é um status de conclusão ou de cancelamento, o comando registra também o motivo do fechamento e as notas — os mesmos campos que o WiseWork pede quando você fecha uma task pela tela. Na conclusão de um bug, pode entrar junto a causa raiz. Um status intermediário não tem esse registro, porque não há nada a fechar.
Numa feature, cada task filha implementada é fechada do mesmo jeito, e a feature fica “em andamento” enquanto sobrar task e “entregue” quando todas estiverem prontas.
- Ele não implementa nada que não tenha buscado antes. Se o item não existe no WiseWork, o comando não inventa trabalho.
- Escopo é escopo. Ele implementa o que os critérios pedem, seguindo os padrões do projeto, sem esticar a entrega em silêncio.
- Os comentários saem em seu nome, pelo seu acesso.
- O comando nunca esconde um erro.
- /ww:fix — quando o caso é corrigir, não construir
