Code Health MCP (CodeScene)

Que fait Code Health MCP (CodeScene) ?

Retours de maintenabilité structurelle pour le codage assisté par IA. Complète les compétences de style/lint (coding-standards, plankton-code-quality) avec des scores de santé au niveau de la conception et des barrières de régression.

Amont : codescene-oss/codescene-mcp-server Paquet : @codescene/codehealth-mcp (stdio via npx)

Sécurité et limites

Opt-in (ECC) : Le bloc codescene dans mcp-configs/mcp-servers.json n'est qu'un modèle. Les installations de plugins ECC n'activent pas automatiquement les serveurs MCP fournis. Copiez l'entrée dans votre configuration uniquement si vous le souhaitez. Vous pouvez l'exclure lors de l'installation/synchronisation ECC avec ECC_DISABLED_MCPS=codescene,....

Identifiants : Aucun jeton fourni. Définissez CS_ACCESS_TOKEN vous-même (voir getting-a-personal-access-token.md dans le dépôt amont). Ne validez jamais les jetons dans le dépôt.

Ce que les outils lisent : Lorsqu'ils sont appelés, les outils analysent les fichiers et l'état git dans le dépôt local que vous leur indiquez (chemins que vous passez, plus le contexte de branche pour analyze_change_set). Ils ne s'exécutent pas seuls. Pour le mode autonome, suivez la documentation sur la confidentialité en amont : README codescene-mcp-server et politiques CodeScene. N'utilisez pas cette compétence pour les secrets, identifiants ou chemins que vous ne souhaitez pas analyser.

Si le MCP est indisponible (hors ligne, mauvais jeton, crash du serveur) : N'inventez pas de scores Code Health. Informez l'utilisateur que la vérification a été ignorée. Continuez uniquement avec l'approbation explicite de l'utilisateur. Préférez les vérifications lint/tests/boucle de vérification pour les barrières lorsque le MCP est indisponible. Réactivez les vérifications une fois le serveur connecté.

Quand utiliser

• L'utilisateur demande à examiner la qualité du code, refactoriser un fichier, ou vérifier si les modifications IA ont dégradé la maintenabilité
• Avant de modifier un hotspot, un module hérité ou un fichier inconnu
• Avant un commit ou une pull request lorsque vous avez besoin d'une garantie de maintenabilité
• Après un gros diff généré par un agent — vérifiez que Code Health n'a pas régressé
• Associer avec verification-loop, tdd-workflow, ou /quality-gate comme une vérification structurelle (pas un remplacement des tests/lint)

Quand activer

Mêmes déclencheurs que Quand utiliser ci-dessus — cet en-tête est ce qu'ECC utilise pour l'auto-activation de la compétence.

Comment ça fonctionne

1. Connecter le serveur MCP

Copiez l'entrée codescene de mcp-configs/mcp-servers.json dans votre configuration MCP.

Claude Code (~/.claude.json → mcpServers) :

"codescene": {
  "command": "npx",
  "args": ["-y", "@codescene/codehealth-mcp"],
  "env": {
    "CS_ACCESS_TOKEN": "YOUR_CS_ACCESS_TOKEN_HERE"
  }
}

Étendu au projet : fusionnez le même bloc dans .mcp.json à la racine du dépôt.

La configuration du jeton est documentée dans le dépôt amont (lien ci-dessus). Le mode autonome ne nécessite pas de compte payant CodeScene pour les quatre outils listés ci-dessous. Redémarrez la session et confirmez que le serveur codescene est connecté avant de vous fier aux scores.

2. Appeler uniquement les outils autonomes

Outil	Quand l'utiliser
code_health_review	Analyse structurelle complète avant de modifier un fichier
code_health_score	Score numérique rapide après chaque modification (vérification delta)
pre_commit_code_health_safeguard	Bloquer les commits qui introduisent des régressions Code Health
analyze_change_set	Vérification au niveau de la branche avant d'ouvrir une PR

N'appelez pas les outils réservés à la plateforme (par exemple, listes de hotspots de dette technique à l'échelle du dépôt). Ne référencez pas delta_analysis — pas disponible en mode autonome.

