context-driven-development

Présentation de la compétence context-driven-development

Ce que fait la compétence context-driven-development

La compétence context-driven-development vous aide à créer et maintenir un petit ensemble d’artefacts de contexte projet dans un répertoire conductor/, afin que le développement assisté par IA repose sur une base stable et réutilisable. Au lieu de réexpliquer votre projet à chaque échange, vous définissez des documents de référence comme product.md, tech-stack.md, workflow.md et tracks.md, puis vous les mettez à jour au fil de l’évolution du projet.

À qui cette compétence s’adresse

Cette compétence convient particulièrement aux personnes qui utilisent des workflows de type Conductor, du développement IA sur plusieurs sessions, ou des environnements d’équipe où l’intention produit, les choix de stack et le suivi du travail doivent rester cohérents d’un prompt à l’autre. Elle est particulièrement utile pour :

• le démarrage d’un nouveau projet
• l’onboarding d’un agent IA sur une base de code existante
• les équipes qui veulent un contexte projet reproductible
• les utilisateurs lassés de perdre le contexte entre les sessions

Le vrai besoin auquel elle répond

La plupart des utilisateurs n’ont pas besoin de “plus de documentation”. Ils ont besoin que les sorties de l’IA cessent de dériver. Le rôle concret de context-driven-development est de transformer une connaissance projet floue et limitée à une session en artefacts gérés, qui survivent aux tâches d’implémentation, à la planification et aux passations.

Ce qui la différencie d’un prompting classique

Un prompt classique peut décrire votre application une fois. La context-driven-development skill vous apporte une structure pour garder cette description à jour et cohérente dans le temps. Son vrai différenciateur n’est pas la génération de code en elle-même, mais l’échafaudage de contexte et sa synchronisation avant et pendant le développement.

Ce que vous y gagnez si elle correspond à votre usage

Si vous utilisez context-driven-development for Context Engineering, le principal bénéfice est une meilleure continuité :

• une intention produit plus claire
• des décisions de stack documentées
• des attentes de workflow explicites
• des unités de travail suivies au lieu de TODOs dispersés
• un meilleur onboarding d’agent sur des repos brownfield

Quand ce n’est pas un bon choix

Évitez cette compétence si vous avez seulement besoin d’un snippet ponctuel, si vous ne comptez pas maintenir de documentation projet, ou si vous ne travaillez pas dans un workflow où un contexte persistant améliore réellement les résultats suivants. Elle apporte le plus de valeur lorsque le même projet est repris régulièrement.

Comment utiliser la compétence context-driven-development

Contexte d’installation et emplacement de cette compétence

Cette compétence provient du dépôt wshobson/agents, dans plugins/conductor/skills/context-driven-development. Le schéma d’installation de base dans les environnements compatibles Skills est :

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

Après l’installation, appelez-la depuis votre environnement IA lorsque vous devez initialiser ou mettre à jour le contexte projet, plutôt que de passer directement à l’implémentation.

Fichiers à lire en priorité avant la première utilisation

Pour démarrer vite et avec un minimum d’interprétation, lisez :

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

SKILL.md explique quand utiliser la compétence, comment les artefacts s’articulent entre eux et quel workflow de maintenance suivre. references/artifact-templates.md est le raccourci le plus utile en pratique : il montre la structure attendue de product.md, tech-stack.md et des fichiers associés, afin de fournir plus rapidement à l’agent des entrées complètes.

Les entrées dont la compétence context-driven-development a besoin

La compétence fonctionne bien mieux si vous fournissez assez de matière source pour générer ou mettre à jour les artefacts de contexte. Les bonnes entrées comprennent généralement :

• le type de projet : greenfield ou brownfield
• la structure actuelle du dépôt ou des dossiers
• la finalité du produit et ses utilisateurs cibles
• les contraintes techniques et les choix de stack
• les préférences de workflow de développement
• la roadmap actuelle, les jalons ou les éléments de travail
• la documentation existante comme README.md, des tickets, des notes d’architecture ou du code

Si vous dites seulement “set up context for my app”, la sortie restera générique. Si vous fournissez des éléments concrets sur le produit, la stack, le workflow et le dépôt existant, les artefacts deviennent nettement plus exploitables.

Usage greenfield : démarrer un nouveau projet

Pour un nouveau projet, utilisez context-driven-development afin de mettre en place les artefacts centraux avant d’écrire beaucoup de code. Une bonne demande précise par exemple :

• ce qu’est le produit
• à qui il s’adresse
• quelles fonctionnalités sont dans ou hors périmètre
• la stack attendue
• les attentes en matière de déploiement et de tests
• la façon dont le travail doit être suivi

