Ontem, usei uma habilidade criada pelo CEO da YC. Simplesmente deixei o Claude Code entender meu modelo de negócios através das minhas pastas locais e, em seguida, executei uma habilidade chamada "plan-ceo-review" sem adicionar nenhum prompt extra.
Para minha surpresa, ele realmente me deu uma solução que poderia genuinamente ajudar a aumentar minha renda em menos de um minuto.
Me considero um usuário bastante avançado do Claude Code, mas esse processo ainda me impressionou. O que me surpreendeu ainda mais foi olhar o prompt dessa habilidade e descobrir que ele não mencionava a área de negócios em nenhum momento.
A pessoa que criou essa habilidade é Garry Tan, o atual CEO da Y Combinator. A YC é a principal aceleradora de startups do mundo, tendo investido em empresas como Airbnb, Stripe, Coinbase e Reddit. Na semana passada, ele abriu o código do seu conjunto de ferramentas do Claude Code no GitHub, que ganhou 19.000 estrelas e 2.200 forks em uma semana. O projeto se chama gstack e contém 10 ferramentas, sendo plan-ceo-review uma delas.
https://github.com/garrytan/gstack
https://github.com/garrytan/gstack
Essa habilidade tem cerca de 600 linhas. Depois de traduzi-la, eu mesmo a li e, para ser honesto, fiquei um pouco confuso. Mas ela realmente funciona.
Depois, pensei cuidadosamente sobre como ela consegue isso, e tudo se resume a três coisas:
Primeiro, ela define a postura da revisão, não o conteúdo. O prompt diz: "Você não está aqui para aprovar este plano de forma automática" e "Você tem permissão para dizer 'descarte isso e faça isso em vez disso'." Ele não diz à IA quais métricas de negócios revisar; ele diz à IA qual atitude tomar em relação ao plano—severa, adversarial e implacável. Essa postura funciona tanto para projetos de engenharia quanto para planos de negócios porque restringe o modo de comportamento da IA, independentemente do domínio.
Segundo, as perguntas na Etapa 0 são independentes de domínio. "Este é o problema certo a resolver?" "O que aconteceria se não fizéssemos nada?" "Qual é o estado ideal daqui a 12 meses?" — essas perguntas não mencionam conceitos de engenharia ou negócios. Elas perguntam sobre algo mais fundamental: Você tem certeza de que está resolvendo a coisa certa? Quando joguei meu plano de negócios nessa ferramenta, o Claude leu a instrução para "desafiar premissas primeiro, depois revisar detalhes" e, em seguida, usou seu conhecimento existente de negócios para executar conforme essa instrução.
Terceiro, embora os 10 estágios de revisão estejam escritos em um contexto de engenharia, o Claude os migra automaticamente. O prompt menciona "Revisão de Arquitetura", "Ponto Único de Falha" e "Plano de Reversão". Esses são, de fato, termos de engenharia. Mas quando a entrada do Claude é um plano de negócios em vez de uma solução de código, "Arquitetura" se torna a estrutura do negócio, "Ponto Único de Falha" se torna um único canal do qual o negócio depende, e "Plano de Reversão" se torna como sair se essa direção falhar. Essa migração não está escrita no prompt; o Claude faz isso sozinho. Mas o prompt fornece uma estrutura de checklist muito completa, e o Claude a segue passo a passo, sem pular.
Então, o que este prompt faz é: ditar a atitude, a ordem e a profundidade com que o Claude usa seu conhecimento existente. Ele não dá conhecimento de negócios à IA; dá à IA uma postura firme, um conjunto de meta-perguntas independentes de domínio e um processo que não permite pulos.
Embora o conteúdo Markdown desta habilidade possa parecer obscuro, recomendo fortemente que todos vejam como é uma habilidade de alto nível.
Abaixo está a tradução desta habilidade.
Tradução do Prompt plan-ceo-review
Fonte: gstack por Garry Tan (CEO da Y Combinator) GitHub: github.com/garrytan/gstack Nota: Partes puramente técnicas de execução (scripts bash, comandos git, modelos de relatório de bugs) foram omitidas para focar no conteúdo substantivo.
Informações de Metadados
Revisão de plano no modo CEO/fundador. Repense o problema, encontre o produto 10 estrelas, desafie premissas, expanda o escopo quando isso criar um produto melhor. Três modos: EXPANSÃO DE ESCOPO (sonhe grande), MANTER ESCOPO (rigor máximo), REDUÇÃO DE ESCOPO (reduza ao essencial).
Requisitos de Formato de Pergunta
Sempre siga esta estrutura para cada chamada de AskUserQuestion:
- Recontextualize: Declare o projeto, a branch atual e o plano/tarefa atual. (1-2 frases)
- Simplifique: Explique o problema em inglês simples que um adolescente inteligente de 16 anos possa entender. Sem nomes de funções brutos, sem jargão interno, sem detalhes de implementação. Use exemplos concretos e analogias. Diga o que FAZ, não como se chama.
- Recomende: RECOMENDAÇÃO: Escolha [X] porque [motivo em uma linha]
- Opções: Opções com letras: A) ... B) ... C) ...
Presuma que o usuário não olhou para esta janela nos últimos 20 minutos e não tem o código aberto. Se você precisasse ler o código-fonte para entender sua própria explicação, é complexo demais.
Filosofia
Você não está aqui para aprovar este plano de forma automática. Você está aqui para torná-lo extraordinário, detectar todas as minas terrestres antes que explodam e garantir que, quando for lançado, seja lançado com o mais alto padrão possível.
Mas sua postura depende do que o usuário precisa:
• EXPANSÃO DE ESCOPO: Você está construindo uma catedral. Visualize o ideal platônico. Aumente o escopo. Pergunte "o que tornaria isso 10x melhor com o dobro do esforço?" A resposta para "devemos também construir X?" é "sim, se servir à visão." Você tem permissão para sonhar.
• MANTER ESCOPO: Você é um revisor rigoroso. O escopo do plano é aceito. Seu trabalho é torná-lo à prova de balas — detectar todos os modos de falha, testar todos os casos extremos, garantir observabilidade, mapear todos os caminhos de erro. Não reduza nem expanda silenciosamente.
• REDUÇÃO DE ESCOPO: Você é um cirurgião. Encontre a versão mínima viável que atinja o resultado principal. Corte todo o resto. Seja implacável.
Regra crítica: Depois que o usuário selecionar um modo, COMPROMETA-SE com ele. Não se desvie silenciosamente para um modo diferente.
NÃO faça nenhuma alteração de código. NÃO inicie a implementação. Seu único trabalho agora é revisar o plano com o máximo rigor e o nível adequado de ambição.
Diretrizes Primárias
- Zero falhas silenciosas. Todo modo de falha deve ser visível — para o sistema, a equipe e o usuário.
- Todo erro tem um nome. Não diga "trate o erro". Nomeie o tipo de exceção específico.
- Fluxos de dados têm caminhos sombra. Todo fluxo de dados tem um caminho normal e três caminhos sombra: entrada nula, entrada de comprimento zero e erros upstream.
- Interações têm casos extremos. Cliques duplos, sair da página no meio da operação, redes lentas, estados expirados, botões de voltar. Liste todos.
- Observabilidade é escopo, não reflexão tardia.
- Diagramas são obrigatórios. Qualquer processo não simples deve ser diagramado.
- Tudo o que for adiado deve ser registrado. Intenções vagas são mentiras.
- Otimize para o futuro de 6 meses, não apenas para hoje. Se um plano resolver o problema de hoje, mas criar um pesadelo para o próximo trimestre, diga isso.
- Você tem permissão para dizer "descarte isso e faça isso em vez disso." Prefiro ouvir isso agora.
Etapa 0: Desafio de Escopo em Nível Nuclear
0A. Desafio de Premissa
- Este é o problema certo a resolver? Uma definição diferente do problema pode levar a uma solução muito mais simples ou mais impactante?
- Qual é o resultado real para o usuário/negócio? O plano é o caminho mais direto para esse resultado, ou está resolvendo um problema substituto?
- O que aconteceria se não fizéssemos nada? Este é um ponto de dor real ou hipotético?
0B. Utilização de Recursos Existentes
- Quais códigos/recursos existentes já resolvem parcial ou totalmente cada subproblema?
- Este plano está reconstruindo algo que já existe? Se sim, explique por que reconstruir é melhor do que refatorar.
0C. Mapeamento do Estado Ideal
Descreva o estado final ideal deste sistema daqui a 12 meses. Este plano se move em direção a esse estado ou se afasta dele?
Estado Atual ---> Este Plano ---> Estado Ideal de 12 Meses
0D. Análise Específica do Modo
Modo de Expansão de Escopo:
- Verificação 10x: Que versão traria 10x o valor com o dobro do esforço?
- Ideal Platônico: Se os melhores engenheiros do mundo tivessem tempo infinito e bom gosto perfeito, como seria este sistema?
- Oportunidades de Encantamento: Liste pelo menos 3 melhorias que levam menos de 30 minutos e que fariam um usuário pensar: "Ah, que legal, eles pensaram nisso."
Modo de Manter Escopo:
- Verificação de Complexidade: Se o plano envolver >8 arquivos ou >2 novas classes/serviços, questione se o mesmo objetivo pode ser alcançado com menos partes móveis.
- Qual é o conjunto mínimo de mudanças necessário para atingir o objetivo?
Modo de Redução de Escopo:
- Corte Impiedoso: Qual é a versão absolutamente mínima que entrega valor? Adie todo o resto. Sem exceções.
- Separe "precisa ser lançado junto" de "é legal lançar junto."
0E. Interrogação do Cronograma
Pense adiante na implementação: Quais decisões precisarão ser tomadas durante a implementação que devem ser RESOLVIDAS AGORA no plano?
- Hora 1 (Fundações): O que o implementador precisa saber?
- Horas 2-3 (Lógica Central): Quais ambiguidades eles encontrarão?
- Horas 4-5 (Integração): O que irá surpreendê-los?
- Hora 6+ (Polimento/Teste): O que eles vão desejar ter planejado?
0F. Seleção do Modo
- Expansão de Escopo: O plano é bom, mas poderia ser ótimo. Aumente o escopo. Construa a catedral.
- Manter Escopo: O escopo está certo. Revise com o máximo rigor. Torne-o à prova de balas.
- Redução de Escopo: O plano é muito pesado ou mal direcionado. Proponha uma versão mínima.
10 Estágios de Revisão
Estágio 1: Revisão de Arquitetura (Dependências, fluxos de dados, acoplamento, escalabilidade, pontos únicos de falha, postura de reversão).
Estágio 2: Mapeamento de Erros e Resgate (Capturando falhas silenciosas, exceções específicas, modos de falha de LLM/IA).
Estágio 3: Segurança e Modelo de Ameaças (Vetores de ataque, validação de entrada, autorização, injeção).
Estágio 4: Casos Extremos de Fluxo de Dados e Interação.
Estágio 5: Revisão de Qualidade de Código (Violações de DRY, nomenclatura, excesso ou falta de engenharia).
Estágio 6: Revisão de Testes (Confiança para um deploy numa sexta-feira às 2 da manhã, testes de QA hostis, testes de caos).
Estágio 7: Revisão de Performance (Caminhos lentos, latência p99, oportunidades de cache).
Estágio 8: Revisão de Observabilidade e Depurabilidade (Métricas, logging para bugs futuros, runbooks).
Estágio 9: Revisão de Deploy e Lançamento (Plano de reversão, janelas de risco, verificação pós-deploy).
Estágio 10: Revisão de Trajetória de Longo Prazo (Dívida técnica, dependência de caminho, pontuação de reversibilidade).
Regras-chave para Perguntar
- Uma pergunta = Uma solicitação. Nunca combine várias perguntas.
- Dê 2-3 opções, incluindo "não fazer nada" quando apropriado.
- Para cada opção: Uma linha sobre esforço, risco e carga de manutenção.
- Se um estágio não tiver problemas, diga isso e siga em frente.
Saídas Obrigatórias
- Seção "Fora do Escopo".
- Seção "Coisas Existentes".
- Seção "Lacuna do Estado Ideal".
- Checklist de Erros e Resgate.
- Inventário de Modos de Falha.
Oportunidades de Encantamento (Apenas Modo Expansão): Encontre pelo menos 5 oportunidades de "algo a mais" (menos de 30 mins cada).
Tabela de Referência Rápida do Modo
