Mise à jour des Noridocs

Aperçu

Les Noridocs sont des fichiers docs.md répartis dans la base de code qui documentent l'objectif, l'architecture et l'implémentation de chaque dossier. Mettez-les à jour après les modifications de code en utilisant le sous-agent nori-change-documenter.

Principe fondamental : Fournir du contexte → Dispatcher le sous-agent → Vérifier les mises à jour.

Annoncez au démarrage : « J'utilise la skill Updating Noridocs pour mettre à jour la documentation. »

Le processus

Étape 1 : Rassembler le contexte

Préparez les informations pour le sous-agent :

[ ] Qu'est-ce qui a changé ? (fonctionnalité ajoutée, bogue corrigé, refactorisation, etc.)
[ ] Pourquoi a-t-il changé ? (motivation, problème résolu)
[ ] Quels dossiers/fichiers ont été modifiés ?
[ ] Y a-t-il des changements architecturaux ou de nouveaux motifs ?

Étape 2 : Dispatcher le sous-agent nori-change-documenter

Utilisez l'outil Task avec le type nori-change-documenter :

Task(subagent_type: nori-change-documenter)

Dans le prompt, fournissez :

Une description claire de ce qui a changé et pourquoi
Les chemins de fichiers qui ont été modifiés
Le contexte pertinent des PR/commits
Toute implication architecturale
Toute documentation obsolète que vous avez remarquée et qui n'est pas directement liée à votre modification

Étape 3 : Vérifier les mises à jour

Vérifiez que la documentation a été mise à jour :

[ ] Exécutez git status pour voir quels fichiers docs.md ont changé
[ ] Vérifiez les diffs pour vous assurer que les mises à jour sont exactes
[ ] Vérifiez que les mises à jour portent sur l'architecture système, pas sur les détails

Format des Noridocs

Chaque docs.md suit cette structure :

# Noridoc: [Nom du dossier]

Path: [Chemin d'accès au dossier depuis la racine du repository. Toujours commencer par @. Par
  exemple, @/src/endpoints ou @/docs ]

### Overview
[Résumé de 2-3 points du dossier]

### How it fits into the larger codebase

[Description de 2-10 points sur la façon dont le dossier interagit avec et s'intègre dans d'autres
 parties de la base de code. Concentrez-vous sur les invariants système, l'architecture, les
 dépendances internes, les emplacements qui appellent ce dossier, et les emplacements vers
 lesquels ce dossier appelle]

### Core Implementation

[Description de 2-10 points des points d'entrée, des flux de données, des détails
 architecturaux clés, de la gestion d'état]

### Things to Know

[Description de 2-10 points des détails d'implémentation délicats, des invariants système,
 ou des surfaces d'erreur probables]

Created and maintained by Nori.

Les Noridocs ne doivent PAS lister les fichiers, maintenir des comptages, ni suivre les nombres de lignes. Ces motifs de documentation sont fragiles et casseront très rapidement.

Erreurs courantes

Fournir un contexte vague

Problème : Le sous-agent ne peut pas comprendre ce qui a changé
Solution : Soyez précis sur quoi/pourquoi/où

Ignorer la vérification

Problème : Mises à jour de documentation inexactes ou manquantes
Solution : Vérifiez toujours git diff après l'exécution du sous-agent

Documenter les changements triviaux

Problème : Bruit dans la documentation, effort gaspillé
Solution : Mettez à jour la documentation uniquement pour les changements architecturaux significatifs

Signaux d'alerte

Ne jamais :

Ignorer la fourniture de contexte au sous-agent
Supposer que la documentation a été mise à jour sans vérification
Mettre à jour la documentation manuellement au lieu d'utiliser le sous-agent

Toujours :

Fournir un contexte détaillé sur ce qui a changé et pourquoi
Vérifier que le sous-agent a mis à jour les fichiers docs.md appropriés
Se concentrer sur les changements au niveau de l'architecture/système

updating-noridocs