Lição 1 de 13: A primeira execução do /work

/workComando do Claude Code que executa um plano de fatia, tarefa por tarefa, pedindo aprovação a cada passo. é o comando do Claude Code que executa um plano de fatia, tarefa por tarefa. Os outros termos desta lição (fatia, plano, skill, stack) você viu nos módulos anteriores. Se esquecer algum, o Glossário fica numa aba ao lado.

Como começa a primeira fatia

Suponha que você acabou de escrever um plano de fatia no Módulo 2. Você abre o Claude e roda /work. O que acontece?

Pega um SaaS de recibos como exemplo: emite recibo pra autônomo, valida o CPF ou CNPJ do cliente, guarda no banco. O plano da primeira fatia (feat-recibos-foundation.md) listava 12 tarefas. A Phase 1.1 começava assim:

Tasks:

• Initialize git repo, pyproject.toml with uv, dependency groups
• Create docker-compose.yml — PostgreSQL 16 (pgvector/pgvector:pg16 image), pgAdmin
• Write sql/001_create_tables.sql — DDL das tabelas
• Create src/recibos/config.py with pydantic-settings
• ...

Success criteria: make setup starts PostgreSQL, creates all tables, and make down tears it down cleanly.

Você roda /work. O Claude propõe criar 6 arquivos de uma vez. Você para e aprova só o primeiro. Essa decisão, uma tarefa por aprovação, é o hábito que esta lição instala.

A regra: uma tarefa, uma aprovação

Cada execução do /work segue o mesmo ciclo:

1. O Claude lê o plano ativo em plans/.
2. Identifica a próxima tarefa pendente.
3. Propõe uma execução concreta (arquivos a criar/modificar, comandos a rodar).
4. Pede aprovação.

Você aprova uma tarefa por vez, não o plano inteiro. Quando algo der errado depois (e vai dar), você sabe em qual tarefa o bug entrou. Sem isso, você reabre 8 tarefas pra investigar uma.

O exercício desta lição é estabelecer esse ritmo. Você não vai escrever código aqui, só rodar /work uma vez, validar a proposta, tomar uma decisão.

O que /work faz, mecanicamente

/work é uma skill: o arquivo .claude/skills/plan-then-work/SKILL.md que o starter já trouxe na L04 do Módulo 1. Ela faz três coisas:

1. Lê o plano ativo: vai na pasta plans/ e identifica o feat-<algo>.md que não está em archive/. Se houver mais de um, pergunta qual.
2. Identifica a próxima tarefa pendente: lê a seção ## Task list do plano e cruza títulos com git log --oneline -20 pra estimar quais já saíram. Essa heurística não é infalível: se errar, você corrige na mão.
3. Propõe a execução dessa tarefa específica: quais arquivos vai criar/modificar, quais comandos vai rodar, e pede aprovação granular.

A aprovação fica granular: cada tarefa é uma decisão sua.

Passo 1 — Confirma que o plano está acessível

Cole no Claude:

Liste os arquivos da pasta de planos do projeto e diga qual está como plano ativo (não está em archive/).

A resposta deve listar pelo menos um feat-<algo>.md em plans/. Se vier vazio, o plano da L05 do Módulo 2 não foi gravado: volte na L05 e confirma que rodou git add + git commit.

Passo 2 — Roda /work

/work

A resposta vai parecer com este esboço (o output real do Claude costuma trazer mais raciocínio antes da proposta):

Lendo o plano ativo da fatia 1 (feat-pdf-recibo-MEI-sem-nfse.md)...

Plano identificado. Próxima tarefa pendente da Task list:

1. Schema da tabela "recibos": id, contador_id, cliente_cpf,
   valor_centavos, numero_sequencial, criado_em

Posso começar criando a migration?

Vou:
- Criar o arquivo de schema da tabela "recibos" no diretório
  de schemas do projeto (vou inferir o caminho do CLAUDE.md)
- Gerar a migration SQL correspondente
- Mostrar o diff antes de aplicar

Do you want to proceed? [y/n]

Os detalhes (nome da tabela, colunas, paths) refletem o que você escreveu no plano. Se a proposta do Claude diverge muito do plano, o plano está vago: volte na L05 do Módulo 2.

Passo 3 — Antes de aprovar, valide em 4 dimensões

Esta é a parte que costuma ser pulada. Antes de digitar y, leia a proposta com quatro perguntas:

