gstack: Stack de Engenharia de Software com IA

Agentes de IA para codificação já conseguem escrever funções, modificar repositórios, executar testes e abrir solicitações de pull request. O problema mais difícil é fazer um agente seguir um processo de engenharia repetível antes, durante e depois da escrita do código.

O gstack, um projeto de Garry Tan originalmente construído em torno do Claude Code, segue uma rota diferente: em vez de substituir seu agente de codificação por outra plataforma, ele envolve o agente que você já utiliza com habilidades especializadas, ferramentas de navegador, revisões, controles de segurança e processos de lançamento. O projeto descreve o resultado como uma equipe virtual de engenharia – vinte e três especialistas e oito ferramentas poderosas, todos comandos com barra diagonal, tudo em Markdown, sob licença MIT.

Os alvos da comparação dependem de qual parte do gstack você precisa: coleções de habilidades como o Superpowers, sistemas de especificação como OpenSpec e GitHub Spec Kit, metodologias como o BMAD, plataformas de orquestração como o Ruflo, ou seu próprio conjunto mantido de habilidades de agentes. Vários destes se combinam com o gstack em vez de substituí-lo, e o ecossistema mais amplo ao qual todos pertencem é mapeado no hub de Ferramentas de Desenvolvimento com IA deste site.

O que é o gstack?

O gstack é uma coleção open-source de fluxos de trabalho de engenharia com IA. Na formulação do gstack, o desenvolvimento de software consiste em vários tipos diferentes de raciocínio, e pedir a um único prompt genérico de codificação que execute todos eles é uma abstração pobre – então o projeto expõe habilidades especializadas:

• exploração do produto
• revisão de produto e CEO
• revisão de arquitetura
• revisão de experiência do desenvolvedor
• revisão de design
• revisão de implementação
• QA baseado em navegador
• investigação e depuração (debugging)
• análise de segurança
• documentação
• benchmarking
• preparação de lançamento
• implantação (deployment)
• retrospectivas

O projeto apresenta esses papéis como uma equipe virtual de engenharia: um CEO que repensa o produto, um gerente de engenharia que define a arquitetura, um designer que detecta “lixo de IA” (AI slop), um revisor que encontra bugs de produção, um líder de QA que abre um navegador real, um oficial de segurança que executa auditorias OWASP e STRIDE, e um engenheiro de lançamento que envia o PR (pull request). A ferramenta (toolchain) ao redor das definições de habilidades é TypeScript e Bun: um script de configuração, documentação de habilidades gerada, hooks de sessão, estado sob ~/.gstack/, um navegador embutido e um conjunto de CLIs independentes.

O gstack não é um modelo de fundação (foundation model) e não é uma substituição para o Claude Code; é uma camada de processo executada sobre um suporte (harness) de agente:

Duas propriedades estruturais decidem onde o gstack se encaixa. Primeiro, o projeto o descreve como um processo e não como uma coleção de ferramentas: as habilidades são executadas na ordem em que um sprint é executado – pensar, planejar, construir, revisar, testar, lançar, refletir – e cada habilidade repassa seus artefatos para a próxima, então /office-hours escreve um documento de design que /plan-ceo-review lê, e /plan-eng-review escreve um plano de teste que /qa coleta. Segundo, o gstack não é exclusivo para o Claude Code: ./setup detecta automaticamente os agentes instalados na máquina, e ./setup --host <name> alvo o Codex CLI, OpenCode, Cursor, Factory Droid, Kiro, Slate, OpenClaw e Hermes, enquanto um resumo de instruções de apenas 2KB no repositório cobre agentes que leem regras e não precisam de instalação alguma.

Por que o gstack existe

Uma sessão em branco do Claude Code é extremamente flexível, e essa flexibilidade também é uma de suas fraquezas. Considere uma solicitação de recurso como:

Adicionar tokens de API no nível da organização à aplicação.

