context-driven-development

Visão geral da skill context-driven-development

O que a skill context-driven-development faz

A skill context-driven-development ajuda você a criar e manter um pequeno conjunto de artefatos de contexto do projeto em um diretório conductor/, para que o desenvolvimento com apoio de IA tenha uma base estável e reutilizável. Em vez de reexplicar seu projeto em toda conversa, você define documentos centrais como product.md, tech-stack.md, workflow.md e tracks.md, e depois os atualiza conforme o projeto evolui.

Para quem vale a pena instalar

Esta skill é mais indicada para quem usa fluxos no estilo Conductor, desenvolvimento com IA em múltiplas sessões ou ambientes de equipe nos quais a intenção do projeto, as escolhas de stack e o acompanhamento do trabalho precisam permanecer consistentes entre prompts. Ela é especialmente útil para:

• configuração inicial de novos projetos
• onboarding de um agente de IA em uma base de código existente
• equipes que querem um contexto de projeto repetível
• usuários cansados de perder contexto entre sessões

O trabalho real que ela resolve

A maioria dos usuários não precisa de “mais documentação”. Precisa de saídas de IA que parem de se desviar. Na prática, o trabalho da context-driven-development é transformar conhecimento de projeto vago e restrito a uma sessão em artefatos gerenciados que sobrevivem entre tarefas de implementação, planejamento e handoffs.

O que diferencia da prompting comum

Um prompt normal pode descrever seu app uma vez. A context-driven-development skill oferece uma estrutura para manter essa descrição atualizada e internamente consistente ao longo do tempo. O diferencial não é geração de código por si só, e sim a estruturação e sincronização do contexto antes e durante o desenvolvimento.

O que você ganha se ela for adequada ao seu caso

Se você usa context-driven-development for Context Engineering, o principal ganho é continuidade melhor ao longo do trabalho:

• intenção de produto mais clara
• decisões de stack documentadas
• expectativas de workflow explícitas
• unidades de trabalho rastreadas em vez de TODOs soltos
• onboarding melhor de agentes em repositórios brownfield

Quando não é uma boa escolha

Pule esta skill se você só precisa de um snippet isolado de código, não pretende manter a documentação do projeto ou não usa um fluxo em que contexto persistente melhora as saídas futuras. Ela entrega mais valor quando o mesmo projeto será retomado várias vezes.

Como usar a skill context-driven-development

Contexto de instalação e onde esta skill fica

Esta skill vem do repositório wshobson/agents, em plugins/conductor/skills/context-driven-development. O padrão básico de instalação em ambientes com Skills habilitadas é:

npx skills add https://github.com/wshobson/agents --skill context-driven-development

Depois de instalar, invoque a skill no seu ambiente de IA quando precisar estruturar ou atualizar o contexto do projeto, em vez de ir direto para a implementação.

Leia estes arquivos antes do primeiro uso

Para começar rápido e com menos adivinhação, leia:

1. plugins/conductor/skills/context-driven-development/SKILL.md
2. plugins/conductor/skills/context-driven-development/references/artifact-templates.md

SKILL.md explica quando usar a skill, como os artefatos se relacionam e qual é o fluxo de manutenção. Já references/artifact-templates.md acelera o uso na prática: ele mostra o formato esperado de product.md, tech-stack.md e arquivos relacionados, para que você consiga fornecer entradas mais completas ao agente com mais rapidez.

Quais entradas a skill context-driven-development precisa

A skill funciona melhor quando você fornece material-fonte suficiente para gerar ou atualizar os artefatos de contexto. Entradas fortes normalmente incluem:

• tipo de projeto: greenfield ou brownfield
• estrutura atual do repositório ou das pastas
• propósito do produto e usuários-alvo
• restrições técnicas e escolhas de stack
• preferências de workflow de desenvolvimento
• roadmap atual, milestones ou itens de trabalho
• documentação existente, como README.md, tickets, notas de arquitetura ou código

Se você disser apenas “configure o contexto para meu app”, a saída tende a ser genérica. Quando você fornece evidências sobre produto, stack, workflow e o repositório existente, os artefatos ficam muito mais acionáveis.

Uso em greenfield: começando um projeto novo

Em um projeto novo, use context-driven-development para estruturar os artefatos centrais antes de escrever muito código. Um bom pedido inclui:

