Como usar o /office-hours do gstack para destravar o que você está construindo

Fala aí, beleza? Aquele momento em que tu tem uma ideia na cabeça, abre o editor e trava porque não sabe se aquilo merece uma linha de código sequer

É desconfortável, né? 🙂

A gente costuma resolver isso do jeito errado: abre um chat em branco, joga a ideia lá e recebe de volta um monte de elogio educado

O /office-hours propõe outra coisa

Ele é uma skill do garrytan/gstack, repositório de titularidade da conta garrytan, o perfil de Garry Tan, President & CEO da Y Combinator, conforme publicação do perfil oficial da própria YC

A documentação apresenta a skill como o lugar onde começar: ela expõe as suposições ANTES de qualquer código ser escrito

Neste post tu vai ver como rodar o comando passo a passo, o que ele cobra de você e em que momento do projeto ele rende muito mais que um prompt em branco

Bora?

Formação Recomendada

Formação Vibe Coding

Do Prompt ao Produto: Crie Software Real com IA

• 474 aulas
• 20 projetos
• 39h 27min

Conhecer formação

O que você precisa antes de rodar o /office-hours

O mínimo aqui é curto, e isso é uma boa notícia

• Claude Code instalado, porque o gstack é um conjunto de skills pra ele
• git disponível na máquina, já que a instalação documentada é por clone do repositório
• o gstack clonado na pasta de skills do Claude Code (o comando vem no próximo bloco)

Nada de PC da Nasa, calma 😀

Duas coisas que valem tu saber antes de mexer:

O projeto é open source sob licença MIT

E o repositório foi criado em 11 de março de 2026, ou seja, tu está lidando com algo recente, que nasceu ontem no calendário de ferramenta madura

Isso muda a expectativa: aqui a régua é entender o que a skill FAZ, não decorar um fluxo que existe há anos

Como usar o /office-hours passo a passo

1. Instale o gstack pelo comando documentado no README

A instalação oficial é o clone direto na pasta de skills:

git clone --single-branch --depth 1 https://github.com/garrytan/gstack.git ~/.claude/skills/gstack && cd ~/.claude/skills/gstack && ./setup

Traduzindo o que essa linha faz: um clone raso (uma branch só, sem arrastar histórico) direto pra pasta de skills do Claude Code, e na sequência ela entra nessa pasta e executa o ./setup que vem no próprio repositório, tudo de uma vez, do jeito que o README documenta

O erro comum deste passo: sair caçando instalação alternativa em tutorial de terceiro e acabar em um wrapper que não é o repositório oficial

Se tu quer o gstack, clona o gstack

2. Acione a skill

Dá pra chamar direto pelo comando /office-hours

Mas a skill também define gatilhos textuais de invocação, se liga nisso: ela aciona em pedidos como "brainstorm this", "I have an idea", "help me think through this", "office hours" e "is this worth building"

E tem mais: a documentação diz que ela deve ser invocada proativamente quando a pessoa descreve uma ideia de produto ainda sem código

O erro comum deste passo: achar que só o slash command vale e ficar frustrado quando a skill aparece "sozinha" no meio de uma conversa

Ela foi feita pra isso mesmo

3. Escolha o modo

São dois, e a escolha muda o papo inteiro:

O erro comum deste passo: entrar no startup mode com um projetinho de fim de semana e sair de lá desanimado sem motivo

Se é hackathon ou aprendizado, o builder mode existe justamente por isso

4. Descreva o que você está construindo com especificidade

Aqui é o filtro de verdade

A documentação afirma que especificidade é a única moeda

Respostas vagas são devolvidas pra refinamento: especificidade é tratada como critério de aceite, não como sugestão simpática

O erro comum deste passo: responder "desenvolvedores que sofrem com produtividade"

Isso não é um usuário, isso é um slide 😛

5. Passe pelos seis eixos do modo startup

O modo startup aplica seis perguntas forçadas, destiladas de como os partners da YC avaliam produtos:

• demand reality (realidade da demanda)
• status quo (o que a pessoa faz hoje)
• desperate specificity (especificidade desesperada)
• narrowest wedge (a cunha mais estreita)
• observation & surprise (observação e surpresa)
• future-fit (encaixe no futuro)

Repara que nenhum desses eixos pergunta qual framework tu vai usar

São perguntas sobre gente, não sobre stack

O erro comum deste passo: tratar os seis eixos como formulário pra despachar rápido

Quanto mais tu se apressa aqui, menos o documento final vale

6. Recupere o design doc

Os dois modos terminam gravando um design doc em ~/.gstack/projects/

Esse arquivo é a saída real da sessão, não o papo na tela

O erro comum deste passo: fechar o terminal achando que a conversa ficou pra trás e nunca abrir a pasta

7. Encadeie com o planejamento

O documento gerado é consumido por outras skills do próprio gstack: ele alimenta /plan-ceo-review e /plan-eng-review

E o README traz um fluxo de exemplo bem direto:

Load gstack. Run /office-hours then /autoplan

Ou seja: pensar primeiro, planejar depois, construir por último

Em que momento do projeto o /office-hours rende mais que um prompt em branco

Essa é a pergunta que interessa, porque skill boa na hora errada não ajuda ninguém

Quando a ideia ainda não tem uma linha de código. É o cenário que a própria documentação nomeia: a skill é o lugar onde começar, expondo suposições antes de qualquer código ser escrito

Quando o projeto travou porque ninguém definiu quem é o usuário. Acontece MUITO em projeto que já tem três semanas de commits. Aí o eixo status quo (o que a pessoa faz hoje) faz um estrago saudável

Quando tu está decidindo entre escopo largo e cunha estreita. O eixo narrowest wedge existe pra isso, e é o tipo de decisão que a gente adia empurrando feature pra frente

Quando é projeto paralelo ou hackathon. Aqui o builder mode faz mais sentido que o startup: ele é voltado a projetos paralelos, hackathons, aprendizado e open source

Quando tu não consegue nomear um humano específico que precisa do produto. A documentação é dura nisso, e com razão: não conseguir nomear esse humano é o aprendizado mais importante antes de escrever código

Doeu? Ótimo, doeu barato

Agora compara com jogar a ideia solta no chat

No prompt em branco tu recebe texto, fecha a aba e amanhã não sobra nada

No /office-hours a saída é estruturada e vira documento em ~/.gstack/projects/, que as skills de planejamento leem depois

É a diferença entre conversar e produzir artefato

E se o teu caso for outro, tipo revisar uma decisão que tu JÁ tomou, o caminho é diferente: nesse cenário vale mais usar o Claude como segunda opinião do que rodar uma sessão pensada pra ideia ainda sem código

Cada ferramenta no seu momento, beleza?

Vídeo relacionado do canal

Pra começar do zero com ferramenta nova e automação, este vídeo do canal mostra as novidades da versão 1.106 do n8n

Próximo passo

A lógica do /office-hours é simples de resumir: expor as suposições antes do código, não depois do deploy

O próximo passo concreto é rodar a skill na ideia que está travada aí na tua cabeça agora, escolhendo o modo certo (startup pra realidade de mercado, builder pra projeto paralelo)

Depois vai lá em ~/.gstack/projects/ e guarda o design doc que saiu de lá

E então segue pro planejamento com as skills do gstack: /plan-ceo-review, /plan-eng-review ou o fluxo Run /office-hours then /autoplan que o README documenta

Da próxima vez que a ideia travar, tu já sabe por onde começar…

até o próximo post! 😀