Examen de la Configuration Claude

Instructions

IMPORTANT : Utilisez la pensée structurée tout au long de votre processus d'examen. Planifiez votre analyse avant de fournir des commentaires. Cela améliore la précision et détecte les problèmes de sécurité critiques.

Étape 1 : Détecter le Type de Fichier

<thinking> Analysez les fichiers modifiés :

1. Quels fichiers .claude ont été modifiés ?
2. Quels types de fichiers ? (CLAUDE.md, skills, agents, prompts, commands, settings)
3. Y a-t-il des préoccupations de sécurité immédiates ?
4. Quel est le périmètre de l'examen (fichier unique ou multiple) ? </thinking>

Déterminez le(s) type(s) de fichier(s) principal(aux) en cours d'examen :

Règles de Détection :

• Agents : Modifications à .claude/agents/*.md ou plugins/*/agents/*.md
• Skills : Modifications aux fichiers skill.md ou fichiers de support des skills (listes de contrôle, références, exemples)
• CLAUDE.md : Modifications aux fichiers CLAUDE.md (n'importe quel emplacement : racine du projet, .claude/, ou sous-répertoires)
• Prompts/Commands : Modifications à .claude/prompts/*.md ou .claude/commands/*.md
• Settings : Modifications à .claude/settings.json ou .claude/settings.local.json

Si plusieurs types sont modifiés, examinez chacun avec la liste de contrôle appropriée.

Étape 2 : Exécuter l'Analyse de Sécurité (TOUJOURS)

<thinking> La sécurité d'abord, quel que soit le type de fichier :

1. settings.local.json est-il commité dans git ?
2. Des secrets en dur (mots de passe, tokens, clés API) ?
3. Les permissions sont-elles correctement ciblées (si settings modifié) ?
4. Des patterns suspects dans les fichiers modifiés ? </thinking>

VÉRIFICATIONS CRITIQUES (à effectuer pour TOUS les examens de configuration Claude) :

Exécutez immédiatement ces vérifications mentales :

• [ ] settings.local.json NOT in git (vérifiez la liste des fichiers modifiés)
• [ ] Aucune identifiant en dur dans aucun fichier modifié
• [ ] Permissions ciblées correctement (si settings.json modifié)
• [ ] Aucune clé API, token ou mot de passe en texte brut

Si TOUT problème de sécurité est détecté : Signalez comme CRITIQUE immédiatement, arrêtez et rapportez.

Consultez reference/security-patterns.md pour les vérifications de sécurité détaillées et les commandes de détection.

Étape 3 : Charger la Liste de Contrôle Appropriée

En fonction du type de fichier détecté, lisez et suivez la liste de contrôle pertinente :

• Agents → checklists/agents.md (YAML, sécurité d'accès aux outils, sélection de modèle, prompts système)
• Skills → checklists/skills.md (structure, YAML, divulgation progressive, qualité)
• CLAUDE.md → checklists/claude-md.md (clarté, références, pas de duplication)
• Prompts/Commands → checklists/prompts.md (objectif, contexte de session, références de skills)
• Settings → checklists/settings.md (sécurité, ciblage des permissions)

La liste de contrôle fournit :

• Stratégie d'examen multi-passes
• Quoi vérifier et quoi ignorer
• Guidance de pensée structurée
• Problèmes courants et signaux d'alerte

Étape 4 : Consulter les Matériels de Référence au Besoin

<thinking> Quand charger les références :

1. Besoin de classer la priorité du problème ? → priority-framework.md
2. Les patterns de sécurité sont flous ? → security-patterns.md
3. Exigences Claude Code (YAML, outils, modèles, limites) ? → claude-code-requirements.md </thinking>

Chargez les fichiers de référence uniquement quand nécessaire pour des questions spécifiques :

• Priorisation des problèmes → reference/priority-framework.md (CRITIQUE vs IMPORTANT vs SUGGÉRÉ vs OPTIONNEL)
• Patterns de sécurité → reference/security-patterns.md (commandes de détection, exemples de correction)
• Exigences Claude Code → reference/claude-code-requirements.md (frontmatter YAML, sélection de modèle, noms d'outils, divulgation progressive, conventions de settings)

Étape 5 : Documenter les Résultats

<thinking> Avant d'écrire chaque commentaire :

1. Niveau de priorité ? (Critique/Important/Suggéré/Optionnel)
2. Problème de sécurité ou problème de qualité ?
3. Quel est la correction ou recommandation spécifique ?
4. Quelle est la raison (pourquoi est-ce important) ?
5. Y a-t-il un lien de référence ou de documentation ? </thinking>

Cette section définit le format de sortie standard pour TOUS les examens de configuration Claude. Les listes de contrôle référencent cette section plutôt que de dupliquer le contenu.

CRITIQUE : Utilisez des commentaires inline sur des lignes spécifiques, PAS un grand commentaire récapitulatif.

Règles de Commentaires Inline :

• Créez un commentaire séparé pour CHAQUE problème spécifique sur la ligne exacte
• NE CRÉEZ PAS un grand commentaire récapitulatif avec tous les problèmes
• NE MODIFIEZ PAS les commentaires existants - créez toujours de nouveaux commentaires
• Incluez la correction spécifique avec exemple de code si applicable
• Expliquez la raison (pourquoi cela importe)

Format de Commentaire :

**[fichier:ligne]** - [PRIORITÉ] : [Description du problème]

[Correction spécifique avec exemple de code si applicable]

[Raison expliquant pourquoi cela importe]

Référence : [lien de documentation si applicable]

Exemple de commentaire inline :

**.claude/skills/my-skill/skill.md:1** - CRITIQUE : Frontmatter YAML manquant

Les skills nécessitent un frontmatter YAML pour être découverts par Claude Code :

\```yaml
---
name: my-skill
description: Description claire avec déclencheurs d'activation
---
\```

Sans frontmatter, le skill ne sera pas reconnu par Claude Code.

Référence : Documentation des Skills Anthropic

Quand utiliser inline vs résumé :

• Commentaire inline : Problème spécifique, recommandation, ou question (utiliser le format fichier:ligne)
• Commentaire récapitulatif : Évaluation globale, recommandation (APPROUVER ou DEMANDER DES CHANGEMENTS)

Chargez l'exemple spécifique pertinent à votre type de fichier (à la demande uniquement, pas au préalable) :

• Agents → examples/example-agent-review.md
• Skills → examples/example-skill-review.md
• CLAUDE.md → examples/example-claude-md-review.md
• Settings → examples/example-settings-review.md
• Prompts → examples/example-prompts-review.md

Enrichissement Entre Plugins

Détection Améliorée des Secrets (plugin bitwarden-security-engineer)

Quand le plugin bitwarden-security-engineer est installé, complétez l'analyse de sécurité manuelle ci-dessus avec :

• Patterns de secrets exhaustifs → activez Skill(detecting-secrets) pour une détection contextuelle qui distingue les fixtures de test des secrets de production, et couvre les patterns au-delà des vérifications manuelles ci-dessus (chaînes de connexion, clés privées, tokens de fournisseurs cloud)

Cette skill est optionnelle. Si non disponible, appuyez-vous sur les vérifications de sécurité manuelles ci-dessus.

Principes Fondamentaux

• Sécurité d'abord : Vérifiez toujours les settings commités, les secrets, les permissions trop larges
• La structure compte : Frontmatter YAML, références de fichiers, divulgation progressive, limites de lignes
• La qualité importe : Instructions claires, exemples, emphase appropriée, pensée structurée
• Efficacité des tokens : Divulgation progressive, tailles de fichiers appropriées, chargement à la demande
• Commentaires actionnables : Dites quoi faire et pourquoi, pas seulement quoi ne pas faire
• Ton constructif : Concentrez-vous sur le code/config, pas les personnes ; expliquez la raison