Da Demanda à Entrega
Primeiro esclareça o que o usuário quer mudar e o que significa "concluído", depois execute. Continue o trabalho já autorizado até o fim; quando uma decisão for necessária, complete primeiro as partes que não dependem dela. Não trate "escrevi um plano", "o código compila" ou "o merge automático foi iniciado" como entrega final.
Convenções de Trabalho
- Escolha o método de desenvolvimento com base no objetivo, risco e custo do feedback. Pode-se escrever uma especificação primeiro, ou fazer TDD em interfaces públicas claras, ou implementar direto e validar depois; os métodos podem ser combinados. Sempre defina critérios de conclusão observáveis, obtenha evidências de comportamento real e não imponha um fluxo único para todas as tarefas.
- Descreva "o que é agora" com base no código atual, resultados de execução e artefatos de release reais; descreva "o que deve se tornar" com base no objetivo confirmado pelo usuário. Ao encontrar discrepância, corrija a implementação ou os registros obsoletos; não sobrescreva o objetivo do usuário com documentação antiga.
- Escolha o processo com base na escala. Pequenas alterações podem ter a especificação resumida em poucas frases; apenas requisitos que cruzam módulos devem ser divididos em fatias, projetados e documentados. Não carregue todo o conhecimento, estabeleça cadeias de aprovação fixas ou preencha modelos vazios para cada edição.
- O escopo já autorizado pelo usuário permanece válido. Pesquisa, implementação e verificação reversível não precisam de confirmação repetida; a liberação externa segue o objetivo explícito do usuário. Quando ainda faltam objetivos de produção ou autorização, prepare primeiro os artefatos, diferenças, rollback e verificação, depois explique o que está faltando.
- Este skill pode ser usado de forma獨立. Os skills listados na tabela abaixo são chamados sob demanda se instalados; se não estiverem instalados, o skill conclui diretamente o resultado da fase, sem exigir que o usuário instale o conjunto completo.
- Uma tarefa é continuamente avançada pelo responsável atual. Métodos especializados complementam as evidências e artefatos da fase atual, reutilizando decisões já confirmadas e o mesmo registro, sem criar um fluxo concorrente.
Escolha o Próximo Passo
| Situação Atual | Como Avançar | Skill Chamável |
|---|---|---|
| Não sabe qual habilidade usar, ou só quer aprender a usar | Escolha a entrada mínima para a tarefa; primeiro explique o uso, não confunda consulta com autorização de implementação | dev-help |
| Primeira configuração de ambiente, modelo de papel ou orçamento de inferência | Verifique as ferramentas e modelos reais disponíveis, salve preferências curtas; não assuma fornecedor fixo ou capacidade de backend | dev-setup |
| Quer que trabalhos repetitivos se ajustem gradualmente ao seu hábito | Extraia padrões estáveis do histórico permitido para leitura, formando habilidades de projeto curtas e mantíveis | dev-personalize |
| Usuário pergunta sobre o andamento durante a tarefa, ou precisa de um resumo para transição | Resuma o concluído, evidências atuais e pendências; responda e continue a tarefa original, a menos que uma pausa seja explicitamente solicitada | dev-status |
| Entrada vem de chat, Issue, screenshot, log ou múltiplos feedbacks | Encontre evidências originais, comportamento real, objetivos e escopo; mescle solicitações duplicadas | dev-intake |
| Precisa configurar integração de relatórios ou monitorar demandas por fonte | Separe a seleção de fonte, rastreador, roteamento de repositório, método de controle e gatilho real; complete a inicialização dentro da autorização | dev-issue-setup |
| Relatórios de fonte já configurada precisam de classificação, deduplicação ou roteamento | Processe evidências com base no relatório nativo, identidade e contrato do rastreador; as fontes podem ser chat, ticket, e-mail, alerta ou entrada manual; não reproduza nem corrija nesta fase | dev-issue-triage |
| Pipeline de relatórios configurado, triagem confiável e condições reais de controle de UI prontas | Verifique a atribuição, reproduza ou valide patches existentes conforme protocolo completo; corrija e entregue um draft de PR quando necessário e autorizado | dev-issue-fix |
| Regras do produto têm ambiguidade crítica | Primeiro responda com fatos do código, esclareça em rodadas as perguntas que mudariam a solução | dev-grill |
| Requisitos claros mas ainda não prontos para aceitação | Escreva comportamento do usuário, limites, não-objetivos e condições de sucesso | dev-spec |
| Usuário quer aprofundar ou reescrever a solicitação pendente | Use quatro perguntas para verificar omissões profissionais, materiais originais, método específico e evidências independentes; entregue um prompt utilizável | dev-sharpen |
| Assumindo um módulo desconhecido | Percorra um caso de uso real: entrada, negócio, armazenamento, feedback e caminho de falha | dev-learn |
| Não entende por que um design histórico existe | Diferencie comportamento atual, razão da época e suposição; rastreie código e evidências de decisão disponíveis | dev-why |
| Compensações substantivas em limites ou interfaces | Compare diferentes estruturas; julgue pela experiência do chamador, propriedade do estado e terminologia de domínio | dev-architecture |
| Modelo TLA+ existente ou claramente a ser criado, precisa de diagrama de estado com resultados de verificação | Execute TLC, gere marcadores de regra e contraexemplo mínimo; verifique gradualmente com código real | dev-statechart |
| Precisa verificar propriedades críticas, escolher ferramenta formal ou manter modelo | Especifique propriedades, suposições e limites; execute verificação e identifique deriva do modelo; diagramas explicativos comuns não entram automaticamente neste fluxo | dev-formal-verify |
| Envolve página, interação, sistema de design ou aceitação visual | Use componentes e tokens do código real; leia especificações de design por cenário de produto ou marketing; não exija conta de ferramenta de design | dev-ui-design |
| Requisito não pode ser entregue confiavelmente de uma vez | Divida em fatias funcionais verticais aceitáveis, dependências explícitas; primeiro faça o caminho mínimo completo funcionar | dev-plan |
| Trabalhos que não conflitam entre si ou diferentes soluções que valem a pena comparar | Atribua escopo de escrita e regras de aceitação, depois integre e valide o resultado final | dev-parallel |
| Especificação ou fatias prontas para implementação | Implemente conforme normas de engenharia existentes, conecte comportamento real, valide artefatos atuais | dev-build |
| Issue comum, erro de funcionalidade CLI/API/UI ou falha de aceitação | Reproduza a partir da entrada real e encontre a causa raiz; entre no fluxo de medição apenas se o alvo for métrica de desempenho | dev-debug |
| Usuário especificou TDD primeiro, ou implementação atual escolheu TDD | Complete teste falho e implementação mínima um por um na interface pública; testes de complemento para comportamento já correto não entram automaticamente em implementação vermelho-verde | dev-tdd |
| Erros similares ocorrem repetidamente ou restrições críticas são facilmente contornadas | Priorize melhorar tipo, interface e propriedade de estado; adicione regras executáveis quando houver valor real | dev-guardrails |
| Implementação concluída | Verifique separadamente conformidade com especificação e qualidade de engenharia; corrija problemas reais | dev-review |
| Precisa provar que caminhos reais de usuário funcionam | Conduza aplicação real, verifique resultados e efeitos colaterais; mantenha método de verificação reproduzível | dev-verify |
| Objetivo é melhorar latência, throughput, recursos ou outras métricas mensuráveis | Fixe carga de trabalho e métrica; complete coleta de evidências, otimização ou comparação justa; reutilize a mesma linha de base | dev-benchmark |
| Objetivo inclui ir para produção | Confirme ambiente e versão, execute implantação autorizada, verifique serviço real e registre | dev-deploy |
| Precisa de documentação clara, mensagem de commit ou resumo de PR | Organize informações pelas perguntas do leitor; forneça comportamento específico, evidências e compensações necessárias | dev-writing |
| Uma demanda foi entregue ou explicitamente interrompida | Organize novo conhecimento, corrija conflitos, preserve razões valiosas e arquive o processo | dev-archive |
Especificação existente: implemente diretamente. Só pediu design: entregue design. Só pediu explicação: pare na explicação. Leia Avanço e Retomada para lidar com paralelismo e interrupções. Para refinar requisitos, leia Transição de Fase da Demanda à Implementação; ao executar a tarefa selecionada, leia Método de Execução de Engenharia; eles complementam a fase atual, não reselecionam fases já concluídas.
Quando não houver fluxo pronto adequado para uma tarefa complexa, use Método de Execução Personalizado para formar unidades verificáveis e continuar o trabalho autorizado. Para registro e revisão posterior de tarefas longas, use Método de Evidência de Decisão para verificar se decisões, alternativas e evidências reais correspondem; quando apenas revisão for solicitada, entregue o resultado da auditoria, não continue migração ou implementação automaticamente. Rastrear por que um design foi adotado no passado é responsabilidade do dev-why. Quando o usuário explicitamente quiser construir um painel de status operacional, trate como tarefa de implementação; apenas consultar andamento use dev-status.
Para o Trabalho Continuar
Os materiais de projeto criados por este conjunto de skills têm como raiz .agents/wtadev/, usando as seguintes partições conforme necessário. Materiais existentes devem ser consultados em seu local real e referências necessárias preservadas; apenas migre quando explicitamente solicitado, mantendo conteúdo, identificadores e links válidos. Quando o usuário especificar outro local nesta sessão, siga sua instrução:
.agents/wtadev/changes/<data-tema>/: brief, spec, plan, progresso, evidências da demanda atual; crie conforme necessário..agents/wtadev/notes/: terminologia validada, contexto, decisões, erros aprendidos e entendimento de módulo; o arquivoindex.mdapenas aponta o caminho..agents/wtadev/deploy/<ambiente>/: manual de implantação e registros de release históricos emreleases/..agents/wtadev/archive/changes/,.agents/wtadev/archive/notes/: trabalhos concluídos e conhecimento histórico, explicitamente não representam comportamento atual.
Estes são materiais do projeto alvo, não devem ser escritos no pacote de instalação .agents/skills/. Para recuperação, use o Modelo de Transição, deixando apenas o resultado atual, evidências, pendências e próximos passos.
Conclusão
Compare com o objetivo de entrega original: forneça as alterações reais, evidências de verificação da versão atual, endereço de entrega ou commit, e as partes realmente não concluídas. Se precisa ir para produção mas ainda não foi implantado, escreva explicitamente "Implementação concluída, implantação não concluída"; após a implantação bem-sucedida, integre o conhecimento reutilizável e referências ao código mais recente no projeto, em vez de despejar todo o histórico de chat no AGENTS.md.
Materiais Locais Completos
Consulte o Índice de Métodos para escolher os fluxos completos, regras de verificação, exemplos e modelos dentro deste skill. Todos os recursos necessários para execução estão neste pacote, sem depender da instalação de outros skills; leia apenas o conteúdo necessário para a tarefa atual do branch.