• o que é o produto
• para quem ele existe
• quais recursos estão dentro ou fora do escopo
• stack esperada
• expectativas de deploy e testes
• como o trabalho deve ser acompanhado

Aqui a skill é especialmente valiosa porque força decisões que, de outra forma, costumam ficar nebulosas até o início da implementação.

Uso em brownfield: extraindo contexto de um repositório existente

Em uma base de código existente, peça à skill para inferir e organizar o contexto a partir do repositório. Aponte para:

• árvore de código-fonte
• arquivos de dependências
• configuração de CI
• README e histórico de issues
• documentação existente
• convenções de nomenclatura e pistas de workflow

É aqui que muita gente percebe valor rapidamente: o context-driven-development guide ajuda a transformar um repositório que “funciona, mas é difícil de explicar” em artefatos que um agente consegue reutilizar depois.

Artefatos centrais e para que serve cada um

O repositório gira em torno de alguns arquivos persistentes em conductor/:

• product.md: problema, usuários, solução, funcionalidades, métricas, roadmap
• tech-stack.md: linguagens, frameworks, dependências, infraestrutura, ferramentas
• workflow.md: como se espera que o desenvolvimento aconteça
• tracks.md: unidades de trabalho, status ou organização da entrega em andamento

A ideia importante não é só criar arquivos, e sim manter relação entre eles. Decisões de produto devem bater com escolhas de stack, regras de workflow devem refletir a realidade da equipe, e o trabalho rastreado deve estar alinhado ao roadmap e às prioridades de implementação.

Como transformar um objetivo vago em uma invocação forte

Um prompt fraco:

• “Use context-driven-development for my project.”

Um prompt mais forte:

• “Use context-driven-development to create initial conductor/ artifacts for a brownfield SaaS repo. Infer product scope from README.md, src/, and issue labels. Capture stack choices from package.json, Docker config, and CI. Create product.md, tech-stack.md, workflow.md, and tracks.md. Flag assumptions separately from confirmed facts.”

Por que isso funciona melhor:

• informa o estado do repositório
• nomeia os artefatos desejados
• aponta as fontes de evidência
• pede separação entre suposições e fatos

Workflow sugerido para a primeira adoção

Um fluxo prático de context-driven-development usage:

1. Reúna as evidências atuais no repositório e na documentação.
2. Peça à skill para rascunhar os artefatos centrais em conductor/.
3. Revise erros factuais e restrições ausentes.
4. Resolva contradições entre documentação de produto, stack e workflow.
5. Só então comece tarefas de implementação ou planejamento que dependam desses artefatos.
6. Execute a skill novamente após mudanças relevantes de escopo, arquitetura ou workflow.

Essa sequência importa porque a skill foi feita para melhorar o trabalho posterior, não apenas para gerar documentos uma única vez.

Como usar bem os templates de artefatos

O arquivo references/artifact-templates.md é útil quando a skill tem informação parcial. Em vez de deixar o agente inventar seções ausentes, forneça respostas diretas para campos do template, como:

• personas-alvo
• status das funcionalidades
• métricas de sucesso
• justificativa das dependências
• escolha de hospedagem
• toolchain de testes e lint

Quanto mais partes do template você preencher com restrições reais, menos limpeza será necessária depois.

Dicas práticas que realmente mudam a qualidade da saída

Para ter resultados melhores com context-driven-development usage:

• peça que o agente marque explicitamente o que é desconhecido
• separe estado atual de estado futuro desejado
• deixe claro se as decisões estão fechadas, provisórias ou em aberto
• forneça exemplos do workflow da sua equipe se workflow.md for importante
• solicite checagens de consistência antes de aceitar os artefatos

Um padrão útil é: “Draft, then validate for cross-file contradictions.” Isso ajuda a encontrar desencontros como um roadmap prometendo apps mobile enquanto a stack e o workflow apontam para um MVP apenas web.

FAQ da skill context-driven-development

Vale a pena instalar context-driven-development se eu já escrevo bons prompts

Em geral, sim, se você volta ao mesmo projeto com frequência. Bons prompts ajudam em uma sessão. A context-driven-development skill ajuda a criar contexto durável, que prompts futuros podem reutilizar em vez de reconstruir do zero.

É amigável para iniciantes

