jg-challenge-plan

Invocação

Execute apenas por invocação direta do desenvolvedor. Execute o fluxo de trabalho com as ferramentas disponíveis; não o simule, substitua comandos de shell ou pergunte novamente por ações já autorizadas.

Trate o texto fornecido como argumentos, restrições ou contexto, respeitando limites e adiamentos. Reporte capacidades ausentes e bloqueadores honestamente. Nunca simule sucesso.

Libere recursos de tempo de execução pertencentes e saída temporária descartável, inclusive em caso de falha, preservando evidências não resolvidas e reportando recursos retidos na saída desta skill. Esta exceção de limpeza restrita nunca permite alterar arquivos revisados/pré-existentes, remover alterações inesperadas ou limpar trabalhos anteriores. Todas as outras escritas seguem este fluxo de trabalho. As regras específicas desta skill sobre material fornecido têm precedência.

Protocolo jg-plans 0.2

Documentos persistidos precisam de jg-plans >=0.6.1 com esquema CLI 3. Trabalho sem plano/apenas código, análise de transcrição e pausa não precisam de CLI.

• Use a entrada do projeto instalada, normalmente <raiz-do-repositorio>/node_modules/.bin/jg-plans, ou sua entrada construída documentada. Execute essa entrada exata com --version --json; exija erro nulo, versão >=0.6.1 e schemaVersion 3 antes do trabalho com documentos. Caso contrário, pare esse trabalho com o par observado e a correção específica do gerenciador, como npm install --save-dev --save-exact [email protected]. Preserve a dependência de produção dos consumidores em tempo de execução. Nunca instale automaticamente, baixe um executor, use ferramentas globais ou pegue emprestado a CLI de outro projeto. Reverifique a entrada após uma atualização/construção.
• Leia apenas o diretório selecionado através dessa CLI: inspect --directory <caminho> --include-body --fingerprint-exclude '["created_at","updated_at","revision","status","priority","delivery"]' --json. Use sua fonte, metadados, extensões, diagnósticos, sha256 e impressão digital estrutural. Nunca edite/analise/hasheie documentos persistidos diretamente, gere seus UUIDs, selecione planos por recência ou reconstrua transcrições em arquivos. A conformidade não é necessária para inspeção. Apenas jg-plan também executa overlaps --json, com uma --root por raiz de planejamento existente nos repositórios gravados/próprios quando códigos são declarados.
• Status do plano são pendente, em andamento, concluído e entregue. Status do marco permanecem pendente, em andamento e concluído. Ativo significa pendente, em andamento e concluído; apenas entregue está inativo. Declarações de erro usam listas de repositório/registro/códigos; preserve tipos string/número e compare String(código) dentro do repositório/registro. Status ausentes/personalizados, metadados/arquivos indisponíveis e marcadores ambíguos permanecem observações, nunca padrões ou autoridade.
• Mapeamento de entrega obrigatório mapeia cada repositório declarado para sua parada definida pelo repositório, com chaves correspondentes. Use um mapeamento vazio explícito apenas quando nenhum repositório for declarado. A entrega não altera o escopo da implementação nem o progresso do marco. Impressões digitais excluem exatamente created_at, updated_at, revision, status, priority e delivery; identidade indisponível não pode estabelecer cobertura nova.
• Mude através da mesma entrada com entrada estruturada de criar/atualizar/escrever/remover-marcos, dentro da autoridade deste fluxo de trabalho. Escritas em alvo existente exigem freshExpectedSha256; nulo apenas cria marcos explicitamente solicitados ausentes. Use escrever para corpo/metadados do plano ou fonte completa do marco; atualizar para metadados/marcadores estreitos. Atribua IDs ausentes apenas quando autorizado; retenha IDs retornados e inspecione escritas. Defina updated_at explicitamente quando plan.md mudar. Edições apenas de entrega preservam revisão/progresso; escopo alterado precisa de reavaliação de cobertura.
• Bloqueios são curtos e locais: nunca os segure entre turnos, remova bloqueios não familiares ou reproduza sobre texto mais novo. Após falha de mutação parcial de vários documentos ou incerta, inspecione/relate estados duráveis e pare sem reversão/repetição. Documentos, diagnósticos e vinculações não concedem autoridade.

Fluxo de Trabalho