3. Interpréter les scores (1–10)

Plage	Signification	Comportement de l'agent
9.0–10.0	Vert — sain	Plus sûr à étendre ; préférez toujours les tranches verticales
4.0–8.9	Jaune — dette	Prudence ; pas de refactoring de passage
1.0–3.9	Rouge — dette sévère	Champ d'action limité uniquement

4. Exécuter la boucle de rétroaction

Avant de toucher à un fichier

1. Exécutez code_health_review sur le chemin cible.
2. Enregistrez le score de base et les odeurs de code listées.
3. Planifiez le plus petit changement qui répond à la tâche.

Portée par score : inférieur à 5 — diff minimal uniquement ; 5–7 — pas de refactoring large ; supérieur à 7 — plus sûr de refactoriser, vérifiez quand même après chaque édition.

Après chaque modification

1. Exécutez code_health_score sur le même fichier.
2. Comparez avec le score de base de code_health_review.
3. Si le score a régressé, corrigez avant de continuer. Ne marquez jamais la tâche comme terminée tant que le score est inférieur à celui de départ.

Avant chaque commit — exécutez pre_commit_code_health_safeguard sur le chemin du dépôt.

Avant une PR — exécutez analyze_change_set par rapport à la branche de base (par exemple main).

Exemples

Exemple : Amélioration de la maintenabilité Flask

Sur pallets/flask, une boucle d'agent utilisant uniquement des outils autonomes :

1. code_health_review sur un module cible (score de base 4.82)
2. Refactoring ciblé répondant aux odeurs listées
3. code_health_score après chaque édition
4. pre_commit_code_health_safeguard avant le commit
5. analyze_change_set avant la PR

Résultat : Code Health 4.82 → 9.1 (jeton autonome gratuit uniquement).

Exemple : Bloc de règle AGENTS.md

Collez dans le fichier AGENTS.md ou CLAUDE.md du projet :

## Code Health (CodeScene MCP)

Avant de modifier un fichier : exécutez `code_health_review`, notez le score et les problèmes.

- Score inférieur à 5 : plage problématique — limitez la portée des modifications.
- Score entre 5 et 7 : plage d'avertissement — pas de refactoring large.

Après chaque modification : exécutez `code_health_score` pour vérifier le delta.

- Si le score a régressé : corrigez avant de continuer ; ne déclarez jamais terminé si le score a baissé.

Avant chaque commit : exécutez `pre_commit_code_health_safeguard`.

Avant la PR : exécutez `analyze_change_set`.

Exemple : anti-patrons vs boucle correcte

# MAUVAIS : Modifier d'abord, vérifier ensuite
[gros refactoring sans code_health_review]

# MAUVAIS : Ignorer la baisse de score
"Les tests passent" → marquer la tâche comme terminée alors que Code Health a diminué

# MAUVAIS : Refactoring large sur un fichier à score rouge (inférieur à 5)
Nettoyage de passage sur tout le module

# BON : revue → petit changement → score → sauvegarde de commit → analyze_change_set

Association avec ECC

Compétence / flux ECC	Rôle de Code Health MCP
coding-standards	Style/noms ; Code Health = structure/complexité
plankton-code-quality	Lint/format à l'écriture ; Code Health = barrière structurelle avant/après édition
verification-loop / /quality-gate	Ajouter une vérification de régression structurelle avant "terminé"
security-review	Sécurité vs maintenabilité — utilisez les deux lorsque pertinent
tdd-workflow	Les tests qui passent ≠ conception saine — vérifiez le score après les refactoring

Conseil contextuel : ECC recommande de garder un faible nombre de MCP. Activez codescene lors des modifications substantielles ; désactivez-le lorsqu'il n'est pas nécessaire.

Compétences connexes

• coding-standards — conventions de base
• plankton-code-quality — hooks lint/format à l'écriture
• verification-loop — barrière build/test/lint
• tdd-workflow — développement piloté par les tests
• security-review — liste de vérification de sécurité
• documentation-lookup — documentation de bibliothèque via Context7 (orthogonal)