Skill ou app — o que fazer quando o trabalho se repete

O sinal das três vezes

Antes de construir qualquer coisa, confirme que existe processo. Se você reconhece dois destes, existe.

• Você reabre uma conversa antiga só para copiar o prompt de lá
• Você explica o mesmo contexto toda vez, do zero
• O resultado sai diferente e você conserta na mão, sempre do mesmo jeito
• Alguém te pediu "faz aquilo que você fez pra mim"
• Você já tem uma pasta com o modelo de como o resultado tem que ficar

Uma vez é tarefa. Duas é coincidência. Na terceira, você não está mais trabalhando — está repetindo. E repetição é a única coisa que vale a pena construir.

A pergunta que decide

A pergunta não é "qual é melhor". É esta: o resultado pode variar?

E quase sempre começa na skill. O app vem depois, quando a skill já rodou em casos reais e provou que o processo está certo. Não é etapa burocrática — é o que evita você congelar em código um processo que ainda estava errado.

Como construir a skill

O processo inteiro leva uns vinte minutos. A parte difícil é a primeira, e ela não é técnica.

1. Faça o trabalho inteiro uma vez, do jeito difícil. Não tente escrever a skill antes. Você ainda não sabe o processo — você acha que sabe. Ele só aparece quando você tropeça nele.

2. No fim, peça para a própria IA escrever. A conversa que acabou de acontecer é o rascunho da skill. Não jogue fora.

Pega tudo o que a gente acabou de fazer e transforma num passo a passo
que sirva para o próximo caso, não só para este.

Tira o que era específico deste caso — nome, números, datas. Deixa só o
processo. Onde eu te corrigi no meio do caminho, escreve isso como regra,
porque foi ali que eu te ensinei alguma coisa.

No fim, me diz em que ponto você ficou na dúvida sobre o que eu queria.

3. Corte o específico. Nome do cliente, valor, data, o arquivo daquele dia — fora. O que sobra depois do corte é o processo. Se sobrou pouca coisa, você não tinha um processo: tinha um pedido.

4. Escreva o gatilho. Essa é a peça que quase todo mundo erra. O gatilho é o que faz a skill se lembrar de si mesma — sem ele, você tem um documento que precisa ser invocado à mão, o que é o mesmo que não ter nada. Escreva as frases que você realmente fala, não as que soam bem.

5. Salve no lugar certo. Uma pasta com o nome da skill, e dentro dela um arquivo SKILL.md:

---
name: dashboard-da-clinica
description: Use quando pedirem para transformar o PDF de planejamento
  tributário de uma clínica em dashboard. Dispara com "gera o dashboard",
  "monta o dashboard pra clínica", ou quando apontarem para um arquivo
  chamado PLANEJAMENTO TRIBUTÁRIO.
---

# O que essa skill faz
Uma frase. Se você não consegue escrever em uma, o processo ainda
está confuso.

# Passo a passo
1. ...
2. ...
3. ...

# Regras que eu aprendi errando
- ...

# O que conferir antes de entregar
- ...

O description vale mais que o resto do arquivo. É a única parte que é lida o tempo todo — é ela que decide se a skill acorda. Passo a passo ruim você conserta na hora; gatilho ruim você nunca descobre, porque a skill simplesmente nunca dispara.

6. Teste no próximo caso real. Não num caso inventado para testar. Caso inventado sempre passa — foi você que inventou.

7. Quando errar, corrija a skill, não o resultado. Essa é a regra que separa quem tem uma skill de quem tem um arquivo parado. Você vai sentir preguiça: é mais rápido consertar a entrega e seguir. Consertou o resultado três vezes seguidas? A skill está errada, e você acabou de pagar três vezes pelo mesmo conserto.

Como construir o app

Se a skill já roda, metade do app está escrita — o passo a passo dela é a especificação.

1. Escreva a entrada e a saída, uma frase cada. Antes de qualquer tela, qualquer framework, qualquer decisão técnica.

Entra: um PDF de planejamento tributário de uma clínica.
Sai:   uma página HTML com os cenários de faturamento e os números,
       pronta para mandar para o cliente.

Se você não consegue escrever essas duas linhas, não é hora de app. Volte para a skill.

2. Trave o formato da saída. O modelo do resultado é seu, escrito à mão, com os buracos marcados. A IA preenche os buracos — ela não decide a forma. É aqui que nasce o controle sobre o resultado final: o que está no template não varia nunca mais.

3. Faça a versão feia primeiro. Uma pasta, um comando, roda na sua máquina. Sem tela, sem login, sem banco, sem nome bonito. A versão feia é a que ensina o que o app precisa ter — e ela fica pronta na mesma tarde.

4. Use nos próximos casos reais. Uns cinco, dez. É neles que aparecem os casos que você não tinha previsto — e é muito mais barato descobrir isso antes de existir tela.

5. Só então coloque a tela. Quando você já sabe exatamente o que entra e o que sai, a tela leva uma tarde. Quando você começa por ela, leva um mês e ainda muda tudo depois.

6. Por último: link, login e cobrança. Nessa ordem, e só se outra pessoa realmente for usar.

A ordem importa mais que a tecnologia. Quase todo app que morre no meio, morre porque começou pela tela. A tela é a parte gostosa de fazer — e é a única que não decide nada.

Onde mora o controle

Skill e app não mudam o que a IA sabe. Mudam quanto ela pode decidir.

Cada degrau tira uma decisão da IA e traz para você. É só isso — não tem mágica, e não tem modelo melhor no meio do caminho. O resultado para de variar porque você parou de deixar variar.

E cada decisão que você tira dela, você passa a ter que tomar. Esse é o preço, e ele é real: uma skill você reescreve em dez minutos, um app é seu para sempre — para consertar, atualizar e explicar quando quebrar. Subir um degrau cedo demais custa caro.

As quatro armadilhas

Escrever a skill antes de fazer o trabalho. Sai um texto bonito que não descreve nada, porque você documentou o que imagina que faz — não o que faz. Faça primeiro, escreva depois. Sempre nessa ordem.

Skill larga demais. "Me ajuda com contabilidade" não dispara nunca e não decide nada. Skill boa é estreita a ponto de parecer pequena: um trabalho, um resultado, um gatilho. Três skills estreitas valem mais que uma que tenta cobrir tudo.

Corrigir o resultado em vez da skill. Você conserta o mesmo detalhe pela quinta vez, no piloto automático, e a skill continua errada — ainda vai te dar trabalho na sexta. Toda correção que você faz duas vezes é uma linha que faltou no arquivo.

Pular direto para o app. A mais cara das quatro. Você congela em código um processo que ainda estava errado, e agora consertar não custa dez minutos: custa uma refatoração. A skill é barata de jogar fora — é para isso que ela serve primeiro.