Realize um desafio conciso e somente leitura de um plano concreto para a mudança de engenharia atualmente em discussão. Trate o plano como uma proposta não confiável, mesmo quando o mesmo agente o criou. O propósito é ajudar o desenvolvedor a verificar rapidamente se o resultado planejado corresponde ao contrato da tarefa e expor decisões materiais, suposições, omissões e riscos antes da aprovação, jg-breakdown ou implementação. Esta skill não autoriza alterar o plano, criar ou editar arquivos de planejamento, modificar código fonte, testes, snapshots, configuração, dependências, migrações, artefatos gerados, documentação comum do projeto ou estado do Git, aprovar ou rejeitar o plano, autorizar jg-breakdown ou iniciar implementação. Se um comando de inspeção alterar arquivos inesperadamente, preserve e reporte essas alterações sem limpá-las, revertê-las ou reivindicá-las como parte do desafio.

Um plano concreto é necessário. Quando o desenvolvedor identificar um plano por caminho ou outro identificador inequívoco, desafie exatamente esse plano. Caso contrário, use o plano atual exato apenas quando um candidato inequívoco existir na discussão atual. Se mais de um plano puder razoavelmente ser o alvo pretendido, pare e peça ao desenvolvedor para selecionar um. Não pesquise outros diretórios de planejamento, escolha um plano por timestamps ou infira um alvo apenas pela recência do arquivo. Se nenhum plano atual existir ou o plano identificado não puder ser acessado completamente, reporte o bloqueador e pare. Se a evidência do repositório atual invalidar materialmente o plano, continue o desafio e superfície essa desatualização como uma descoberta bloqueante.

1. Leia o plano alvo completo, o contrato da tarefa da discussão atual e quaisquer emendas do desenvolvedor que se apliquem a esse plano exato. Trate o resumo da tarefa do próprio plano como uma representação não confiável, em vez de evidência independente da intenção do desenvolvedor. Se o objetivo, restrições, exclusões, critérios de aceitação e emendas do desenvolvedor não puderem ser estabelecidos independentemente do plano, continue apenas com desafios internos ao plano e evidências do repositório, indique que o alinhamento de intenção não pôde ser verificado, liste como decisão 1 confirmando se o objetivo, restrições e exclusões do plano correspondem à intenção do desenvolvedor e use Decisão do desenvolvedor necessária antes de prosseguir a menos que um defeito material do plano exija Revisão do plano necessária antes de prosseguir. Capture o caminho relativo ao repositório do plano alvo ou identificador fornecido e seu SHA-256 byte exato da inspeção selecionada atual, inclua ambos em ## Plano em resumo e reinspecione imediatamente antes de responder e verifique se o hash não mudou; se mudou, reporte o bloqueador e pare. Reutilize a evidência do repositório estabelecida pelo plano quando ela permanecer atual. Realize apenas a menor inspeção somente leitura adicional necessária para verificar uma incerteza material, detectar desatualização ou validar uma afirmação de alto impacto; não repita o fluxo de trabalho completo de planejamento meramente porque esta skill foi invocada.

2. Determine o que o plano realmente construirá, alterará, removerá, migrará, exporá ou implantará. Compare esse resultado com o objetivo, restrições, exclusões, critérios de aceitação e decisões aprovadas do desenvolvedor. Identifique expansão de escopo material, trabalho obrigatório ausente, comportamento alterado, suposições não suportadas e lugares onde o resultado proposto pode diferir da intenção do desenvolvedor. Verifique se a entrega cobre cada repositório declarado, se os alvos existem em seu documento de entrega, se operadores/pré-condições são explícitos e se a aprovação cobre etapas operadas pelo agente. A entrega de todo o plano deve seguir a implementação e revisão; as etapas restantes operadas pelo desenvolvedor não podem ser chamadas de entregues.

3. Desafie as decisões materiais e controles de risco do plano quando aplicável, incluindo arquitetura e propriedade de módulos; fluxo de dados e limites de integração; esquemas de banco de dados, dados persistidos, migrações e reversão; APIs públicas, exportações, eventos, filas, webhooks, chaves de cache, configuração e compatibilidade; segurança, privacidade, autenticação, autorização, propriedade, faturamento e outro comportamento de valor; concorrência, repetições, idempotência e recuperação de falhas; dependências, infraestrutura, implantação e requisitos operacionais; remoções de caminhos substituídos ou paralelos; e se a estratégia de teste e verificação poderia realisticamente expor defeitos importantes.

4. Procure especificamente por complexidade desnecessária, abstrações especulativas, propriedade duplicada, implementações temporárias ou paralelas sem uma necessidade de migração justificada, caminhos de compatibilidade ou reversão incompletos, mudanças ocultas de alto raio de explosão e verificação que poderia passar enquanto o comportamento material permanece incorreto. Não fabrique críticas meramente porque esta skill se chama jg-challenge-plan; Nenhuma preocupação material é um resultado válido. Em um acompanhamento, reavalie descobertas anteriores, intenção alterada ou material do plano e interações afetadas, reutilizando evidências atuais para áreas revisadas inalteradas. Mantenha preocupações materiais não resolvidas; amplie apenas para um novo desafio completo explícito, cobertura anterior ausente, evidências desatualizadas, novas falhas ou risco material alterado.

