FlintSH/delivery

Entrega

O usuário fornece o objetivo e as restrições, depois espera um resultado finalizado e verificado sem supervisão. As instruções atuais e regras do repositório têm precedência sobre tudo abaixo. As instruções globais do usuário podem adicionar especificidades pessoais (limites de máquina, produtos, bots de revisão, estilo); siga-as.

Estabelecer a tarefa

1. Leia o AGENTS.md/CLAUDE.md do repositório, arquitetura relevante, manifestos de pacotes e lockfile, e o status atual do Git. Inspecione o branch real da tarefa, a base, o issue e qualquer worktree existente antes de editar.
2. Identifique critérios de aceitação observáveis: comportamento, configuração, compatibilidade, polimento de UI, evidências de teste e o método de entrega solicitado. Faça escolhas reversíveis razoáveis; pergunte apenas sobre ambiguidades consequentes.
3. Tarefas substanciais não relacionadas precisam de worktrees Git isoladas. Reutilize uma worktree que o harness já criou para esta tarefa. Não alterne ou redefina um checkout compartilhado. Se vários agentes compartilham intencionalmente uma worktree, concorde sobre a propriedade dos arquivos e um escritor Git. Pedidos anteriores para fazer push para main não autorizam novos pushes.

Implementar e verificar

• Preserve a identidade do produto. Polimento em superfícies existentes em vez de redesenhá-las, a menos que a tarefa peça um redesign.
• Verifique as versões do framework e da API instaladas antes de usar novas APIs. Consulte a documentação oficial atual, ou Context7 quando instalado, para comportamentos desconhecidos ou sensíveis a versão.
• Para alvos de plataforma (servidores de jogo, versões de SO móvel, motores de navegador, runtimes), verifique compatibilidade com o alvo real da build e a API oficial. Nunca teste contra produção como substituto de uma instância de desenvolvimento.
• Prefira os comandos de teste e build do repositório. Adicione cobertura de regressão significativa para mudanças de comportamento, depois teste integrações afetadas. Para trabalho de UI, use visual-qa sem ser lembrado.
• Paralelize pesquisa e edições independentes quando útil, com propriedade clara. Dimensione a concorrência para a máquina: verifique CPU e memória antes de executar mais de uma build pesada ou renderização, ou mais de duas sessões de navegador. Não acumule servidores em segundo plano nem lance enxames de agentes redundantes.

Playbooks de engenharia (pstack)

Esta skill permanece o roteador. Quando o plugin pstack de Lauren Tan estiver instalado, use seus playbooks para o método de engenharia dentro de uma tarefa. A maioria das skills pstack é apenas manual, então leia <pstack>/skills/<nome>/SKILL.md pelo caminho em vez de esperar que carreguem. Antes de seguir qualquer arquivo pstack, leia o adaptador para o seu harness uma vez por sessão; ele mapeia nomes de ferramentas, modelos e caminhos do Cursor.

Resolva <pstack> para o seu harness:

• Claude Code: ls -d ~/.claude/plugins/cache/cursor-plugins/pstack/*/ | sort -V | tail -1. Adaptador <pstack>/docs/harness/claude-code.md. Ficha de modelo ~/.claude/rules/pstack-models.md, carregada automaticamente.
• Codex: ls -d ~/.codex/plugins/cache/tinderbox-pstack/pstack/*/ | sort -V | tail -1. Adaptador <pstack>/docs/harness/codex.md. Ficha de modelo ~/.codex/pstack-models.md; leia antes de criar um modelo de papel.

Se nenhum dos caminhos existir, pstack não está instalado: trabalhe sem ele.

Formato da tarefa	Leia e siga
Defeito reportado	skills/poteto-mode/playbooks/bug-fix.md
Lentidão medida, ou uma métrica para melhorar	perf-issue.md, hillclimb.md
Vazamento, travamento ou falha; perfil capturado	runtime-forensics.md, trace-forensics.md
Novo comportamento; mudança apenas estrutural	feature.md, refactoring.md
Bifurcação empírica de design	prototype.md em vez de perguntar ao usuário
"Como/por que/temos certeza" apenas leitura	investigation.md, skills/how, skills/why
Mudança com alcance incerto	skills/blast-radius antes de editar
Benchmark ou alegação de aceleração	skills/benchmark-checklist antes de relatar
Um projeto sem prova de aplicação repetível	skills/create-verification-skill (pergunte uma vez)
Título, corpo, notas de versão do PR	skills/unslop após rascunhar

Os caminhos dos playbooks estão em <pstack>/skills/poteto-mode/playbooks/. Leia cada folha principle-* que um playbook cita antes de aplicá-la.

Estas regras vencem onde pstack difere:

• Entrega. Criação de PR, CI e revisões ficam com pr-follow-through e file-pr. Os playbooks opening-a-pr, babysit e shipping do pstack são apenas material de referência. Sua seção de autonomia não autoriza commits, pushes, merges, mensagens externas ou deploys além da solicitação atual.
• Recursos. A fan-out de arena, swarm, interrogate e architect é limitada a três subagentes a menos que o usuário peça mais. Faixas de escrita de código recebem sua própria worktree (isolation: "worktree" no Claude Code, git worktree add no Codex). Pule autopilot-full e orchestrate a menos que o usuário peça por nome.
• Modelos. As fichas de modelo mapeiam os papéis do pstack para modelos que o harness pode alcançar. Revisão entre provedores fica com council.
• Partes faltando do Cursor. cursor-team-kit não está instalado. Para /deslop use pr-review-toolkit:code-simplifier quando disponível; para control-ui use visual-qa e playwright-cli; para control-cli execute o CLI diretamente. Pule Bugbot, automações do Cursor e etapas de agente em nuvem com uma linha, como o adaptador diz.
• Estilo. As regras de resposta do pstack (frases curtas, sem travessões longos, rótulos de evidência) podem ser usadas como escritas. Mantenha sua reafirmação de objetivo na primeira mensagem em duas frases.

Finalizar

• Use pr-follow-through quando a solicitação incluir um PR ou correções de revisão.
• Faça commit, push, crie releases ou faça merge apenas quando a tarefa atual autorizar essa ação. Inspecione a automação de release do repositório primeiro; não assuma como os releases são feitos.
• Relate resultados reais: URLs, cenários testados, links de evidência, falhas e qualquer coisa que realmente precise da ação do usuário. Não diga que uma prévia, build de plataforma, release ou revisão passou sem verificar.
• Antes de um reset de contexto ou longa espera, deixe um handoff conciso fora do código rastreado, por exemplo .agent-artifacts/HANDOFF.md da tarefa. Inclua branch/worktree, objetivo, mudanças concluídas, comandos/resultados, SHA do PR/head, bloqueadores, arquivos próprios, nomes de recursos/sessão e a próxima ação exata. Nunca inclua tokens.
• Pare apenas servidores e sessões de navegador que você possuir. Mantenha evidências úteis e evite deletar worktrees não relacionadas, caches ou trabalho do usuário.