Um agente capaz pode imediatamente inspecionar o repositório e começar a modificar o código de autenticação, enquanto um engenheiro sênior primeiro perguntaria quem é o dono dos tokens, se os usuários podem pertencer a várias organizações, como os tokens são revogados, se as permissões são herdadas, o que acontece com a autenticação existente, se os tokens devem expirar, como os segredos são exibidos e quais eventos de auditoria são necessários. O agente pode eventualmente descobrir algumas dessas perguntas, mas não há garantia de que as descobrirá antes da implementação. O gstack move essa disciplina para fluxos de trabalho reutilizáveis: em vez de ideia -> agente de codificação -> código, a alteração passa por revisão de produto, planejamento técnico, revisão de arquitetura, implementação, revisão de código, QA em navegador e lançamento como etapas nomeadas, cada uma com seu próprio comando (a sequência completa está em Um Fluxo de Trabalho Prático com gstack abaixo).

Isso não torna a IA correta; muda a distribuição de probabilidade de seus erros. O agente é levado a desafiar premissas mais cedo, inspecionar evidências, revisar seu próprio trabalho de várias perspectivas e verificar a aplicação em vez de parar quando o código compila.

Como o gstack transforma habilidades Markdown em processo

A maioria das capacidades do gstack origina-se em definições de habilidades Markdown. Uma habilidade de agente pode descrever:

• quando ela deve ser executada
• qual contexto ela deve inspecionar
• que perguntas ela deve fazer
• quais ferramentas ela pode usar
• quais comandos ela deve executar
• quais evidências ela deve coletar
• quais verificações devem passar
• como o resultado deve ser estruturado

Tal habilidade atua em algum lugar entre documentação, um prompt reutilizável, um procedimento operacional padrão e configuração de fluxo de trabalho executável. As mecânicas subjacentes são cobertas em Claude Skills e SKILL.md para Desenvolvedores; o gstack adiciona infraestrutura por cima dessa primitiva: definições de habilidades geradas, hooks de inicialização e conclusão, gerenciamento de estado sob ~/.gstack/, automação de navegador, mecanismos de segurança, inspeção de repositório, telemetria opt-in, memória entre sessões gerenciada por /learn, e conhecimento persistente opcional através do projeto separado GBrain, que /setup-gbrain pode configurar como um banco de dados PGLite local, um projeto Supabase ou um endpoint MCP remoto.

As habilidades mais importantes do gstack

A coleção exata muda rapidamente, mas vários fluxos de trabalho ilustram como o sistema pretende ser usado.

office-hours

/office-hours pertence perto do início de um projeto ou recurso. Ele executa seis perguntas forçantes sobre o problema antes de qualquer código ser escrito, e no exemplo prático do README ele redefine uma solicitação por um “app de briefing diário” como um chefe de gabinete pessoal com IA, e então escreve o documento de design que todas as habilidades a jusante leem. Para entradas vagas como “precisamos de uma busca de projeto melhor”, a saída é um requisito, não código.

plan-ceo-review

/plan-ceo-review examina as premissas de nível de produto por trás de um plano. Ele funciona em quatro modos de escopo – Expansão, Expansão Seletiva, Manter Escopo, Redução – e pode desafiar o escopo, identificar oportunidades faltantes, reduzir trabalho desnecessário, ou sugerir enquadrar o problema de forma diferente. Ele é executado antes dos requisitos serem fixados, uma etapa que a maioria das ferramentas de agentes de codificação não possui.

plan-eng-review

/plan-eng-review muda a perspectiva para a engenharia: arquitetura, fluxo de dados, diagramas, casos extremos, uma matriz de testes, modos de falha e preocupações de segurança. Ele permanece separado da revisão de produto porque mesclar ambos em um único prompt grande faz o modelo misturar decisões de produto com decisões de implementação.

plan-design-review e design-review

O gstack trata o design visual e de interação como uma disciplina separada. /plan-design-review classifica cada dimensão de design de 0 a 10, descreve como uma nota 10 parece e edita o plano para fechar a lacuna, com detecção de “lixo de IA” (AI slop) como uma verificação nomeada. O /design-review posterior executa a mesma auditoria contra a implementação real e corrige o que encontra com commits atômicos e capturas de tela antes/depois. Para aplicações web, ambos se pareiam com a automação de navegador do gstack.

