Que fait Planificateur de Documentation ?
Identifiez les lacunes du site de documentation et produisez un backlog priorisé.
Entrées
- Périmètre : Zone à évaluer — toute la documentation, une section spécifique ou un domaine fonctionnel. Par défaut : tout.
- Signaux (optionnel) : Problèmes GitHub, questions de la communauté, fils de support.
- Contexte concurrentiel (optionnel) : Ce que les concurrents documentent et que nous ne documentons pas.
Processus
Étape 1 : Inventaire de la documentation actuelle
Lisez site/src/config/navigation.yml pour l'arborescence de navigation complète — c'est la source de navigation de référence pour le site Astro, chargée par site/astro.config.mjs via site/src/sidebar.ts. Parcourez site/src/content/docs/**/*.{md,mdx} pour tous les fichiers de contenu. Classez chaque fichier par type de contenu (didacticiel, guide pratique, référence, explication, mixte) et par domaine couvert (démarrage rapide, outils, agents, multi-agents, déploiement, etc.).
Étape 2 : Identifier les lacunes
Comparez l'inventaire avec :
- Surface fonctionnelle du SDK : Toutes les fonctionnalités majeures sont-elles documentées ? Les fonctionnalités sans page de documentation sont des lacunes.
- Complétude Diataxis : Pour chaque domaine fonctionnel, la documentation existe-t-elle dans les quatre types ? Une fonctionnalité avec une référence mais sans didacticiel présente une lacune.
- Signaux de la communauté : Si GitHub CLI est disponible, extrayez les problèmes ouverts étiquetés "documentation" de strands-agents/harness-sdk. Mappez les questions à la documentation existante (peu claire/difficile à trouver) ou manquante (lacune de contenu).
- Comparaison concurrentielle (si fournie) : Que documentent LangChain, CrewAI, Anthropic et OpenAI à propos de fonctionnalités équivalentes que nous ne documentons pas ?
Étape 3 : Hiérarchiser
Attribuez un score à chaque lacune en fonction de l'impact sur le développeur et de l'effort :
- P0 (à faire maintenant) : Impact élevé, tout effort. Démarrage rapide, mise en route, concepts de base.
- P1 (à faire bientôt) : Impact moyen, effort faible. Guides pratiques manquants pour les tâches courantes.
- P2 (à planifier) : Impact moyen, effort élevé. Nouveaux didacticiels, explications architecturales.
- P3 (backlog) : Impact faible. Scénarios de niche, documentation de cas limites.
Étape 4 : Produire le backlog
Produisez-le en Markdown :
## Backlog de Documentation : [Périmètre]
**Généré le :** [date]
**Pages inventoriées :** [nombre]
**Lacunes identifiées :** [nombre]
### P0 : À faire maintenant
- [ ] [Tâche] — [type de contenu] — [page cible] — [raison]
### P1 : À faire bientôt
- [ ] [Tâche] — [type de contenu] — [page cible] — [raison]
### P2 : À planifier
- [ ] [Tâche] — [type de contenu] — [page cible] — [raison]
### P3 : Backlog
- [ ] [Tâche] — [type de contenu] — [page cible] — [raison]
### Matrice de Couverture
| Domaine fonctionnel | Didacticiel | Guide pratique | Référence | Explication |
|---|---|---|---|---|
| Bases des agents | O | ~ | O | N |
| Outils personnalisés | O | O | O | N |
| Multi-agents | ~ | N | O | ~ |
### Informations issues des signaux
- [Thème issu des signaux de la communauté mappé à des lacunes documentaires spécifiques]
Ce que cette compétence NE FAIT PAS
- N'écrit pas de documentation (utilisez plutôt docs-writer pour cela)
- Ne nécessite pas de pipelines de signaux externes (fonctionne avec le seul inventaire local)
- Ne crée pas automatiquement de tâches dans des outils externes