1. Tarefa bate? A primeira tarefa que o Claude identificou bate com a primeira tarefa pendente da sua Task list? Se não, ele leu errado o plano ou interpretou o git log errado. Pergunte por quê.
2. Stack bate? Os arquivos e libs que ele vai usar batem com o CLAUDE.md do projeto? Se você definiu uma stack e o Claude propõe outra, algo está ambíguo. Se você não sabe qual ORM seu projeto usa, pergunte: "qual ORM esse projeto usa? Mostra o arquivo onde está configurado."
3. Função existe? Toda função, método ou import que o Claude propõe existe na versão da biblioteca que o projeto usa? Este é o check anti-alucinação mais importante. Dá pra verificar de duas formas, escolhe a mais rápida:
   • Pedir verificação ao Claude: "o método db.recibos.upsertMany que você propôs: confirma que ele existe na versão de Drizzle que está no projeto? Mostra o link da doc da versão exata."
   • Verificar manualmente: abre o arquivo de dependências do seu projeto (package.json pra Node, pyproject.toml pra Python, equivalente pra outras linguagens), anota a versão exata (ex: drizzle-orm@^0.30.10), e abre a doc oficial dessa versão. Se o método não aparece, é invenção.
4. Cabe numa execução? A proposta cabe em ~1 commit ou ~1 PR (conforme a regra da L05 do Módulo 2)? Se o Claude está empacotando 3 tarefas em uma, peça pra separar.

Se algo não bate, não aprove ainda. Responda com correção específica. Exemplo se o Claude inventou uma coluna:

Espera. A coluna "atualizado_em" que você propôs não está no Acceptance criteria do plano. De onde veio?

Três caminhos podem aparecer na resposta, e cada um pede um gesto diferente.

Passo 4 — Aprove a tarefa (não o plano)

Quando a proposta passa nas 4 perguntas, aprove digitando y. O Claude vai:

1. Criar/modificar os arquivos propostos
2. Mostrar diff
3. Pedir aprovação pra cada operação separadamente (cada Edit, cada Write, cada Bash fora do allowlist que você configurou na L09/M1)

Os comandos git add e git commit aparecem no final da tarefa, quando o Claude considera que terminou. A próxima tarefa do plano não roda automaticamente. Você precisa pedir /work de novo. Isso é de propósito: te força a olhar o resultado antes de seguir.

Se você rejeitar

Antes de fechar a sessão, registra a fricção no plano:

Adiciona uma seção "## Fricções" no fim do plano com 1 bullet: o que você propôs, por que rejeitei, e qual ajuste no plano precisaria pra evitar isso na próxima execução.

Isso vira input pra L12 (quando /work trava): você não está só pulando, está documentando.

Build Diary — onde a verificação salvou duas horas

Volta pra Phase 1.1 do recibos (feat-recibos-foundation.md). A tarefa 4 da lista era "Create src/recibos/config.py with pydantic-settings." Quando você pede /work nessa tarefa, o Claude propõe:

Vou criar src/recibos/config.py usando pydantic.BaseSettings com os campos DATABASE_URL, DOWNLOAD_DIR, e os timeouts.

Parece plausível. Mas você lembra que pydantic.BaseSettings migrou pra um pacote separado em pydantic v2: virou pydantic-settings. Olha o pyproject.toml: pydantic-settings = "^2.5". Então pede:

Espera. Em pydantic v2, BaseSettings não está mais em pydantic, e sim em pydantic_settings. Confirma o import correto antes de criar o arquivo.

O Claude voltou com from pydantic_settings import BaseSettings, o correto. Sem essa pergunta de 30 segundos, o config.py ia ser criado com import quebrado e o erro só apareceria quando você rodasse make setup. Dois minutos virariam vinte: debug, correção e commit extra.

Esse é o tipo de invenção maligna que parece plausível. A verificação anti-alucinação custa pouco e poupa horas.

Por isso o /work para a cada tarefa: cada passo precisa de uma verificação sua antes do próximo rodar.

Takeaways

• Aprove uma tarefa por vez, não o plano inteiro. Quando algo quebrar, você sabe onde.
• Antes de cada y, rode as 4 perguntas: tarefa bate, stack bate, função existe, cabe em uma execução.
• Invenções do Claude vêm em 3 tipos (benigna, arquitetural, maligna), e cada uma pede um gesto diferente. A maligna é a mais difícil de pegar e a mais cara se passar.
• A próxima tarefa do /work não roda sozinha. Pedir de novo é parte do ritmo.

Você terminou quando

Você rodou /work uma vez, leu a proposta, validou nas 4 dimensões, e tomou uma decisão consciente: aprovou, pediu refazer, ou registrou rejeição no plano.