La compétence est particulièrement précieuse ici, car elle force des décisions qui resteraient sinon floues jusqu’au démarrage de l’implémentation.

Usage brownfield : extraire le contexte d’un dépôt existant

Pour une base de code existante, demandez à la compétence d’inférer et d’organiser le contexte à partir du dépôt. Orientez-la vers :

• l’arborescence du code source
• les fichiers de dépendances
• la configuration CI
• le README et l’historique des issues
• la documentation existante
• les conventions de nommage et les indices de workflow

C’est souvent là que l’adoption crée rapidement de la valeur : le context-driven-development guide aide à transformer un repo qui “fonctionne mais reste difficile à expliquer” en artefacts qu’un agent pourra réutiliser ensuite.

Les artefacts clés et le rôle de chacun

Le dépôt s’articule autour de quelques fichiers persistants dans conductor/ :

• product.md : problème, utilisateurs, solution, fonctionnalités, métriques, roadmap
• tech-stack.md : langages, frameworks, dépendances, infrastructure, outils
• workflow.md : comment le développement est censé se dérouler
• tracks.md : unités de travail, statuts ou organisation continue de la livraison

L’idée importante n’est pas seulement de créer des fichiers, mais de maintenir leur cohérence. Les décisions produit doivent correspondre aux choix de stack, les règles de workflow doivent refléter la réalité de l’équipe, et le travail suivi doit rester aligné avec la roadmap et les priorités d’implémentation.

Transformer un objectif vague en invocation solide

Un prompt faible :

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

Un prompt plus solide :

• “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.”

Pourquoi cela fonctionne mieux :

• l’état du dépôt est précisé
• les artefacts cibles sont nommés
• les sources de preuve sont indiquées
• la séparation entre hypothèses et faits est demandée explicitement

Workflow recommandé pour une première adoption

Un flux d’usage context-driven-development pragmatique :

1. Rassemblez les éléments actuels dans le repo et la documentation.
2. Demandez à la compétence de rédiger une première version des artefacts centraux de conductor/.
3. Relisez pour corriger les erreurs factuelles et les contraintes manquantes.
4. Résolvez les contradictions entre les documents produit, stack et workflow.
5. Ne lancez qu’ensuite les tâches d’implémentation ou de planification qui s’appuient sur ces artefacts.
6. Réexécutez la compétence après tout changement majeur de périmètre, d’architecture ou de workflow.

Cet enchaînement compte, car la compétence est conçue pour améliorer le travail en aval, pas simplement pour générer des documents une seule fois.

Bien exploiter les modèles d’artefacts

Le fichier references/artifact-templates.md est particulièrement utile lorsque la compétence ne dispose que d’informations partielles. Au lieu de laisser l’agent inventer les sections manquantes, fournissez des réponses directes aux champs du modèle, par exemple :

• les personas cibles
• le statut des fonctionnalités
• les métriques de succès
• la justification des dépendances
• le choix d’hébergement
• la chaîne d’outils de test et de lint

Plus vous remplissez le modèle avec de vraies contraintes, moins vous aurez de nettoyage à faire ensuite.

Conseils pratiques qui changent vraiment la qualité du résultat

Pour de meilleurs résultats avec context-driven-development :

• demandez à l’agent de signaler explicitement les inconnues
• distinguez l’état actuel de l’état futur visé
• indiquez si les décisions sont arrêtées, provisoires ou encore ouvertes
• fournissez des exemples du workflow de votre équipe si workflow.md est important
• demandez des vérifications de cohérence avant d’accepter les artefacts

Un bon réflexe consiste à formuler la demande ainsi : “Draft, then validate for cross-file contradictions.” Cela permet de repérer des écarts, par exemple une roadmap qui promet des applications mobiles alors que la stack et le workflow décrivent en réalité un MVP web uniquement.

FAQ sur la compétence context-driven-development

Est-ce que context-driven-development vaut l’installation si je rédige déjà de bons prompts

Oui, dans la plupart des cas, si vous revenez souvent sur le même projet. De bons prompts aident sur une session donnée. La context-driven-development skill aide, elle, à créer un contexte durable auquel les prompts suivants peuvent se référer, au lieu de tout reconstruire à chaque fois.

Est-ce adapté aux débutants

Oui, mais seulement si vous êtes prêt à répondre aux questions de base sur le projet. La compétence apporte une structure, pas une clarté métier à votre place. Les débutants dont les objectifs restent vagues obtiendront encore des artefacts génériques tant qu’ils n’auront pas défini plus concrètement les utilisateurs, les fonctionnalités et les contraintes.