review

/review executa a revisão de engenharia contra alterações no repositório a partir da perspectiva de um engenheiro sênior: ele corrige automaticamente os achados óbvios, sinaliza o resto para aprovação e mantém uma lente consultiva de simplificação para código super-construído. Código escrito com sucesso não é necessariamente código que deve ser mesclado.

investigate

/investigate impõe uma regra sistemática de depuração que o projeto chama de Lei de Ferro: sem correções sem investigação. Ele rastreia o fluxo de dados, testa hipóteses e para após três tentativas de correção falhas em vez de continuar a se debater. Ele também ativa automaticamente /freeze, que bloqueia edições ao módulo sob investigação.

qa e qa-only

/qa faz o agente operar um navegador, interagir com a aplicação, encontrar bugs, corrigi-los com commits atômicos, reverificar e gerar um teste de regressão para cada correção. /qa-only executa a mesma metodologia apenas com relatório. Muitos agentes de codificação param a verificação em “testes passaram”; para uma aplicação web, o navegador é onde erros de integração, problemas de layout, fluxos incorretos, falhas de autenticação e exceções de JavaScript normalmente se tornam visíveis.

ship, land-and-deploy, e canary

A cadeia de lançamento é três habilidades em vez de uma. /ship sincroniza o main, executa testes, audita a cobertura, faz o push e abre a solicitação de pull request, inicializando um framework de teste se o projeto não tiver nenhum. /land-and-deploy mescla, aguarda pelo CI e pela implantação, e verifica a saúde da produção. /canary então executa um loop de monitoramento pós-implantação que observa erros no console, regressões de desempenho e falhas de página.

autoplan, spec, learn, e retro

/autoplan executa o pipeline de revisão de CEO, design, DX e engenharia automaticamente – engenharia sempre por último, para que a porta de lançamento reveja o plano final alterado – e expõe apenas decisões de gosto para aprovação. /spec transforma intenção vaga em uma especificação precisa e executável em cinco fases (por que, escopo, técnica com leitura de código obrigatória, rascunho, arquivo) com uma porta de qualidade de revisão externa antes do arquivamento. /learn gerencia o que o gstack aprendeu entre sessões – padrões, armadilhas e preferências – com revisão, busca, poda e exportação. /retro produz uma retrospectiva semanal ciente da equipe; /retro global a executa em todos os seus projetos e ferramentas de IA.

Automação de Navegador no gstack

Em sistemas macOS suportados (macOS 15+), o gstack dirige primeiro o navegador Aside – seu navegador real, com suas sessões logadas reais, em abas que o agente abre para si mesmo e fecha quando terminar. Quando o Aside não está disponível, o gstack usa seu próprio mecanismo baseado em Chromium como alternativa, que ./setup compila e que executa um daemon persistente em vez de lançar um navegador novo para cada comando:

O estado persistente do navegador permite que cookies, sessões de autenticação e abas sobrevivam entre operações, o que torna o QA baseado em navegador prático. /open-gstack-browser expõe o mecanismo de fallback em modo visível (headed), com um agente de barra lateral que roteia ações rápidas (clique, navegação, captura de tela) para o Sonnet e leitura ou análise para o Opus. Quando o agente atinge um CAPTCHA, uma muralha de autenticação ou um prompt de MFA, $B handoff abre um navegador visível na mesma página com cookies e abas intactos; você resolve, e $B resume continua onde o agente parou. O agente sugere um handoff automaticamente após três falhas consecutivas. /pair-agent compartilha o navegador com outros agentes – OpenClaw, Hermes, Codex, Cursor, ou qualquer coisa que possa usar curl – com tokens escopados, isolamento de abas, limitação de taxa e atribuição de atividade por aba.