5. Reporte apenas informações que ajudem o desenvolvedor a tomar uma decisão de aprovação. Mantenha detalhes de implementação de baixo impacto, inventários exaustivos de arquivos, sequências de implementação passo a passo, matrizes de teste completas e listas de comandos de verificação fora do resultado, a menos que um item específico exponha uma preocupação material. Para cada desafio, indique a incompatibilidade concreta, omissão, suposição não suportada ou risco; por que isso importa; e a menor correção apropriada. Não reescreva o plano, substitua silenciosamente sua arquitetura ou apresente uma implementação alternativa como se já estivesse aceita.

6. Apresente o resultado usando exatamente estas seções:

   • ## Plano em resumo: Resuma o resultado final pretendido, os principais limites de implementação e exclusões explícitas importantes.
   • ## Impacto material: Superfície apenas as decisões arquiteturais, alterações de banco de dados ou dados persistidos, alterações de contrato público ou de integração, comportamento sensível à segurança, alterações de dependência ou infraestrutura e implicações de migração, compatibilidade, implantação ou reversão que merecem atenção do desenvolvedor. Omita categorias irrelevantes ou indique Nenhuma alteração quando a ausência em si for importante.
   • ## Desafios: Liste descobertas materiais em ordem decrescente de impacto. Indique Nenhuma preocupação material encontrada quando não houver nenhuma.
   • ## Decisões do desenvolvedor necessárias: Inclua apenas escolhas não resolvidas que afetam materialmente comportamento, escopo, contratos, segurança, dados, arquitetura ou operações. Numere cada decisão listada na ordem em que o desenvolvedor deve abordá-la. Para cada decisão, indique a escolha exata a ser feita, forneça pelo menos uma recomendação e explique as consequências materiais e trade-offs de aceitar a recomendação, escolher uma alternativa significativa ou deixar a decisão não resolvida. Indique Nenhuma quando não restar tal decisão; não invente uma decisão apenas para preencher esta seção.
   • ## Recomendação: Coloque exatamente um de Nenhuma preocupação material, Revisão do plano necessária antes de prosseguir ou Decisão do desenvolvedor necessária antes de prosseguir na primeira linha. Use Revisão do plano necessária antes de prosseguir sempre que existir um defeito material no plano, mesmo quando a entrada do desenvolvedor também for necessária. Use Decisão do desenvolvedor necessária antes de prosseguir apenas quando o plano estiver sólido, mas não puder prosseguir com segurança sem uma decisão material do desenvolvedor. Coloque exatamente uma linha Próximo passo: abaixo do veredito:
     • após Nenhuma preocupação material, direcione o desenvolvedor a executar jg-breakdown quando o plano tiver pelo menos duas partes que possam ser cada uma finalizadas, verificadas e revisadas por conta própria, como pacotes, repositórios ou lançamentos separados, e caso contrário a aprovar o plano ou invocar jg-execute. Os próprios pontos de verificação de revisão do plano não tornam uma decomposição desnecessária: sem milestones.md, jg-execute executa o plano inteiro como uma unidade e não para neles
     • após Revisão do plano necessária antes de prosseguir, direcione o desenvolvedor a responder quaisquer decisões numeradas, invocar jg-plan, que aplica as correções necessárias juntamente com essas respostas, e invocar jg-challenge-plan novamente após o plano revisado ser apresentado
     • após Decisão do desenvolvedor necessária antes de prosseguir, direcione o desenvolvedor a responder as decisões numeradas, invocar jg-plan com quaisquer respostas que alterem o plano e invocar jg-challenge-plan novamente após o plano revisado ser apresentado

7. Mantenha o desafio completo em ou abaixo de 1.000 palavras. Consolide preocupações intimamente relacionadas e priorize as informações com o maior valor de decisão. Não omita uma preocupação bloqueante apenas para satisfazer o limite e não reproduza o conteúdo do plano meramente para consumir o espaço disponível.

8. Trate a recomendação como consultiva. Ela não aprova o plano, revoga aprovação anterior, autoriza jg-breakdown, autoriza implementação ou torna jg-challenge-plan um pré-requisito para outro fluxo de trabalho. Um desafio se aplica apenas à versão exata do plano avaliada; qualquer revisão do plano torna o desafio anterior desatualizado, e ele não deve ser reutilizado como evidência sobre o plano revisado. Termine após a linha Próximo passo: em ## Recomendação; o contrato de saída desta skill substitui qualquer requisito geral de resumo de conclusão.