Os comandos
Um comando por fase. Nenhum deles decide alguma coisa por você: os de documento são entrevistas — uma pergunta por vez, você responde, o agente organiza e escreve.
Fase 0, uma vez por projeto
Seis comandos, nesta ordem. Cada linha termina numa decisão sua, e cada passo só começa com o anterior commitado — os comandos conferem isso e param se faltar.
| Comando | O que produz | O que você faz |
|---|---|---|
/utf-prd |
docs/prd.md — glossário, atores, histórias, regras de negócio |
Lê inteiro, ajusta e commita; leva o tema ao professor |
/utf-backlog |
Uma Issue por história Ready, mais o roteiro do Kanban |
Aprova a lista antes de as Issues serem criadas |
/utf-flows |
docs/user-flows.md — as jornadas e os pontos de desistência |
Decide o que acontece em cada ponto de desistência e commita |
/utf-design |
docs/design-tokens.md — paleta, espaçamento, tipografia e o protótipo |
Decide os tokens e commita |
/utf-architecture |
docs/architecture.md — estrutura, entidades, estados, contratos |
Lê e commita |
/utf-setup |
apps/ — o monorepo, com a suíte de testes verde e vazia de regras |
Ratifica as decisões e abre o primeiro PR, com a etiqueta manutencao |
O /utf-backlog roda mais de uma vez. A cada leva de
histórias promovidas a Ready no PRD, rode de novo para criar as Issues
correspondentes. Os outros cinco rodam uma vez só.
Uma vez por história
| Comando | Quando | O que acontece |
|---|---|---|
/utf-issue 27 |
No começo e no fim da história | Na primeira vez, cria a branch, faz as perguntas, escreve a spec e — depois da sua aprovação — o plano. Rodado de novo com o plano terminado, atualiza os documentos e despacha o auditor-final para o PR. Rodado no meio, retoma de onde parou. |
/utf-task 1 |
Uma vez por tarefa do plano | Roda o ciclo inteiro da tarefa: tutor, implementador, dois revisores, triagem, leitura do diff e commit. Devolve o controle a você no fim. |
/utf-task |
Sem número | Executa a próxima tarefa pendente do plan.md e avisa quando não houver
mais nenhuma. |
O tutor, do começo ao fim
O tutor não escreve código, não corrige nada e não opina sobre qualidade. Ele tem uma função só: te ensinar o que acabou de ser feito, para você chegar na defesa sem precisar dele.
| Comando | Quando | A pergunta que ele responde |
|---|---|---|
/utf-tutor prd, flows, design, architecture |
Na Fase 0, antes de commitar cada documento | O que essas decisões significam tecnicamente, no meu documento? |
/utf-tutor setup |
Depois do scaffold (o /utf-setup já chama sozinho) |
O que são todos esses arquivos que eu não escrevi? |
/utf-tutor spec |
Antes de aprovar a spec | O que essa decisão me obriga a fazer depois? |
| automático | Antes de cada tarefa, dentro do /utf-task |
O que essa tarefa vai construir, com quais conceitos, e o que eu procuro no diff? |
/utf-tutor passo 3 |
Antes do commit (o /utf-task já chama sozinho) |
A leitura do diff arquivo por arquivo, no seu ritmo. |
/utf-tutor 3 |
Depois de uma tarefa | O que esse diff faz e por que assim? Ele também devolve o nome oficial dos conceitos que apareceram e três perguntas que um professor poderia fazer. |
/utf-tutor antes 3 |
Para reouvir | A explicação pré-implementação daquela tarefa, de novo. |
/utf-tutor prova |
Antes de escrever o PR | O simulado da defesa: uma pergunta por vez, com correção das suas respostas e a lista de arquivos para reler. |
O tutor não pode ser usado durante a defesa. Ele existe para você chegar lá sem precisar dele. Se você não souber responder às três perguntas que ele faz no fim, o trabalho daquela tarefa ainda não acabou.
O que precisa estar configurado
O /utf-backlog, o /utf-setup e cada /utf-issue
falam com o GitHub. Para eles funcionarem você precisa do gh autenticado, com
os escopos repo, workflow e project:
gh auth login
O MCP do GitHub resolve do mesmo jeito, se você preferir. Sem um dos dois, backlog, etiquetas e Pull Requests não saem. Com o MCP Context7 disponível, os fluxos conferem as versões das ferramentas na documentação atual antes de decidir a stack.
Falar também funciona
Dizer “vamos trabalhar na Issue 27” em português dispara o mesmo fluxo — as regras do projeto mandam o agente abrir o workflow correspondente. Os comandos com barra são só o caminho mais curto e o que menos deixa margem para o agente entender outra coisa.