O mecanismo persistente também aumenta a superfície de segurança, já que um agente com acesso a sessões autenticadas detém um privilégio significativo. O gstack entrega uma defesa em camadas contra injeção de prompt (prompt-injection) para isso: filtros de conteúdo (marcação de dados, remoção de elementos ocultos, limpeza de ARIA, lista negra de URLs) em cada leitura de página, além de um classificador de ML local em um subprocesso auxiliar (sidecar) que varre o conteúdo derivado da página antes que o agente o veja, com um combinador de veredito que exige concordância do classificador antes de bloquear. O conteúdo da página é tratado como entrada não confiável – o agente toma sintaxe de uma página, nunca instruções. Verificações antes e durante o uso de QA dirigido por navegador:

• Decida antecipadamente em quais ambientes autenticados o agente pode operar, e prefira um perfil isolado para trabalho de QA quando o mecanismo de fallback estiver em uso.
• Conheça o interruptor de emergência: GSTACK_SECURITY_OFF=1 desabilita a camada de segurança – não o deixe definido.
• O daemon persistente retém cookies e sessões entre execuções, então pare-o quando terminar e confirme que nada ficou em execução, por exemplo ps aux | grep -i chrom.
• Leia os hooks e mecanismos de segurança no repositório clonado antes de ativá-los – eles são arquivos simples, então revise-os da mesma forma que revisaria configuração de CI.
• Após atualizar o clone, reexecute ./setup para que os componentes gerados mantenham-se sincronizados com as definições de habilidades.

Barreiras de Segurança e Segunda Opinião

Três ferramentas poderosas atuam como interruptores de segurança no nível de sessão. /careful avisa antes de comandos destrutivos – rm -rf, DROP TABLE, force-push, git reset --hard – e é ativado dizendo “cuidado”; exclusões recursivas da raiz ou do diretório home e force-pushes para a branch padrão são negados categoricamente. /freeze restringe edições de arquivos a um diretório para que o agente não “corrija” código não relacionado durante a depuração, e /guard ativa ambos ao mesmo tempo.

Revisões de segunda opinião cruzam suportes (harnesses): no Claude Code, /codex envia o trabalho para o OpenAI Codex CLI para uma revisão, desafio ou consulta independente; nos outros suportes, /claude-code faz o contrário. Cada relatório identifica o provedor que efetivamente completou a revisão.

Um Fluxo de Trabalho Prático com gstack

Você não precisa de todas as habilidades do gstack para cada alteração. Um fluxo de trabalho de recurso razoável:

1. /office-hours
2. /plan-ceo-review
3. Criar o plano de implementação
4. /plan-eng-review
5. Implementar
6. /review
7. /qa
8. /ship

Quais habilidades de revisão adicionar depende de quem é o público do software:

Para uma correção de bug trivial, ir diretamente para investigação, implementação, revisão e testes costuma ser suficiente. Uma versão neutra quanto a ferramentas da mesma forma – especificação, design, tarefas, implementar, validar – está em Fluxo de Trabalho de Desenvolvimento Guiado por Especificações de Requisitos para Código. O README do projeto descreve executar dez a quinze desses sprints em paralelo, cada um em seu próprio espaço de trabalho isolado; a estrutura do sprint é o que o projeto diz manter agentes paralelos de se tornarem fontes de caos.

Instalando o gstack

A instalação atual espera uma configuração do Claude Code funcional, Git, Bun v1.0+ e, no Windows, Node.js – o Bun tem um bug conhecido com o transporte de pipe do Playwright no Windows, então o servidor de navegação usa o Node.js como alternativa. Se você ainda não configurou o Claude Code, comece pela visão geral do Claude Code primeiro. No macOS, o navegador Aside (macOS 15+) é recomendado para as habilidades de navegador; sem ele, o daemon Chromium embutido é usado.

1. Verifique seus pré-requisitos: git --version e bun --version (a toolchain é baseada em Bun).

2. Clone o gstack para o diretório de habilidades do Claude:

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

