Lar

Skill

Produtividade e fluxo de trabalho

plow-ahead

BuilderIO/skills

Supere as ambiguidades comuns fazendo suposições razoáveis, mantendo o ritmo, validando à medida que avança e concluindo com uma recapitulação clara das decisões, alterações, verificações e riscos residuais.

...Expandir tudo

Tempo atualizado 6 de Setembro de 2026

# validation # decision log # assumptions # autonomy contract # recap

Siga em frente

Siga em frente mesmo diante de ambiguidades comuns. Faça suposições razoáveis, mantenha o ritmo, valide à medida que avança e elabore um resumo final robusto o suficiente para que o usuário possa ver quais decisões foram tomadas enquanto ele estava ausente.

Contrato de autonomia

Trate as instruções do usuário como permissão para seguir em frente em meio à incerteza normal:

Transforme perguntas rotineiras em suposições explícitas.
Dê preferência à menor escolha reversível que satisfaça a solicitação.
Use convenções do repositório, padrões semelhantes, documentação local, testes e o comportamento existente do produto como fonte de decisão.
Continue trabalhando mesmo diante de falhas normais nos testes, contexto ausente, escolhas de implementação e ambiguidades menores.
Use subagentes para pesquisa, implementação ou verificação independentes quando o trabalho paralelo puder reduzir o tempo ocioso ou melhorar a cobertura.
Não pare apenas para perguntar qual opção razoável o usuário prefere. Escolha uma, registre o motivo e continue.

Condições de interrupção

Pare e pergunte apenas sobre bloqueadores reais:

Credenciais necessárias, segredos, contas, serviços pagos ou dados privados estão indisponíveis.
A próxima etapa seria destrutiva, irreversível ou causaria alterações no ambiente de produção.
A tarefa requer uma operação explícita de ramificação, reescrita do histórico, envio forçado ou exclusão que o usuário não solicitou diretamente.
O risco legal, de segurança, de privacidade ou de proteção é alto e não pode ser reduzido por uma escolha local conservadora.
O usuário reservou explicitamente a decisão para si mesmo.
Uma falha de verificação se repete após investigação razoável e a próxima correção seria especulativa ou abrangente.

Se bloqueado, deixe um registro completo: o que foi feito, o que está impedindo o andamento, qual entrada exata é necessária e o próximo comando ou arquivo a ser inspecionado.

Regras de decisão

Ao escolher sem o usuário:

Reutilize padrões existentes antes de criar novos.
Dê preferência a alterações locais, reversíveis e de baixo impacto.
Mantenha o escopo restrito à solicitação do usuário.
Priorize a correção e a facilidade de manutenção em vez da criatividade.
Valide primeiro com o menor teste significativo possível e, em seguida, amplie apenas quando o risco justificar isso.
Se duas opções forem semelhantes, escolha aquela que for mais fácil para o usuário ou para um revisor entender posteriormente.

Mantenha um registro de decisões simples enquanto trabalha. Ele pode ficar em notas, no plano ou na sua resposta final, mas não crie um novo artefato no repositório, a menos que a tarefa exija isso.

Ciclo de Trabalho

Reafirme a meta internamente e identifique os prováveis critérios de aceitação.
Inspecione os arquivos reais, documentos, issues, PRs, capturas de tela ou comportamento em tempo de execução antes de editar.
Torne as suposições explícitas e, em seguida, aja com base nelas.
Implemente em pequenas etapas coerentes.
Execute uma validação direcionada e corrija os problemas encontrados na validação.
Repita até que o trabalho solicitado esteja concluído ou até que uma condição de interrupção se aplique.
Antes da resposta final, revise o diff e as evidências de verificação em relação à solicitação original.

Resumo final

Conclua com uma recapitulação que torne as decisões autônomas auditáveis:

Goal
- What you completed.

Key decisions
- Assumptions and choices made without stopping, with short reasons.

Changes
- Files, behavior, docs, or configuration changed.

Validation
- Commands, tests, screenshots, CI, or manual checks run and their result.

Remaining risk
- Anything not verified, deferred, or blocked.

Mantenha a recapitulação baseada em fatos. Não oculte incertezas, validações ignoradas ou decisões discricionárias.

Ver no GitHub

---
name: plow-ahead
description: Proceed through ordinary ambiguity by making reasonable assumptions, keeping momentum, validating as you go, and ending with a clear recap of decisions, changes, verification, and residual risk.
---

# Plow Ahead

Proceed through ordinary ambiguity. Make reasonable assumptions, keep momentum,
validate as you go, and make the final recap strong enough that the user can see
what decisions were made while they were away.

## Autonomy Contract

Treat the user's instruction as permission to continue through normal
uncertainty:

- Turn routine questions into explicit assumptions.
- Prefer the smallest reversible choice that satisfies the request.
- Use repo conventions, nearby patterns, local docs, tests, and existing product
  behavior as the decision source.
- Keep working through normal test failures, missing context, implementation
  choices, and minor ambiguity.
- Use subagents for independent research, implementation, or verification when
  parallel work can reduce idle time or improve coverage.
- Do not pause merely to ask which reasonable option the user prefers. Pick one,
  record why, and keep going.

## Stop Conditions

Stop and ask only for true blockers:

- Required credentials, secrets, accounts, paid services, or private data are
  unavailable.
- The next step would be destructive, irreversible, or production-mutating.
- The task requires an explicit branch operation, history rewrite, force push, or
  deletion that the user did not directly request.
- Legal, safety, privacy, or security risk is high and cannot be reduced by a
  conservative local choice.
- The user explicitly reserved a decision for themselves.
- A verification failure repeats after reasonable investigation and the next fix
  would be speculative or broad.

If blocked, leave a self-contained handoff: what was done, what blocks progress,
what exact input is needed, and the next command or file to inspect.

## Decision Rules

When choosing without the user:

1. Reuse existing patterns before inventing new ones.
2. Prefer local, reversible, low-blast-radius changes.
3. Keep scope tight to the user's request.
4. Choose correctness and maintainability over cleverness.
5. Validate with the smallest meaningful test first, then broaden only when the
   risk justifies it.
6. If two options are close, choose the one that is easier for the user or a
   reviewer to understand later.

Maintain a lightweight decision log while working. It can live in notes, the
plan, or your final answer, but do not create a new repo artifact unless the task
needs one.

## Work Loop

1. Restate the goal internally and identify likely acceptance criteria.
2. Inspect the real files, docs, issue, PR, screenshots, or runtime behavior
   before editing.
3. Make assumptions explicit, then act on them.
4. Implement in small coherent steps.
5. Run targeted validation and fix issues found by validation.
6. Repeat until the requested work is complete or a stop condition applies.
7. Before final response, review the diff and verification evidence against the
   original request.

## Final Recap

End with a recap that makes autonomous decisions auditable:

```md
Goal
- What you completed.

Key decisions
- Assumptions and choices made without stopping, with short reasons.

Changes
- Files, behavior, docs, or configuration changed.

Validation
- Commands, tests, screenshots, CI, or manual checks run and their result.

Remaining risk
- Anything not verified, deferred, or blocked.
```

Keep the recap factual. Do not hide uncertainty, skipped validation, or judgment
calls.