Desenvolvedor (cstrlcs/skills)

Desenvolvedor

Entregue o comportamento solicitado com a menor mudança coerente que se encaixe no projeto.

Compreender

Estabeleça o comportamento esperado e o caminho de chamada afetado antes de editar. Para bugs, reproduza a falha antes de corrigi-la quando for prático.

Leia as referências quando seu ramo se aplicar:

• Tarefas grandes com fluxos de trabalho de implementação independentes: siga delegação quando subagentes estiverem disponíveis; mantenha tarefas pequenas ou fortemente acopladas com o agente principal.
• Escrever ou alterar testes: leia testes primeiro; siga seu fluxo de trabalho orientado a testes quando o usuário solicitar desenvolvimento orientado a testes.
• Causa incerta, correção falha, bug intermitente ou regressão de desempenho: siga depuração, estabelecendo seu ciclo de feedback antes de formar hipóteses.
• Construir ou alterar uma interface de usuário (páginas, telas, marcação, estilos, texto da interface, foco ou manipulação de entrada): leia frontend e UI antes de escrever, depois os arquivos do ramo que ele vincula.
• APIs, persistência, migrações, eventos, fluxos de trabalho distribuídos, trabalhos em segundo plano, integrações ou mudanças em tempo de execução: serviços e dados.

Implementar

• Use cláusulas de guarda: trate cada caso de saída primeiro com um retorno antecipado ou lançamento, depois escreva o caminho principal sem indentação. Aplique isso mesmo quando o caminho principal for uma única instrução, para que toda função leia da mesma forma: condições que a interrompem no topo, o trabalho abaixo. Um operador ternário ou else que escolhe entre resultados é a forma a substituir.
• Escreva uma expressão de uso único inline em seu ponto de chamada. Extraia uma função nomeada somente quando ela for reutilizada, encapsular lógica longa demais para ser lida no local, ou for testada por si só, porque um wrapper de uma linha envia o leitor para outro lugar para aprender o que a expressão já diz. Adicione abstrações apenas para comportamento compartilhado existente, um limite real ou uma necessidade de teste demonstrada.
• Nomeie um valor após o parâmetro ou propriedade que ele preenche quando esse nome ainda o descreve, e passe-o com abreviação: const base = … e depois { base }, não const projectsBase = … e depois base: projectsBase. Adicione um qualificador apenas para informações que o código circundante já não fornece, como distinguir dois valores no mesmo escopo, porque um alias faz o leitor mapear dois nomes para uma coisa.
• Essas regras de estilo governam as linhas que você escreve. Deixe o código circundante e seus comentários existentes como estão, a menos que sua mudança os torne incorretos, porque reformatar código não tocado enterra a mudança no diff.
• Valide entrada não confiável em sua fronteira e confie nela a partir desse ponto; trate erros apenas onde eles podem ocorrer e onde um chamador pode agir sobre eles, preservando o contexto do erro e a limpeza.
• Quando uma mudança precisar de uma nova dependência, confirme o pacote exato em seu registro (nome, editor, idade, scripts de instalação) e fixe-o por meio do arquivo de bloqueio, porque agentes são propensos a nomes de pacotes alucinados e com typosquatting.
• Atualize contratos afetados, exemplos de configuração e documentação.

Verificar e entregar

Execute as verificações relevantes do projeto: formatação, lint, tipos, testes e build. Antes de terminar, confirme se cada linha alterada remete à solicitação ou a uma expansão de escopo declarada. Para critérios de aceitação explícitos, mapeie cada um para a verificação que mostra que foi atendido; passar verificações gerais sozinho não estabelece aceitação. Termine quando o comportamento estiver verificado, ou declare exatamente o que permanece não verificado e por quê.

Relate o comportamento resultante, as interpretações que você escolheu onde a solicitação era ambígua, qualquer expansão de escopo e o motivo, as verificações que você executou e as limitações materiais.