3. Execute o script de configuração a partir do diretório clonado:

   cd ~/.claude/skills/gstack
   ./setup
   

   A configuração instala e gera os componentes necessários pelas habilidades suportadas e compila o navegador embutido; uma falha na instalação do Chromium é melhor esforço, a configuração registra a razão, finaliza o registro de todas as habilidades e imprime quais habilidades são afetadas.

4. Adicione uma seção ## gstack ao CLAUDE.md do projeto. As instruções de instalação do projeto incluem essa etapa, e é isso que faz o Claude Code rotear as habilidades: use /browse do gstack para toda navegação web, nunca use as ferramentas mcp__claude-in-chrome__*, e liste as habilidades disponíveis.

5. Verifique a instalação: confira que os arquivos gerados estão presentes no diretório clonado, inicie uma sessão do Claude Code e execute /office-hours em um projeto de teste para confirmar que a habilidade é reconhecida.

Modo de equipe

Para repositórios, o gstack oferece uma configuração orientada a equipe onde desenvolvedores compartilham um único fluxo de trabalho em vez de ambientes configurados individualmente:

(cd ~/.claude/skills/gstack && ./setup --team) && \
  ~/.claude/skills/gstack/bin/gstack-team-init required && \
  git add .claude/ CLAUDE.md && \
  git commit -m "exigir gstack para trabalho assistido por IA"

required bloqueia trabalho assistido por IA no repositório sem o gstack; troque por optional para incentivar os colegas em vez de bloqueá-los. Nenhum arquivo é incluído no repositório: cada sessão do Claude Code começa com uma verificação de atualização automática rápida (limitada a uma vez por hora, à prova de falhas de rede, silenciosa), o que remove a derivação de versões entre a equipe. Configuração pessoal melhora um desenvolvedor; configuração no nível do repositório cria uma convenção de engenharia compartilhada.

Outros suportes, atualizações e desinstalação

• Outros agentes: ./setup --host codex, --host opencode, --host cursor, --host factory, --host kiro, --host slate, --host openclaw e --host hermes instalam as habilidades no próprio diretório de habilidades de cada agente. O resumo de instruções de 2KB em agents-digest/gstack-AGENTS.md cobre agentes que apenas leem arquivos de regras.
• Nomenclatura de comandos: as habilidades são registradas com nomes curtos por padrão (/qa, /review); ./setup --prefix alterna para nomes namespaced (/gstack-qa), o que importa quando você executa outros pacotes de habilidades ao lado do gstack.
• Atualizações: reexecute ./setup após um git pull (obrigatório no Windows, onde as instalações são cópias de arquivos) ou use a habilidade /gstack-upgrade; definir auto_upgrade: true em ~/.gstack/config.yaml mantém a instalação atualizada automaticamente.
• A telemetria está desativada por padrão e pede opt-in na primeira execução. Se você optar por ativar, ela envia o nome da habilidade, duração, sucesso/falha, versão do gstack e SO – nunca código, caminhos de arquivo, nomes de repositório ou prompts. gstack-config set telemetry off a desativa a qualquer momento.
• Desinstalação: ~/.claude/skills/gstack/bin/gstack-uninstall remove habilidades, links simbólicos, estado de ~/.gstack/, estado local do projeto, daemons de navegação e registros de hooks.

Verificar a instalação e corrigir falhas comuns

• ./setup falha – confirme que o Bun está no seu PATH com bun --version; os componentes gerados são compilados pela toolchain Bun.
• Habilidades não reconhecidas pelo Claude Code – confirme que o clone realmente está em ~/.claude/skills/gstack, que o CLAUDE.md do projeto tem uma seção de gstack, e reexecute ./setup.
• /browse reporta NEED_ASIDE ou ASIDE_NOT_RUNNING – o probe está dizendo que usará o navegador de fallback. Isso é normal no Linux e Windows; no macOS significa que o Aside não está aberto ou logado.
• O navegador de fallback falha – cd ~/.claude/skills/gstack && bun install && bun run build.
• Instalação desatualizada após uma atualização – execute /gstack-upgrade ou defina auto_upgrade: true em ~/.gstack/config.yaml.

