Esta é a terceira parte de um total de 5 artigos sobre Spec-Driven Development. Se estiver chegando agora, comece pela Parte 1.

Parte 3 – O Ecossistema de Ferramentas: Spec Kit, Tessl, Claude Code e skills.md

Na Parte 1 desta série, exploramos o conceito de Spec-Driven Development e por que especificações estão substituindo código como a fonte de verdade no desenvolvimento de software. Na Parte 2, mergulhamos na arquitetura conceitual do SDD. Agora é hora de colocar a mão na massa: quais ferramentas estão dando forma a essa nova engenharia de software?

O ecossistema de SDD amadureceu rapidamente ao longo de 2025. O que começou como uma ideia provocadora: “e se specs gerassem código, em vez de apenas guiá-lo?”, agora tem ferramentas concretas, registries de specs, frameworks de integração e um padrão aberto de skills.

Vamos explorar as quatro peças centrais desse ecossistema.

1. GitHub Spec Kit: O Toolkit Agnóstico

O Spec Kit é o projeto open-source do GitHub que codifica um workflow completo de Spec-Driven Development. Lançado em setembro de 2025 e influenciado pela pesquisa de John Lam, o toolkit rapidamente se tornou a referência mais citada do movimento SDD. Acesse o site oficial: Spec Kit.

O Spec Kit opera através de uma CLI (Command Line Interface), chamada specify, e de slash commands que guiam o desenvolvedor por seis etapas:

Constitution → Specify → Plan → Tasks → Implement → PR

A instalação é simples e o workflow é orientado por comandos:

/speckit.constitution — Define os princípios inegociáveis do projeto (padrões de acessibilidade, stack tecnológico, convenções de código). Esse documento vive em /specify/memory/constitution.md e serve como “lei fundamental” para o Agente de IA.

/speckit.specify — Descreve a intenção funcional do que se quer construir, sem entrar em detalhes técnicos. O agente transforma essa intenção em uma especificação estruturada.

/speckit.plan — Traduz a especificação em um plano técnico com decisões arquiteturais, escolhas de tecnologia e definições de API.

/speckit.tasks — Decompõe o plano em tarefas atômicas ordenadas, incluindo tarefas de teste antes da implementação (test-driven structure), checkpoints de validação e rastreamento de dependências.

/speckit.implement — O Agente de IA executa as tarefas seguindo o plano. Aqui o código é finalmente gerado.

/speckit.analyze — Funciona como um quality gate, verificando consistência entre constitution, specs, planos e tasks.

Pontos Fortes

O Spec Kit é agnóstico em relação ao Agente de IA. Funciona com Claude Code, GitHub Copilot, Cursor, Gemini CLI, Windsurf e outros. Isso é uma decisão de design deliberada: se a spec é a fonte de verdade, você não deveria ficar preso a uma ferramenta específica.

Outro ponto poderoso é a consistência entre interações. Em vez de começar do zero a cada prompt, o Spec Kit mantém um entendimento persistente do projeto. Novos membros da equipe podem ler os arquivos de spec e rapidamente entender o contexto, e o agente gera código alinhado com os padrões estabelecidos.

Limitações

Nem tudo são flores. Uma análise detalhada publicada por Birgitta Böckeler no site Martin Fowler revelou que o Spec Kit gera uma quantidade significativa de arquivos Markdown, muitos deles repetitivos entre si e verbosos demais para tarefas simples. A experiência pode parecer como “usar uma marreta para quebrar uma noz” quando aplicada a bugs pequenos ou features triviais.

Gojko Adzic, autor de livros sobre especificação de software, classificou o movimento SDD como uma evolução lógica do BDD (Behaviour-Driven Development), mas alertou que sua estrutura rígida pode reintroduzir a rigidez que os métodos ágeis tentaram superar, o espectro do Waterfall em roupagem nova.

Fazer exatamente o especificado, sem inventar, é o que torna o desenvolvimento agêntico viável em escala empresarial.

2. Tessl: O Framework + Registry Para Agentes Profissionais

Se o Spec Kit é o toolkit do GitHub, o Tessl é a aposta de uma startup inteiramente dedicada ao SDD. Fundada por Guy Podjarny (ex-CEO da Snyk) e respaldada por US$125 milhões em investimentos de Index Ventures, Accel e GV, a Tessl lançou dois produtos complementares em setembro de 2025. Acesse o site oficial: Tessl.

