Spielewoy/autoprompt-skill

Autoprompt

Autoprompt é um loop de orquestração que prioriza a utilidade. Ele armazena a missão uma vez, produz um roadmap executável aprovado de forma independente, despacha faixas prontas para implementação diretamente e comprova o comportamento entregue com testes reais e revisão atualizada.

1. Contrato de início

A invocação autoriza a missão. Não peça ao usuário para reformular, restringir ou aprová-la.

Carregar a skill ou invocá-la sem uma missão nunca inicia ou retoma uma execução, independentemente de artefatos residuais. Uma invocação simples realiza apenas a verificação de fronteira da seção 10, relata o resultado e para.

Antes de gerar, resolva apenas os botões de operador indefinidos:

• Concorrência: tokensaver (padrão, até seis ativos), wide/billionaire (todo trabalho disjunto pronto até o limite global), ou custom max_subs=N.
• Seleção de agente: off/herdado. Subagentes OMP herdam o modelo em execução, portanto a capacidade de esforço é exatamente inherited-only; nunca afirme um esforço selecionável.

Em uma sessão monitorada, pergunte todos os botões indefinidos em uma única pergunta antes do trabalho de repositório/ferramenta. Em uma execução de supervisor não monitorada, não pergunte: use o padrão tokensaver e agents=off e registre as suposições. Uma flag de permissão ignorada não é não monitoramento.

Após o seletor, despache o coordenador de escopo L1 ap-scope-coordinator; ele despacha o autor do roadmap com prioridade de utilidade. Não há viagem de ida e volta separada de coleta e nenhum agente de pré-verificação obrigatório.

Uma missão invocada sempre entra em orquestração: a topologia de escopo limitado é a topologia mínima, e o agente principal nunca faz autotriagem silenciosa de uma missão invocada para execução direta. Pular ou restringir o despacho é uma decisão explícita registrada em GATELOG.md com sua justificativa, nunca uma decisão silenciosa.

2. Caminho rápido de capacidade

Um supervisor pode fornecer uma atestação de capacidade versionada vinculada ao provedor/runtime, versão da CLI, perfil de permissão, seletor de agente, hash da definição do agente, hash de elenco, status/fonte de esforço e sucesso exato de RUN/READ/WRITE. Use-a apenas quando cada vínculo corresponder à inicialização ativa. Valores ausentes, malformados, desatualizados, desconhecidos ou contraditórios são falhas seguras.

Sem uma atestação confiável, o primeiro autor útil do roadmap prova RUN, READ e WRITE contra um caminho de rascunho descartável antes da inspeção do repositório e então continua imediatamente. Qualquer falha para completamente antes da implementação. A persona de pré-verificação é apenas para diagnóstico/recuperação.

3. Topologia de escopo adaptativa

O escopo produz um único ROADMAP.md canônico.

• limitado: autor do roadmap, depois revisor independente e verificador cego fresco simultaneamente – 3 agentes, 2 rodadas, alvo abaixo de um minuto;
• multissuperfície: exatamente 5 agentes, 3 rodadas, alvo abaixo de cinco minutos; mantenha o roadmap completo do autor e as evidências, adicione exatamente dois scouts complementares, depois revisor concorrente mais verificador fresco sem um despacho de síntese redundante;
• excepcionalmente grande: pode exceder o orçamento comum de 6 agentes apenas com um motivo de escalada concreto registrado.

Pesquisa externa é executada apenas quando fatos externos atuais são necessários. Na rejeição, mantenha as evidências aceitas e repare apenas os itens nomeados. Roadmaps vazios, DAGs inválidos, propriedade sobreposta, frameworks/testes ausentes e falha de capacidade são falhas graves.

4. Roadmap executável

ROADMAP.md é a única fonte de escopo/decomposição/plano da nova execução. Inclui ponteiro/hash da missão e nonce; perfil de escopo/escalada; inteligência de repositório; decisões de framework/ferramenta; IDs de itens estáveis; categoria/tag/camada/framework; limites de propriedade; dependências e grupos de inicialização; faixa de integração; etapas de implementação; critérios de aceitação positivos; caminhos infelizes; testes primeiro; verificação real; cobertura >=95% de linhas alteradas e módulos tocados; e requiresDetailedPlan apenas quando necessário.

Itens prontos para implementação são despachados diretamente para construção. Adicione G1 apenas para trabalho de depuração/profundidade, uma bifurcação de design nomeada não resolvida, requiresDetailedPlan: true ou um conflito de plano relatado pelo trabalhador.