Tentando o gstack sem Adotar Tudo

Use o gstack em um recurso real, mas não crítico, em vez de migrar seu processo de desenvolvimento. A inicialização rápida do projeto é o mesmo teste, e termina com “pare aí”:

1. /office-hours – definição do problema
2. /plan-ceo-review – raciocínio de produto
3. /review – verificação de engenharia, após a implementação
4. /qa – verificação em tempo de execução, para projetos web

Se essas etapas revelarem achados que seu fluxo de trabalho normal do Claude Code perde, o resto do sistema vale a pena explorar; se elas produzirem principalmente texto adicional sem alterar decisões de engenharia, adotar a pilha inteira provavelmente não ajudará.

O que o gstack faz bem

Papéis de engenharia separados. Em vez de uma grande instrução “seja um engenheiro sênior”, estratégia de produto, arquitetura, UX, QA, segurança e engenharia de lançamento cada um recebem seu próprio modo de raciocínio.

Verificação, não apenas geração. Revisão, QA em navegador com geração de testes de regressão, auditorias de segurança, benchmarking e a cadeia de lançamento-implantação-canário são fluxos de trabalho de primeira classe no gstack, e não pensamentos subsequentes opcionais.

Inspecionável. Muito da camada comportamental são arquivos Markdown simples que desenvolvedores podem ler e modificar, ao contrário dos fluxos de trabalho internos de um agente autônomo proprietário. O repositório também entrega ferramentas de auditoria para a pilha em si: gstack-context-bill relata quanto uma árvore de habilidades instalada custa em tokens, e gstack-egress escreve um recibo encadeado por hash para cada envio fora da máquina, incluindo telemetria.

Infraestrutura de equipe. Habilidades podem codificar convenções de engenharia – em vez de digitar

Lembre-se de verificar compatibilidade da API, executar testes de integração,
inspecionar o console do navegador e atualizar o changelog.

em cada sessão, os requisitos vivem em um fluxo de trabalho reutilizável, e o modo de equipe torna esse fluxo de trabalho um requisito do repositório.

Onde o gstack pode ser demais

O gstack é deliberadamente opinativo, e isso limita seu encaixe: uma organização madura pode já ter procedimentos de revisão de arquitetura, ferramentas de lançamento, portões de CI, automação de QA, varreduras de segurança, convenções de ADR, modelos de especificação e políticas de revisão de código, e adicionar outra metodologia completa por cima cria sobreposição em vez de clareza.

Também há um custo de contexto e tokens: cada etapa de revisão adicional adiciona inspeção de repositório, raciocínio do modelo e potencialmente mais chamadas a modelos externos. O objetivo é o processo mínimo confiável necessário para lançar software correto, e não um número máximo de revisões de IA; gstack-context-bill pode quantificar o que seu conjunto de habilidades instalado realmente custa por sessão antes de você decidir quanto dele manter.

O gstack funciona melhor como uma caixa de ferramentas cujos fluxos de trabalho você seleciona e adapta, e não como uma cerimônia para cada commit.

Alternativas e Combinações do gstack

As alternativas mais próximas, e a camada que cada uma ocupa:

gstack + Superpowers: disciplina de implementação dentro dos papéis

Ambos são frameworks de habilidades, então eles se sobrepõem mais. A divisão de trabalho ao combiná-los: o gstack fornece os papéis circundantes – produto, design, QA, lançamento – enquanto o Superpowers fornece a disciplina dentro da fase de implementação (TDD, planejamento antes da implementação, depuração sistemática, revisão por subagente). Instale ambos os conjuntos de habilidades, então reduza as habilidades sobrepostas para que o agente nunca veja duas instruções conflitantes para a mesma fase; se os nomes dos comandos colidirem, instale o gstack com ./setup --prefix para que suas habilidades sejam registradas como /gstack-* e coexistam com o outro pacote. Detalhes de instalação e fluxo de trabalho estão no início rápido do Superpowers.

