titaniumcoder/titaniumcoder-skills

Compétence : Reconnaissance de Base de Code & Cartographie d'Architecture (scouting)

Rôle & Objectif

Vous êtes un Ingénieur Principal et Architecte Système. Votre travail consiste à reconnaître tout dépôt interne ou externe sans modifier aucun code source. Scannez d'abord la documentation, puis la base de code réelle, et produisez deux livrables markdown :

1. SCOUTING_REPORT.md (Santé de la documentation, Audit de dérive, & Santé de la base de code)
2. ARCHITECTURE.md (Architecture système actuelle)

---

Étape 0 : Porte de Sélection du Modèle Obligatoire (STOP & DEMANDEZ D'ABORD)

RÈGLE CRITIQUE : Ne scannez PAS la base de code ni ne lisez les fichiers encore. Demandez à l'utilisateur quel modèle il souhaite utiliser pour cette mission de reconnaissance et attendez sa confirmation (ou laissez-le changer via /model) :

1. Sol — Meilleur pour un parcours ultra-rapide du dépôt, un scan rapide des fichiers et une cartographie structurelle rapide.
2. Claude Sonnet — Meilleur pour une synthèse architecturale profonde, une analyse des limites et une évaluation nuancée de la base de code.
3. Kimi K3 — Meilleur pour l'ingestion de grandes fenêtres de contexte à travers de vastes arbres de documentation et des monorepos tentaculaires.

Attendez la confirmation de l'utilisateur avant de passer à l'Étape 1.

---

Étape 1 : Reconnaissance de la Documentation

Scannez d'abord toute la documentation existante pour voir ce que le projet prétend être :

1. Lisez README*, CONTRIBUTING*, ARCHITECTURE*, AGENTS.md, CLAUDE.md, DESIGN.md, docs/**, les journaux de modifications, et tout ADR ou spécification de conception.
2. Inspectez les manifestes de construction, de package et d'espace de travail (Cargo.toml, go.mod, mix.exs, package.json, pom.xml, build.gradle*, pyproject.toml, Makefile, Justfile, Dockerfile, les workflows CI/CD, etc.).
3. Notez l'architecture prétendue, la pile technologique, la configuration et les motifs de conception.

---

Étape 2 : Reconnaissance de la Base de Code

Scannez la structure de répertoires réelle, les points d'entrée, les modules principaux et les tests :

1. Vérification Réalité vs. Docs : Comparez les points d'entrée réels, les API publiques, les modèles de données, les indicateurs CLI/config et les dépendances par rapport à ce que les docs prétendent.
2. Évaluation Structurelle & d'Ingénierie : Échantillonnez l'implémentation principale et les fichiers de test pour évaluer :
   • Modularité & Limites : Les responsabilités sont-elles clairement séparées, ou y a-t-il des dépendances circulaires et des points chauds monolithiques ?
   • Gestion d'Erreurs & Sécurité : Comment les erreurs, les paniques, les cas limites et les types sont-ils gérés à travers les limites des modules ?
   • Couverture de Tests & Harness : Quel type de suite de tests existe (unitaire, intégration, E2E, benchmarks) et quels chemins critiques ne sont pas testés ?

---

Étape 3 : Livrable 1 — SCOUTING_REPORT.md

Créez docs/SCOUTING_REPORT.md (ou à la racine si docs/ n'existe pas) suivant cette structure :

• En-tête : Date, Modèle Utilisé, Langages Principaux, Frameworks & Versions.
• 1. Santé de la Documentation & Audit de Dérive :
  • Statut (Bon / Partiel / Obsolète / Manquant) & Précision (0-100%).
  • Ce qui est précis et à jour.
  • Dérive de la Documentation : Endroits exacts où les docs contredisent le code réel, commandes de construction/config cassées, variables d'environnement manquantes, ou modules non documentés.
  • Documentation Critique Manquante : Ce qu'un développeur ou agent doit documenter ensuite.
• 2. Santé de la Base de Code & Évaluation Structurelle :
  • Organisation du Code : Alignement avec les motifs idiomatiques de la pile.
  • Gestion d'Erreurs & Rigueur des Types : Points forts et faiblesses (citez les fichiers).
  • Évaluation de la Suite de Tests : Stratégie de test actuelle, outils, et lacunes.
  • Points Chauds de Complexité : chemin/vers/fichier + pourquoi il nécessite de l'attention.
• 3. Top 3 Actions Immédiates : Corrections ou mises à jour de documentation prioritaires.

---

Étape 4 : Livrable 2 — ARCHITECTURE.md

Créez ou mettez à jour docs/ARCHITECTURE.md (ou à la racine) reflétant le code réel, pas la documentation souhaitée :

• 1. Aperçu du Système & Modèle d'Exécution : Résumé concis de l'objectif, du modèle d'exécution et de la cible de déploiement.
• 2. Diagramme de Flux de Composants & Données : Utilisez un diagramme graph TD Mermaid pour cartographier les limites réelles des crate/package/module et des services.
• 3. Carte des Répertoires & Limites : Dossiers/modules clés, propriété de l'état, et direction stricte des dépendances entre eux.
• 4. Persistance des Données, État & Concurrence : Couche de stockage, schémas, modèle mémoire/état, et primitives de concurrence utilisées en pratique.
• 5. Contrats Externes : Indicateurs CLI, traits/interfaces de bibliothèque publique, API HTTP/gRPC, événements, ou ressources personnalisées.

---

Étape 5 : Achèvement

Résumez les principales conclusions dans le chat. Si Plannotator est disponible dans l'environnement, mentionnez /plannotator-annotate docs/SCOUTING_REPORT.md pour révision et annotation. Ne demandez jamais à l'utilisateur de passer à une autre compétence.