Decomponha a missão em cada faixa genuinamente disjunta. Nunca colapse uma missão multissuperfície em uma faixa "limitada" para encolher o roadmap; superfícies disjuntas obtêm faixas disjuntas com propriedade disjunta.

5. Governança de nova execução

A governança de nova execução é exatamente:

1. PROMPTS.txt – blocos de prompt exatos somente de acréscimo;
2. ROADMAP.md – roadmap executável canônico;
3. GATELOG.md – transições somente de acréscimo, proveniência de persona/modelo/esforço, vereditos, hashes, tempo decorrido e fronteira de retomada.

Não crie novos arquivos de governança como BRIEF.md, PLAN.md, AGENTS.md, COVERAGE.md, BACKLOG.md, ANCHOR.md, bucketlist.md, intake.md, scope-map.md ou arquivos de escopo por ângulo. Preserve evidências substantivas de implementação/teste/revisão/verificação. Registros legados permanecem legíveis e formatos mistos contraditórios falham fechados.

A governança reside na raiz de governança da execução fora do repositório alvo da missão: PROMPTS.txt, ROADMAP.md e GATELOG.md nunca são escritos na árvore de trabalho alvo e nunca devem aparecer em seu diff.

6. Briefs de ponteiro compactos

O primeiro autor do roadmap armazena a missão exata em PROMPTS.txt. Briefs posteriores carregam:

MISSION POINTER: leia o registro de prompt exato antes de agir; pare se seu hash ou comprimento em bytes diferir.
caminho=<PROMPTS.txt> hash=sha256:<64 hex> bytes=<comprimento em bytes UTF-8> nonce=<NONCE-DA-EXECUÇÃO>

Trabalhadores verificam caminho, hash, comprimento em bytes e nonce antes de agir. Envie apenas função, objetivo, limite, dependências, critérios de aceitação, ponteiros de roadmap/evidências com hashes, esquema/caminho de saída e status de modelo/esforço. Não cole a missão, transcrição, roadmap completo, doutrina ou raciocínio adversarial anterior. Preserve a revisão cega.

7. Hierarquia e despacho

Cada trabalhador é uma persona ap-* instalada e registrada. Sua definição de agente personalizada mais o brief da tarefa despachada são seu contexto operacional completo. Um trabalhador nunca deve carregar, invocar ou reinvocar a skill Autoprompt ou iniciar uma execução aninhada do Autoprompt; ele executa apenas suas instruções de persona e o brief atribuído. Cada despacho vincula o nome registrado da persona pretendida como o tipo de agente: um agente anônimo, de propósito geral ou dinamicamente inventado é um despacho inválido, e qualquer despacho filho deve nomear outra persona ap-* registrada.

• Condutor L0: inicia a execução e relata o veredito final. Em uma nova execução, ele despacha apenas os coordenadores L1 nomeados – ap-scope-coordinator para escopo, ap-feature-coordinator para construção, ap-sweep-coordinator para convergência – nunca um gerente L2 ou um trabalhador L3/L4 diretamente; uma geração direta de trabalhador é um colapso de ignorar o coordenador. ap-preflight-probe e ap-intake permanecem exceções de diagnóstico e retomada de legado, nunca gerações rotineiras.
• Coordenadores L1 (ap-scope-coordinator, ap-feature-coordinator, ap-sweep-coordinator): possuem escopo, frota de recursos ou convergência e apenas despacham. Cada um despacha ap-manager para uma fatia de vários recursos ou várias faixas, ou trabalhadores L3/L4 nomeados diretamente em uma única faixa limitada.
• Gerente L2 (ap-manager): opcional para uma fatia de vários recursos ou várias faixas; despacha trabalhadores L3/L4 nomeados e nunca executa.
• Executores L3 (ap-scoper, ap-researcher, ap-synthesizer, ap-planner, ap-implementer, ap-reviewer, ap-verifier, ap-sweeper, ap-execharness-resolver, ap-framework-generator): realizam trabalho de roadmap/scout/pesquisa/síntese/planejamento/construção/revisão/verificação/varredura.
• Folhas terminais L4 (ap-fresh-verifier, ap-depth-prober, ap-framework-validator, ap-juror, ap-goal-checker, ap-arbiter, ap-re-anchor, ap-scribe, ap-janitor): realizam verificação cega, bloqueio de profundidade, validação de framework, júris, verificação de meta, arbitragem, reancoragem, registros e limpeza.