Sim, mas apenas se você estiver disposto a responder perguntas básicas sobre o projeto. A skill dá estrutura; ela não cria clareza de negócio por conta própria. Iniciantes com objetivos vagos ainda podem receber artefatos genéricos até definirem usuários, funcionalidades e restrições de forma mais concreta.

Ela só funciona com Conductor

Ela foi pensada para artefatos de contexto no estilo Conductor, então esse é o encaixe ideal. Ainda assim, o método por trás dela é portátil: documentos estruturados de produto, stack, workflow e acompanhamento também ajudam em outros setups com IA.

Qual é o principal limite da skill

Ela não substitui experiência de implementação nem revisão de design de sistemas. A context-driven-development é mais forte em organizar o contexto do projeto, explicitar relações entre artefatos e manter a documentação alinhada com o trabalho.

Em que ela difere de simplesmente manter um README

Um README geralmente é mais amplo e voltado ao público. Esta skill empurra o projeto para um contexto operacional de desenvolvimento: o que é o produto, como a stack foi escolhida, como o trabalho avança e o que precisa permanecer consistente entre sessões com agentes.

Quando eu não devo usar context-driven-development

Não use em experimentos minúsculos e descartáveis, scripts de uso único ou projetos nos quais você não vai manter os artefatos. O valor vem do reuso contínuo e da sincronização ao longo do tempo, não apenas do primeiro rascunho.

Como melhorar a skill context-driven-development

Dê evidências para a skill, não aspirações

O maior salto de qualidade vem de ancorar a skill em evidências e decisões reais do repositório. Anexe ou referencie arquivos, configs e listas de funcionalidades reais. Se você fornecer apenas ambições, os artefatos vão soar como documentos genéricos de planejamento, e não como contexto de trabalho.

Peça fatos confirmados versus suposições inferidas

Um modo de falha comum é misturar fatos observados no repositório com palpites. Para melhorar as saídas de context-driven-development, peça duas camadas:

• confirmado a partir de arquivos ou documentação
• inferido com base em padrões ou informações ausentes

Isso acelera muito a revisão e reduz desvio acidental ao longo do tempo.

Torne cada artefato mais orientado a decisões

O que mais importa para os usuários é se os artefatos ajudam em sessões futuras de código. Para melhorar isso, faça com que cada arquivo seja orientado a decisões:

• product.md: quem, problema, escopo, métricas de sucesso
• tech-stack.md: ferramentas escolhidas e por quê
• workflow.md: como mudanças são propostas, implementadas, testadas e revisadas
• tracks.md: o que está ativo, bloqueado, próximo ou concluído

Se uma seção não ajuda a orientar uma decisão futura de código, vale enxugá-la.

Valide a consistência antes de confiar na saída

A skill fica mais útil quando você pede checagem de contradições como:

• escopo do produto maior do que o roadmap suporta
• escolhas de stack em conflito com restrições de deploy
• expectativas de workflow não sustentadas pelas ferramentas do repositório
• tracks desalinhados com as prioridades atuais

Essa etapa de validação é um dos hábitos de maior valor para context-driven-development for Context Engineering.

Melhore os prompts com instruções de leitura do repositório

Em vez de dizer “analyze my repo”, especifique onde está a fonte da verdade. Por exemplo:

• “Use package.json, Dockerfile, .github/workflows/, and README.md as primary evidence.”
• “Treat issue labels and milestone names as workflow clues.”
• “Prefer explicit config over naming heuristics.”

Isso reduz alucinações sobre stack e detalhes de processo.

Itere depois do primeiro rascunho, não antes

Um bom padrão é draft -> review -> refine. Primeiro, peça artefatos completos; depois, faça uma segunda passada com pedidos como:

• remover preenchimento genérico
• adicionar restrições ausentes
• transformar suposições em perguntas
• alinhar tracks ao roadmap
• atualizar a justificativa da stack com versões exatas, quando conhecidas

Na prática, essa iteração costuma funcionar melhor do que tentar acertar tudo no primeiro prompt.

Mantenha os artefatos vivos conforme o projeto muda

A decisão de context-driven-development install só compensa se a documentação continuar atualizada. Reexecute ou revisite a skill quando:

• a arquitetura mudar
• as prioridades mudarem
• as ferramentas mudarem
• aparecer atrito no onboarding
• as saídas do agente começarem a se descolar da realidade do projeto

Contexto desatualizado muitas vezes é pior do que contexto ausente, porque cria uma falsa sensação de confiança.