chancy24/codex-knowledge-base-skill

Maintien de la Base de Connaissances du Projet

Objectif

Utilisez cette compétence pour initialiser, maintenir et faire évoluer une base de connaissances au niveau du projet pour les agents de codage IA. La base de connaissances aide les futures sessions d'agent à comprendre l'objectif du projet, son architecture, ses interfaces, ses décisions, ses bogues et ses changements récents sans avoir à tout redécouvrir à partir de zéro.

Gardez le flux de travail neutre vis-à-vis des outils. Il doit être utilisable par Codex, Claude Code, Cursor, Gemini CLI et autres agents de codage capables de lire les fichiers du projet et de suivre des instructions locales au dépôt.

Quand l'utiliser

Utilisez cette compétence lorsque l'utilisateur demande de :

• initialiser une base de connaissances du projet
• résumer ou documenter un projet
• corriger un bogue et préserver l'expérience de correction
• ajouter ou modifier une fonctionnalité
• ajouter ou modifier une API, un schéma, une commande ou un format de données
• enregistrer une décision technique ou un compromis
• organiser des matériaux bruts du projet en connaissances structurées
• examiner ou faire le bilan d'une session de développement terminée
• mettre à jour AGENTS.md ou les fichiers sous knowledge/

Entrées

Les entrées courantes incluent :

• Le chemin du dépôt ou du projet cible actuel.
• Les fichiers de projet existants, le code source, la documentation, les issues, les journaux ou les matériaux bruts.
• La tâche actuelle de l'utilisateur et les modifications d'implémentation apportées pendant la session.
• Le contenu existant de AGENTS.md, knowledge/, raw/ ou skills/ le cas échéant.

Sorties

Les sorties attendues incluent :

• AGENTS.md règles du projet.
• knowledge/overview.md aperçu du projet.
• knowledge/business.md logique métier et scénarios d'utilisation.
• knowledge/architecture.md architecture système et flux de données.
• knowledge/api.md interfaces, schémas, commandes et structures de données.
• knowledge/decisions.md décisions techniques et compromis.
• knowledge/bugs.md historique des bogues, causes racines, corrections et règles de prévention.
• knowledge/changelog.md enregistrements des changements au niveau de la session.
• Dossiers optionnels raw/ et skills/ locaux au projet.
• Un court rapport final listant ce qui a été mis à jour et ce qui nécessite encore une vérification.

Flux de travail

1. Lisez d'abord les règles du projet :
   • AGENTS.md si présent.
   • knowledge/overview.md
   • knowledge/architecture.md
   • knowledge/decisions.md
   • knowledge/bugs.md
2. Si vous initialisez un dépôt, utilisez les modèles dans references/templates/ ou exécutez le script d'initialisation de ce package.
3. Comprenez la tâche actuelle et identifiez ce qui a changé :
   • objectif du projet ou logique métier
   • architecture ou limites des modules
   • API, commande, fichier de données, schéma ou structure de retour
   • symptôme du bogue, cause racine, correction ou règle de prévention
   • décision technique ou compromis
   • comportement visible par l'utilisateur ou convention d'interface utilisateur
4. Mettez à jour uniquement les fichiers de connaissances pertinents.
5. Supprimez ou réconciliez le contenu en double, obsolète ou contradictoire.
6. Mettez toujours à jour knowledge/changelog.md après un travail important.
7. Signalez les fichiers mis à jour et les validations manquantes.

Pour des conseils de maintenance plus détaillés, lisez references/playbook.md.

Mise à jour de knowledge/

Utilisez le plus petit fichier correspondant au changement :

• Mettez à jour overview.md pour l'objectif durable du projet, son périmètre, ses modules principaux et ses sorties majeures.
• Mettez à jour business.md pour les scénarios utilisateur, les flux de travail, les règles métier et les limites de sécurité.
• Mettez à jour architecture.md pour les relations entre modules, le flux de données, les modes d'exécution et les limites d'intégration.
• Mettez à jour api.md pour les points d'accès, fonctions, commandes, événements, fichiers de données, schémas et structures de retour.
• Mettez à jour decisions.md pour les choix techniques significatifs et les compromis.
• Mettez à jour bugs.md pour les bogues confirmés et les leçons apprises.
• Mettez à jour changelog.md pour chaque résumé de tâche important.

Ne déversez pas de raisonnement transitoire dans la base de connaissances. Préférez les faits stables, les décisions validées et les leçons réutilisables.

Rétrospectives de bogues

Lorsqu'un bogue est corrigé, mettez à jour knowledge/bugs.md avec :

• Symptôme du problème.
• Cause racine.
• Correction.
• Périmètre affecté.
• Validation effectuée.
• Règle pour prévenir la récurrence.

Si la cause racine est incertaine, marquez-la comme en attente de vérification plutôt que de deviner.

Changements d'interface

Lorsqu'une API, commande, fonction, schéma, CSV, événement ou format de fichier change, mettez à jour knowledge/api.md avec :

• Nom de l'interface.
• Méthode de requête ou style d'invocation.
• Chemin, commande, nom de fonction ou chemin de fichier.
• Entrées et paramètres.
• Format de réponse ou de sortie.
• Notes, contraintes et exemples.

Utilisez les noms exacts et l'orthographe des champs.

Décisions techniques

Lorsqu'un choix technique significatif est fait, mettez à jour knowledge/decisions.md avec :

• Contexte de la décision.
• Options envisagées.
• Choix final.
• Raison du choix.
• Conséquences et travail de suivi.

Enregistrez les décisions qui aideront les futurs agents à éviter de rouvrir des questions réglées.

Éviter la pourriture des connaissances

• Préférez modifier une entrée existante plutôt que d'ajouter une entrée quasi identique.
• Marquez le contenu obsolète comme remplacé ou remplacez-le par le fait actuel.
• Gardez les faits du projet séparés des spéculations.
• Utilisez des dates pour les décisions, les bogues et les entrées du journal des modifications.
• Gardez le langage neutre vis-à-vis des agents, sauf si une intégration d'outil spécifique nécessite une note spécifique à l'outil.
• Ne remplacez pas les règles du projet rédigées par l'utilisateur sans une demande explicite.

Réponse finale

Gardez la réponse finale concise. Incluez :

• Fichiers mis à jour.
• Validation effectuée.
• Toute vérification manuelle restante.