L1 nunca executa. Uma única faixa limitada ignora L2. Despache trabalho disjunto pronto junto, gerando-todos-depois-coletando: emita cada geração de um grupo pronto antes de coletar qualquer relatório – o despacho em segundo plano paralelo é a forma padrão e a serialização é permitida apenas para dependências reais declaradas. Sem auto-revisão. Reutilize evidências válidas e evite propriedade duplicada.

Subagentes estendem o trabalho do agente que despacha; eles nunca o substituem. O despachante mantém síntese, integração e julgamento final. Trabalhadores comuns de implementação, planejamento e relé de leitura não devem rederivar contexto que o despachante já possui. Agentes de garantia independentes devem rederivar independentemente a verdade relevante sem ler os vereditos uns dos outros ou consumir as afirmações de sucesso do autor.

Cada despacho é coletar-e-depois-parar: pare aquele agente explicitamente assim que seu relatório final for coletado; um agente estacionado retomável ainda é um agente ativo e conta contra o teto de ativos. Nunca deixe um agente concluído ocioso para possíveis acompanhamentos.

8. Modelo e esforço OMP

OMP usa subagentes markdown nativos com listas de permissão spawns explícitas. As funções geradas omitem uma substituição de modelo e herdam o modelo pai selecionado. Elenco e esforço são, portanto, inherited-only; agents=auto e listas de modelos explícitas não são roteáveis através deste adaptador.

OMP descobre a skill instalada e os arquivos de agente ap-* de seu diretório de agentes. As listas nativas de spawns impõem arestas filhas canônicas e OMP impõe o teto de recursão.

9. Construção e verificação

Use TDD rigoroso: escreva e execute o teste de comportamento com falha correto, implemente a mudança mínima, refatore sob verde, execute módulos tocados e dependentes diretos e prove cobertura >=95% de linhas alteradas/módulos tocados. Use executores e sistemas reais. Não simule o sistema sob teste ou bancos de dados em testes de integração.

Revisão de implementação independente e verificação em tempo de execução são executadas simultaneamente quando nenhuma consome o veredito da outra. O trabalho de depuração requer evidências de vermelho-para-verde derivadas de problema e bloqueio de profundidade na função responsável mais profunda.

DONE requer cobertura total da missão/roadmap, zero descobertas abertas, usabilidade, nenhuma regressão de verde-para-vermelho pré-existente, cobertura >=95% de linhas alteradas, exercício real de ponta a ponta, validação de registro bem-sucedida, zero subagentes ativos e limpeza quando ativada.

10. Retomada, direcionamento, arbitragem e git

Retomada é explícita: apenas uma instrução explícita de resume ou um relançamento do supervisor retoma uma execução; carregamento de skill, invocação simples ou artefatos residuais nunca o fazem. A única leitura de inicialização é a cauda do GATELOG.md – sua última linha de fronteira carrega o ponteiro/hash da missão, nonce, último portão aceito e IDs de itens abertos; relate esse status em menos de 150 palavras e pare quando nenhuma fronteira estiver ativa. Na retomada explícita, verifique o hash do ponteiro e despache a fronteira aberta com briefs de ponteiro compactos; trabalhadores, não o contexto de retomada, leem ROADMAP.md, PROMPTS.txt e evidências substantivas. Trate artefatos temporários, vazios ou não analisáveis como ausentes. Anexe o auto-direcionamento posterior ao próximo bloco de PROMPTS.txt sem reescrever o histórico.

O árbitro decide bifurcações técnicas. Pergunte ao usuário durante a execução apenas para ações irreversíveis/destrutivas genuinamente de propriedade do usuário, dinheiro real/cota, credenciais indisponíveis ou direção do produto. Nunca arbitre falha de capacidade, bloqueadores, cobertura ou verificação real.

Não faça commit, push, publique, implante, gaste dinheiro, exclua dados do usuário, force-push, reset hard ou limpe a árvore de trabalho sem autorização explícita do usuário.

11. Execução

Use OMP 17.4.0 ou posterior e invoque explicitamente:

/skill:autoprompt <missão>

OMP descobre a skill instalada e os arquivos de agente ap-* de seu diretório de agentes. As listas nativas de spawns impõem arestas filhas canônicas e OMP impõe o teto de recursão.