xallindrome-labs/claude-code-ops

/runway

Objetivo: toda pergunta é feita agora, para que nada precise ser perguntado no turno 40. Depois disso, o usuário aprova um único plano e se afasta; seu telefone é notificado apenas em pontos de parada.

Regras básicas (o usuário pode ter suas próprias no CLAUDE.md; as dele prevalecem):

• Trabalho local e reversível (edições, builds, testes, comandos locais, commits em uma branch ou worktree) é executado sem permissão.
• Sempre pare para: push ou deploy, envio de qualquer mensagem, submissão de qualquer aplicação, gastar dinheiro, excluir dados, publicar qualquer coisa pública.
• Use modelos de subagente mais baratos para trabalhos pesados (buscas, execuções de teste, triagem de logs); use o modelo principal apenas para design e depuração difícil.

0. Pré-voo (silencioso, sem perguntas)

• Encontre a raiz do repositório e seu estado: git status, branch atual, um SPEC.md existente, scripts de teste e build (package.json, Makefile, etc.). Encontrar fatos é seu trabalho, não do usuário.
• Verifique se as aprovações por telefone estão ativas. Elas estão ativas se ~/.claude/settings.json tem um hook PermissionRequest executando phone-approve.js, ou se o hook deste plugin está habilitado, e ~/.claude/phone-approve.json existe. Caso contrário, informe o usuário uma vez (configuração: execute node "${CLAUDE_PLUGIN_ROOT}/hooks/phone-approve.js" --init, depois inscreva o aplicativo ntfy no tópico de solicitação daquele arquivo) e continue; os pontos de parada então recorrem ao diálogo da área de trabalho.
• Verifique se os comandos de ponto de parada são forçados a solicitar permissão, porque o modo automático pode aprová-los sem notificar. Procure nas configurações do usuário, do projeto e locais por regras permissions.ask (ou deny) cobrindo git push, comandos de deploy deste repositório (vercel, aws s3 sync, cdk deploy, npm publish, gh release, gh pr merge), e comandos de exclusão (rm -r, git clean, git branch -D). Se regras estiverem faltando, proponha as específicas, mostre o diff e adicione-as apenas se o usuário disser sim (o arquivo examples/permissions-ask.json do plugin é um ponto de partida). Nunca adicione regras allow para ferramentas de envio, publicação ou deploy, e nunca Bash(*).

1. Entreviste até que o especificação esteja completa

Se um skill grilling ou grill-me estiver instalado, chame-o e execute-o nesta funcionalidade; suas regras se aplicam integralmente. Caso contrário, realize a entrevista você mesmo da seguinte forma: pergunte em rodadas; cada rodada contém todas as perguntas cujos pré-requisitos já foram resolvidos, cada uma numerada, cada uma com sua resposta recomendada redigida de forma que "sim" a aceite. Aguarde as respostas, recalcule o que agora pode ser perguntado e repita. Pesquise fatos do ambiente você mesmo (use um subagente para buscas pesadas) e nunca pergunte ao usuário algo que você possa descobrir. Decisões são do usuário.

Se o usuário já realizou uma sessão de grilling nesta funcionalidade anteriormente na conversa e confirmou entendimento compartilhado, não a repita: reutilize as respostas e pergunte apenas sobre itens da lista de verificação abaixo que ficaram em aberto.

Continue até que nada fique em aberto em todos os itens:

1. Objetivo: uma ou duas frases, o resultado visível para o usuário.
2. Escopo: o que mudará (áreas, arquivos, superfícies).
3. Fora do escopo: o que não deve ser tocado.
4. Critérios de aceitação: uma lista de verificação onde cada item pode ser comprovado como verdadeiro pela saída de um comando.
5. Comando de verificação: exatamente um comando cujo código de saída 0 significa pronto (por exemplo npm run lint && npm test && npm run build). Se nenhum existir, a especificação inclui escrevê-lo como a primeira tarefa.
6. Pontos de parada: quais dos itens push / deploy / send / submit / spend / delete / publish esta funcionalidade atingirá, e o que o usuário espera em cada um (por exemplo "faça push da branch, abra um PR, não faça merge").
7. Decisões que você tomaria durante a tarefa: bibliotecas, nomes, formatos de dados, texto, comportamento em casos extremos. Pergunte agora, com uma recomendação.
8. Limite de turnos (padrão 60) e qualquer preocupação orçamentária.

Não avance até que o usuário confirme entendimento compartilhado.

2. Escreva SPEC.md e faça commit localmente

Escreva SPEC.md na raiz do repositório:

# <nome da funcionalidade>
## Objetivo
## Escopo
## Fora do escopo
## Critérios de aceitação
- [ ] ...
## Comando de verificação
`<um comando>`
## Pontos de parada
| Ação | Tratamento esperado |
## Decisões já tomadas
## Limite de turnos
60

Crie uma branch (git switch -c runway/<slug>), ou use uma worktree quando outras sessões estiverem editando a mesma pasta, então faça commit apenas de SPEC.md. Isso é local e reversível; não pergunte. Nunca faça push.

3. Aprovação de um plano

Entre no modo de plano e apresente um único plano: etapas ordenadas, quais etapas vão para subagentes (e em qual modelo), o comando de verificação e os pontos de parada com seu tratamento esperado. Esta é a única aprovação antes da execução. Use ExitPlanMode e peça ao usuário para escolher "Sim, e usar modo automático". (O hook de telefone deliberadamente ignora a aprovação do plano, então o usuário faz isso no computador.)

Se o modo automático não estiver ativo após a aprovação, diga isso e peça ao usuário para ativá-lo. Não execute o loop no modo manual.

4. Execute sob /goal com um limite de turnos

Comandos de barra internos não podem ser invocados pelo modelo, então termine a etapa anterior fornecendo ao usuário uma linha para colar (preencha o comando real e o limite):

/goal <comando de verificação> sai com 0, todo critério de aceitação em SPEC.md está marcado como concluído com evidências na transcrição, e nada na lista de fora do escopo do SPEC.md foi tocado, ou pare após 60 turnos

Se a sessão já estiver executando um goal, /goal o substitui. O avaliador vê apenas a transcrição, então, durante o trabalho: execute o comando de verificação com frequência, imprima seu resultado e marque os critérios do SPEC.md com evidências. Relate o progresso em relação ao limite de turnos a cada turno.

Durante a execução:

• Não faça perguntas. Se algo não especificado surgir, escolha a opção mais próxima da especificação, registre-a em "Decisões já tomadas" e continue. Pare para uma pergunta apenas quando prosseguir atingiria um ponto de parada ou contradiria a especificação.
• Faça commits em commits pequenos na branch runway. Nunca faça push sem uma aprovação de ponto de parada.
• Em um ponto de parada, faça a chamada normalmente; o prompt de permissão é o que notifica o telefone. Se for negado, não tente outra forma: registre-o, termine o que não precisa dele e relate.
• Se 3 turnos consecutivos não fizerem progresso, pare e relate o que o bloqueou.

5. Finalize

Quando a verificação passar (ou o limite for atingido), relate nesta ordem:

1. Resultado: pronto / parcialmente pronto / bloqueado, além da branch e qualquer link de PR.
2. Estatísticas de diff (git diff --stat <base>...HEAD).
3. Verificado: critérios comprovados, com o comando e resultado.
4. Não verificado: critérios não comprovados ou apenas parcialmente; qualquer coisa ignorada ou negada em um ponto de parada.
5. Subagentes usados, em qual modelo e onde um modelo menor teve pior desempenho.
6. Turnos e custo aproximado usados em relação ao limite.