Est-ce que cela fonctionne uniquement avec Conductor

La compétence est pensée pour des artefacts de contexte de style Conductor, c’est donc son meilleur terrain d’usage. Cela dit, la méthode sous-jacente est portable : des documents structurés sur le produit, la stack, le workflow et le suivi du travail peuvent aussi aider dans d’autres configurations de développement assisté par IA.

Quelle est la principale limite de la compétence

Elle ne remplace ni l’expertise d’implémentation ni une revue de conception système. context-driven-development est surtout performante pour organiser le contexte projet, faire ressortir les relations entre artefacts et maintenir la documentation alignée avec le travail réel.

En quoi est-ce différent du simple maintien d’un README

Un README est généralement large et orienté vers un public externe. Cette compétence pousse vers un contexte opérationnel pour le développement : ce qu’est le produit, comment la stack a été choisie, comment le travail avance, et ce qui doit rester cohérent d’une session d’agent à l’autre.

Quand ne faut-il pas utiliser context-driven-development

Ne l’utilisez pas pour de petites expériences jetables, des scripts ponctuels ou des projets dont vous ne maintiendrez pas les artefacts. La valeur vient de la réutilisation et de la synchronisation dans la durée, pas seulement de la première version.

Comment améliorer la compétence context-driven-development

Donnez à la compétence des preuves, pas des intentions

Le plus gros saut de qualité vient d’un ancrage dans de vraies preuves du dépôt et de vraies décisions. Joignez ou référencez des fichiers, des configs et des listes de fonctionnalités réels. Si vous ne fournissez que des ambitions, les artefacts ressembleront à une documentation de cadrage générique au lieu d’un contexte de travail exploitable.

Demandez une distinction entre faits confirmés et hypothèses inférées

Un mode d’échec fréquent consiste à mélanger les faits observés dans le repo avec des suppositions. Pour améliorer les sorties de context-driven-development, demandez deux niveaux de lecture :

• confirmé à partir des fichiers ou de la documentation
• inféré à partir de motifs récurrents ou d’informations manquantes

La relecture devient alors beaucoup plus rapide, et le risque de dérive involontaire diminue.

Resserrez chaque artefact autour des décisions

Ce qui compte le plus pour les utilisateurs, c’est de savoir si les artefacts aideront réellement lors des prochaines sessions de code. Pour y parvenir, rendez chaque fichier orienté décision :

• product.md : pour qui, quel problème, quel périmètre, quels indicateurs de succès
• tech-stack.md : quels outils sont retenus et pourquoi
• workflow.md : comment les changements sont proposés, développés, testés et relus
• tracks.md : ce qui est actif, bloqué, à venir ou terminé

Si une section ne peut pas guider une future décision de développement, mieux vaut l’alléger.

Vérifiez la cohérence avant de faire confiance au résultat

La compétence est bien plus utile si vous lui demandez de contrôler les contradictions possibles, par exemple :

• un périmètre produit plus large que la roadmap
• des choix de stack incompatibles avec les contraintes de déploiement
• des attentes de workflow non prises en charge par l’outillage du repo
• des tracks qui ne correspondent pas aux priorités actuelles

Cette étape de validation fait partie des pratiques les plus rentables avec context-driven-development for Context Engineering.

Améliorez vos prompts avec des consignes de lecture du dépôt

Au lieu de dire “analyze my repo”, précisez où se trouve la vérité. Par exemple :

• “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.”

Cela réduit les hallucinations sur la stack et les processus.

Itérez après la première version, pas avant

Un bon schéma est : draft -> review -> refine. Demandez d’abord des artefacts complets, puis faites un second passage pour :

• supprimer le remplissage générique
• ajouter les contraintes manquantes
• transformer les hypothèses en questions
• aligner les tracks avec la roadmap
• mettre à jour la justification de stack avec les versions exactes lorsqu’elles sont connues

Cette itération donne généralement de meilleurs résultats que de vouloir perfectionner le premier prompt.

Gardez les artefacts vivants à mesure que le projet évolue

La décision d’installer context-driven-development ne porte ses fruits que si les documents restent à jour. Relancez ou revisitez la compétence lorsque :

• l’architecture change
• les priorités évoluent
• l’outillage change
• des frictions apparaissent à l’onboarding
• les sorties de l’agent commencent à s’éloigner de la réalité du projet

Un contexte obsolète est souvent pire qu’une absence de contexte, car il crée un faux sentiment de confiance.