O Tessl Framework

O Framework integra-se ao seu Agente de IA via MCP (Model Context Protocol) e muda o comportamento padrão do agente. Em vez de correr para escrever código ao receber um prompt, o agente primeiro:

  • Faz perguntas de esclarecimento — Uma por vez, até entender a intenção.
  • Cria specs primeiro — Documentos estruturados em Markdown (.spec.md) com YAML frontmatter, descrevendo o que o software deve fazer.
  • Aguarda aprovação — Pausa para que o humano confirme que a spec captura a intenção correta.
  • Implementa com guardrails — Constrói contra as specs aprovadas, depois verifica o trabalho.

Uma spec típica do Tessl tem três partes: descrição do componente, lista de capacidades com testes vinculados e uma API mostrando como usar o componente. Specs e testes são commitados junto com o código, funcionando como memória de longo prazo do produto.

O Tessl Spec Registry

O Registry é talvez a contribuição mais original da Tessl. Com mais de 10.000 specs pré-construídas para bibliotecas open-source, ele resolve um dos problemas mais frustrantes dos Agentes de IA: a alucinação de APIs.

Agentes frequentemente inventam APIs que não existem ou misturam versões de bibliotecas, especialmente em pacotes menos populares ou mais recentes. O Registry fornece ao agente informações autoritativas sobre como usar cada biblioteca corretamente com importações, exemplos, convenções e armadilhas comuns.

Após a instalação, o Tessl cria um arquivo KNOWLEDGE.md e o conecta ao AGENTS.md, dando ao agente acesso a todas as usage specs do projeto. É como um npm ou PyPI, mas para o contexto dos agentes, uma camada compartilhada de conhecimento estruturado.

Tessl vs. Spec Kit

Embora ambos se rotulem como ferramentas de SDD, suas abordagens diferem significativamente. O Spec Kit implementa o SDD em sua forma mais pura: spec-as-source, onde a especificação é literalmente a fonte que gera a implementação. O Tessl opera mais como spec-anchored: specs são artefatos centrais, mas coexistem com código editado manualmente.

O Tessl também se posiciona como uma plataforma de habilitação de agentes mais ampla, com avaliação de skills, distribuição de contexto entre repositórios e suporte a contexto privado para equipes.

3. Claude Code: O Agente Nativo Para SDD

O Claude Code, da Anthropic, é o agente que mais organicamente se integra ao workflow de SDD e isso não é coincidência. Como ferramenta de terminal, o Claude Code foi projetado para desenvolvimento totalmente agêntico: você explica o que quer e ele planeja, orquestra, executa e verifica. Se quiser conhecer o Claude Code na prática, confira aqui. A documentação oficial você encontra aqui.

CLAUDE.md: Memória Persistente

O arquivo CLAUDE.md é a “constituição” local do Claude Code, instruções persistentes que sobrevivem entre sessões. Ali você define convenções do projeto, padrões de código, restrições arquiteturais e qualquer contexto que o agente precisa lembrar.

No contexto de SDD, o CLAUDE.md funciona como o equivalente do constitution.md do Spec Kit, mas de forma nativa e sem necessidade de tooling externo.

Subagentes e o Task System

Uma das capacidades mais poderosas do Claude Code para SDD é o sistema de subagentes. Em vez de tratar o Claude como um programador solo, você o trata como uma equipe:

  • Você é o product owner.
  • Claude (agente principal) é o tech lead.
  • Subagentes são os desenvolvedores.

Na prática, o fluxo de SDD com Claude Code segue quatro fases:

  • Pesquisa — Subagentes paralelos investigam o codebase, bibliotecas de referência e padrões relevantes, gerando relatórios de pesquisa.
  • Especificação — O agente principal sintetiza a pesquisa em specs estruturadas (requisitos, design, tarefas).
  • Aprovação — O humano revisa três documentos (requirements, design, tasks) em vez de dezenas de micro-decisões durante a implementação.
  • Implementação — Subagentes executam tarefas em paralelo, cada um em seu próprio contexto, fazendo commits incrementais.

Isso reduz drasticamente o que um desenvolvedor chama de “approval fatigue”: em vez de ser interrompido dezenas de vezes durante a implementação, você revisa documentos estruturados no início e depois deixa a implementação fluir.