gstack + OpenSpec: especificações duráveis, revisões ao vivo

O OpenSpec mantém humanos e agentes alinhados em torno de especificações de alteração explícitas – artefatos para a alteração proposta, especificações, decisões de design e tarefas de implementação. A propriedade-chave é a persistência: uma conversa de chat desaparece no histórico de contexto, mas uma especificação permanece no repositório onde humanos e futuras sessões de agentes podem revisá-la. O gstack adiciona a revisão de produto antes que a especificação exista e a revisão e QA após ela ser implementada:

Uma sequência concreta: execute /office-hours e /plan-ceo-review, capture o resultado como uma alteração OpenSpec, implemente com base nela, então execute /review e /qa. Observe que o gstack também entrega seu próprio skill /spec, que arquiva especificações sob ~/.gstack; se o OpenSpec possuir a especificação, mantenha o /spec do gstack fora do circuito para que os dois não diverjam. O início rápido do OpenSpec cobre em detalhes o loop explorar-propor-aplicar-arquivar.

gstack + GitHub Spec Kit: escolha um espinha dorsal de planejamento

O fluxo de trabalho central do Spec Kit é uma sequência de etapas explícitas – constituição, especificar, planejar, tarefas, implementar, convergir – e ele se expandiu para correção de bugs, avaliação de ideias, extensões, predefinições e integrações. Como o Spec Kit e o gstack centralizam a etapa de planejamento, executar ambos os fluxos completos duplica trabalho. Se a rastreabilidade de requisitos e etapas formais importam, deixe o Spec Kit possuir a espinha dorsal da especificação e use o gstack para as camadas que o Spec Kit não força – revisão de produto, revisão de design, QA em navegador e lançamento. Uma comparação mais ampla de configurações guiadas por especificação, incluindo Kiro e Claude Code, está em GitHub Spec Kit vs Kiro vs Workflows SDD do Claude Code.

BMAD e Ruflo: eixos diferentes

O BMAD é uma metodologia de desenvolvimento impulsionada por IA mais ampla cujos fluxos de trabalho adaptativos cobrem pensamento de produto, especificações, arquitetura e implementação, escalando a cerimônia para o tamanho do trabalho. Ele e o gstack ambos jogam o papel de espinha dorsal de processo, então escolha um como espinha dorsal em vez de executar ambos totalmente; as habilidades individuais do gstack ainda podem ser selecionadas ao lado de uma metodologia.

O Ruflo visa orquestração multi-agente: trabalhadores coordenados, memória compartilhada, enxames. O gstack aplica múltiplas perspectivas de especialistas a um fluxo de trabalho de engenharia; uma plataforma de orquestração aplica múltiplos agentes executantes a um objetivo de engenharia. A fronteira se torna vaga – o gstack pode chamar ferramentas externas e modelos adicionais, e orquestradores podem implementar papéis de engenharia estruturados – mas a decisão é independente: se o problema é que o agente pula a disciplina de engenharia, um framework de habilidades é a correção direta; se é executar dez agentes concorrentemente em muitas tarefas e repositórios, um orquestrador está acima de um fluxo de trabalho como o gstack em vez de substituí-lo.

Habilidades personalizadas: a camada mais personalizável

Você também pode pular o framework completamente e criar uma pequena coleção de habilidades para os procedimentos que sua equipe já segue:

skills/
  architecture-review/
  api-review/
  database-migration-review/
  incident-analysis/
  release-check/
  security-review/

Cada habilidade codifica conhecimento específico da organização que um framework genérico não pode saber. Uma habilidade de migração de banco de dados pode exigir análise de rollback, análise de lock de tabelas, revisão de impacto de índices, estimativa de duração da migração, ordem de implantação e compatibilidade com a versão anterior da aplicação; uma habilidade de revisão de API pode exigir compatibilidade para trás, verificações de autenticação, consistência de paginação, análise de idempotência, comportamento de limite de taxa e alterações no OpenAPI. Um caminho prático: comece das habilidades do gstack que você realmente usa, copie sua estrutura para o seu próprio diretório skills/ e reescreva as verificações ao redor de suas convenções.