Os Hooks do Claude Code permitem executar código em pontos determinísticos do workflow, antes e depois de cada ação do agente. Isso complementa o SDD adicionando verificações automáticas que não dependem do julgamento do LLM.

4. Skills.md: O Padrão Aberto Que Conecta Tudo

Se existe uma peça que une todo o ecossistema de SDD, essa peça é chamada de Agent Skills, e mais especificamente, o arquivo SKILL.md.

O Que São Skills?

Skills são pastas organizadas contendo instruções, scripts e recursos que Agentes de IA podem descobrir e carregar dinamicamente. Em outubro de 2025, a Anthropic publicou os Agent Skills e, em dezembro, liberou o formato como um padrão aberto, adotado também pela OpenAI para o Codex CLI e ChatGPT. Visite a documentação oficial: Agent Skills.

Simon Willison, um dos mais respeitados comentaristas do ecossistema de IA, chamou os Skills de potencialmente “um negócio maior que o MCP”, exatamente por sua simplicidade radical. Enquanto o MCP é uma especificação de protocolo completa com hosts, clientes, servidores, transportes e múltiplos mecanismos, Skills são Markdown com um pouco de YAML e scripts opcionais.

Esta é a anatomia de um Skill:

meu-skill/
├── SKILL.md     # Obrigatório: instruções + metadados YAML
├── scripts/          # Opcional: código executável
├── references/   # Opcional: documentação adicional
└── assets/           # Opcional: templates, fontes, imagens

O conteúdo Markdown contém as instruções que o agente segue quando o skill é ativado. O agente decide automaticamente quando carregar cada skill com base no contexto, ou seja, é model-invoked, não user-invoked.

Progressive Disclosure: Eficiência de Contexto

A arquitetura de Skills usa progressive disclosure: o agente carrega informações em estágios conforme necessário, em vez de consumir todo o contexto de uma vez. Na inicialização, apenas os metadados (nome e descrição) são carregados. Quando um skill é acionado, o agente lê o SKILL.md do filesystem. Se as instruções referenciam outros arquivos, o agente os carrega sob demanda.

Isso significa que você pode instalar muitos Skills sem penalidade de contexto. O agente só sabe que cada skill existe e quando usá-lo.

Skills no Contexto do SDD

No ecossistema de SDD, Skills funcionam em múltiplas camadas:

  • Skills de metodologia — Como o tessl-labs/spec-driven-development, que ensina ao agente o workflow de SDD (perguntar antes de codificar, criar specs, aguardar aprovação).
  • Skills de uso de bibliotecas — Eliminam alucinações de API fornecendo specs autoritativas sobre como usar frameworks específicos. O Tessl Registry é essencialmente um marketplace de skills desse tipo.
  • Skills de domínio — Convenções internas da equipe, padrões de segurança, guidelines de marca, processos de deploy.
  • Skills de criação de artefatos — Como os skills nativos da Anthropic para criação de documentos DOCX, XLSX, PPTX e PDF, que transformam agentes genéricos em especialistas de produção.

O Marketplace Emergente

Já existe um ecossistema de marketplaces de Skills surgindo. O SkillsMP (skillsmp.com) indexa skills de repositórios públicos do GitHub, filtrando por qualidade. O Tessl Registry funciona como distribuidor centralizado com avaliação de qualidade. E a Anthropic mantém seu próprio repositório oficial de skills de referência.

A beleza desse ecossistema é que nenhuma peça exige as outras. Você pode usar Spec Kit com Gemini CLI. Tessl com Cursor. Skills com qualquer agente que leia Markdown. Claude Code sem nenhum framework externo. A interoperabilidade é um princípio de design, não um acidente.

O Que Isso Significa na Prática?

O ecossistema de ferramentas de SDD está respondendo a uma pergunta fundamental: como dar aos Agentes de IA o contexto necessário para produzir código confiável em escala?

A resposta que está emergindo é surpreendentemente humana: da mesma forma que integramos novos engenheiros de software em uma equipe. Damos a eles documentação (specs), convenções (constitution/CLAUDE.md), conhecimento sobre as ferramentas que usamos (usage specs/registry), procedimentos para tarefas comuns (skills) e processos de revisão claros (phase gates).

O SDD não é um retorno ao Waterfall. É o reconhecimento de que Agentes de IA (assim como engenheiros humanos) trabalham melhor com contexto estruturado, intenção clara e guardrails bem definidos.

Seguimos na Parte 4.

Equipe DSA