Quatro Camadas: Habilidades, Especificações, Metodologias, Orquestradores

Quatro camadas cobrem a maioria dessas ferramentas, e elas mostram como as combinações acima se encaixam:

Habilidades respondem “como o agente deve se comportar?”

gstack, Superpowers e habilidades de agente personalizadas.

Sistemas de especificação respondem “exatamente o que estamos construindo?”

OpenSpec e GitHub Spec Kit; os conceitos e terminologia subjacentes de desenvolvimento guiado por especificação são definidos em O que é Desenvolvimento Guiado por Especificação?.

Metodologias respondem “como o projeto deve avançar da ideia para o software?”

BMAD, Superpowers e partes do gstack.

Orquestradores respondem “como múltiplos agentes devem executar o trabalho?”

Ruflo e outros runtimes multi-agente.

As camadas se compõem; um ambiente de desenvolvimento pode conter todas as quatro:

O gstack já abrange várias dessas fronteiras.

Você Deve Usar o gstack?

O README do projeto descreve o público como fundadores técnicos e CEOs que ainda querem lançar, usuários do Claude Code pela primeira vez que querem papéis estruturados em vez de um prompt em branco, e líderes técnicos e engenheiros seniores que querem revisão rigorosa, QA e automação de lançamento em cada PR. O gstack vale a pena tentar se você usa agentes de codificação extensivamente e o fator limitador não é mais a geração de código em si. Sintomas típicos:

• o agente começa a implementar antes de entender o problema
• planos de implementação perdem implicações de arquitetura
• código gerado passa nos testes, mas falha no navegador
• revisões são inconsistentes entre sessões
• etapas de lançamento são repetidamente esquecidas
• diferentes desenvolvedores pedem ao agente de formas completamente diferentes
• instruções de engenharia úteis permanecem soterradas em arquivos CLAUDE.md
• você digita repetidamente os mesmos prompts de revisão manualmente

Se sua automação já fornece portões determinísticos fortes e o agente apenas lida com pequenas tarefas bem especificadas, o gstack adiciona pouco.

gstack e a Direção do Desenvolvimento de Software com IA

A mudança em que o gstack está inserido rastreia em gerações: conclusão de código (2022-2023), agentes de codificação (2024-2025), especificações e fluxos de trabalho de agentes (2025-2026), e organizações de engenharia de IA programáveis. Os produtos mudarão, mas o modelo permanece um componente; a qualidade de engenharia depende cada vez mais do sistema circundante:

• especificações persistentes
• habilidades reutilizáveis
• conhecimento do repositório
• acesso a navegador
• testes
• ferramentas determinísticas
• loops de revisão
• controles de segurança
• memória
• fronteiras de aprovação humana
• orquestração

Conclusão

O gstack é o processo de engenharia ao redor de um agente de codificação, empacotado como habilidades inspecionáveis e versionadas, e seu valor está em forçar esse processo sobre o agente em vez de estar em qualquer habilidade única.

Comece pela sequência de teste e mantenha apenas as habilidades que merecem seu lugar. Além disso, a direção é camadas compostas – especificação, habilidades, verificação determinística, orquestração – cada uma fazendo o que as outras não podem.

Referências

• repositório do gstack – fonte, definições de habilidades e configuração
• análises aprofundadas das habilidades do gstack – filosofia, exemplos e fluxo de trabalho para cada habilidade
• navegador Aside – o navegador que o gstack dirige primeiro no macOS
• repositório do Superpowers – fonte, habilidades e manifestos de plugins
• repositório do OpenSpec – fonte, documentação e pacote CLI
• documentação do GitHub Spec Kit – referência oficial do fluxo de trabalho do Spec Kit
• repositório do BMAD-METHOD – a metodologia ágil impulsionada por IA adaptativa
• repositório do Ruflo – a plataforma de orquestração multi-agente