claude-config — Presentation Equipes

⚙

claude-config

Referentiel centralise de configuration Claude Code

v2.1.0

Standardiser • Distribuer • Evoluer

83

Skills

82

Commandes

14

Hooks

10

Serveurs MCP

5

Roles

Mars 2026 — Presentation equipes

Le defi

❌ Sans claude-config

• Chaque projet maintient sa propre config Claude Code
• Duplication de skills, hooks, regles entre projets
• Divergence progressive des configurations
• Pas de standard entre equipes
• Onboarding long pour chaque nouveau projet
• Mise a jour manuelle, projet par projet

✅ Avec claude-config

• Source unique de verite pour toutes les equipes
• Distribution automatisee en une commande
• Personnalisation par equipe et par role
• Standard commun avec flexibilite locale
• Onboarding en 3 minutes
• Sync bidirectionnelle parent ↔ enfants

common/* + teams/{team}/* + roles/{role}/* = Config Finale

💻

Axe Team

Stack technique

booking-api-legacy
Java 8, Spring 5.3, Struts 6.1

wcoff
Java 25, Spring Boot 3.5, hexagonal

+ votre equipe...

+

👥

Axe Role

Permissions

🛠 Dev — acces complet (83 skills)
📚 Techlead — dev + review
📋 PO — tickets & reporting (10 skills)
🔎 QA — tests & debug (15 skills)
🤖 Agent — headless autonome

+

🖥

Axe Platform

Runtime

macOS / Linux
Docker / Podman
MCP: bun / docker / npx (futur)

=

🎯

Config Finale

Personnalisee
pour chaque contexte

Exemple : Un PO sur l'equipe booking-api-legacy sur macOS recoit 10 skills (po, mep, weekly-report...), 3 serveurs MCP (Jira, Confluence, Teams), et les regles de ticket WCBOO.

⚙ Workflow & Implementation

epct— Workflow 9 phases (explore → doc)

refactor— Refactoring 8 phases + non-regression

oneshot— Implementation rapide (<1h)

🔎 Analyse & Debug

debug— Diagnostic systematique d'erreurs

techlead— Analyse architecture & design

deep-code-analysis— Investigation multi-fichier

explore— Recherche rapide codebase

🔒 Securite

security:cve— Analyse CVE Checkmarx SCA

security:static— Analyse SAST code statique

security:dependency— Traitement dependances via Chrome

gitleaks— Detection de secrets dans le code

🧪 Testing & Qualite

bruno— Tests E2E API

postman— Collections Postman

coverage— Couverture JaCoCo

code-review— Revue A-F + audit OWASP

lint-fix— Correction checkstyle/SonarQube

sonar— Analyse quality gates

simplify— Opportunites de reuse

📁 Git Ops & CI/CD

commit— Commit & push rapide

create-pull-request— MR auto-generee

fix-pr-comments— Corriger les retours MR

watch-ci— Surveiller & auto-fix pipeline

release— Tag, publish, bump version

📝 Documentation & Notifications

doc:create— Generer docs depuis le code

doc:validate— Verifier la doc vs code

doc:sync— Publier sur Confluence

teams-notify— Notification Adaptive Card

📋 Gestion de projet & Tooling

po— Creer des tickets Jira

weekly-report— Rapport hebdo Teams

infra-upgrade— Upgrade JDK, middleware

n8n— Workflow automation

claude-memory— Gerer CLAUDE.md

skill-builder— Creer & optimiser des skills

update-config— Mettre a jour depuis claude-config

note— Prise de notes rapide

💻 booking-api-legacy 15 skills

splunk— Orchestrateur logs Splunk

splunk-investigate— Investigation incident par CJID

splunk-apigee— Logs API Management Apigee

splunk-reference— Fields natifs, sourcetypes, hosts

bruno-sanity— Tests non-regression E2E

bruno-promote— Promouvoir en suite non-regression

mep— Creer les tickets de mise en prod

incident— Orchestration incident prod + SNOW

incident-knowledge— Base de connaissances incidents

splunk-alert— Configurer alertes Splunk + ServiceNow

create-change:apigee— CHANGE ServiceNow Apigee

apache-deploy— Deploy HTML vers Apache statique

presentation— Slides HTML interactives

activity-report— Rapport d'activite equipe en slides

release— Release Maven + Nexus specifique

⚡ wcoff 8 skills

deploy-cloud— Deploy AWS ECS via JIB + Fargate

terraform— Infrastructure as Code AWS

mutation-testing— PIT : qualite des tests par mutation

renovate— Gestion MR de mise a jour dependances

mkdocs— Site de documentation statique

review-env— Environnement ephemere par MR

security-waf— Regles AWS WAFv2 & Web ACL

security-checkov— Scan securite Terraform

Principe : Les skills communs sont dans templates/common/ et distribues a toutes les equipes. Les skills specifiques sont dans templates/teams/{team}/ et ne sont installes que pour l'equipe concernee. Le catalog.json definit la visibilite de chaque skill : "scope": "universal" ou "team-specific".

Workflow EPCT — un squelette commun, des implementations specifiques

🔍 explore

Sonnet

→

📋 plan

Sonnet

→

📝 tasks

Sonnet

→

🧪 tdd

Opus

→

💻 code

Opus

→

🧪 test

Opus

→

🚀 deploy

Haiku

≠

→

✅ validate

Haiku

≠

→

🔎 e2e

Sonnet

≠

→

📝 doc

Sonnet

Implementation differente par equipe Phase desactivable par equipe

Meme phase, implementation differente selon l'equipe

Phase EPCT	💻 booking-api-legacy	⚡ wcoff
deploy	`./scripts/main.sh -a startdev` Maven WAR → Tomcat 9 local	`mvn spring-boot:run` ou `docker-compose up` Spring Boot + JIB → ECS
validate	✅ `/bruno:sanity` Collections Bruno E2E sur endpoints REST	⚠ Tests d'integration Python `python3 backend/test_jira.py` + health check
e2e (bruno)	✅ `/epct:bruno` Creation collection Bruno + promotion non-regression	❌ Phase desactivee Pas de Bruno — couvert par les tests d'integration
test	`./scripts/main.sh -a test` JUnit 4 + Mockito, sub-agent background	`mvn test` JUnit 5 + Spring Boot Test
code	🚫 Java 8 : var, toList(), isEmpty() interdits	✅ Java 25 : records, sealed classes, pattern matching

Quand est-ce que la distinction est faite ? A l'installation. Le workflow EPCT est commun dans templates/common/, mais les variables {{BUILD_CMD}}, {{TEST_CMD}}, {{HEALTH_CHECK_ENDPOINT}} et les phases activees/desactivees sont definies dans teams/{team}/variables.json. L'installateur substitue ces valeurs et produit un EPCT adapte a chaque equipe.

Structure a 2 niveaux

🌐 templates/common/ — Universel

🚀 83 skills partages entre toutes les equipes
📄 82 commandes slash (shortcuts)
🔌 14 hooks (validation, notification, audit)
🤖 6 agents (explore, action, fix...)
📚 Templates de rapports
📃 Regles de conventions communes

Les skills communs utilisent des {{VARIABLES}} resolues a l'installation selon les valeurs de l'equipe cible.

🛠 templates/teams/{team}/ — Specifique

📝 CLAUDE.md specifique a la stack
📋 Variables (100+ par equipe)
📄 Commandes specifiques
📚 Skills additionels ou overrides
📃 Regles techniques (Java version, etc.)
📖 Documentation base de connaissances

Comparaison equipes

	💻 booking-api-legacy	⚡ wcoff
Java	8 var interdit	25 records, sealed
Framework	Spring 5.3 + Struts 6.1	Spring Boot 3.5 + Jakarta EE
Build	`./scripts/main.sh -a startdev`	`mvn spring-boot:run`
Deploy	Tomcat 9 + Ansible	JIB + AWS ECS
Ticket prefix	WCBOO	(auto)
Variables	100+	50+
EPCT phases	Toutes (10/10)	8/10 (validate, bruno desactives)

Chaque role recoit exactement ce dont il a besoin

🛠

Dev

83

skills

Acces complet. Code, review, deploy, security, tests.

10 MCP

📚

Techlead

83

skills

Dev + architecture, guidance equipe, documentation.

10 MCP

📋

PO

10

skills

Tickets, reporting, MEP. Pas de code, pas de deploy.

3 MCP

🔎

QA

15

skills

Tests, debug, logs. Code interdit sauf Bruno.

3 MCP

🤖

Agent

∞

headless

Autonome Docker. CI/CD, taches planifiees, incidents.

All MCP

Matrice Role / Capacite

Capacite	🛠 Dev	📚 TL	📋 PO	🔎 QA	🤖 Agent
Modifier le code	✅	✅	❌	❌	✅
Creer des tickets Jira	✅	✅	✅	✅	✅
Code review	✅	✅	❌	❌	❌
Tests E2E (Bruno)	✅	✅	❌	✅	✅
Scans securite	✅	✅	❌	❌	✅
Deploy	✅	✅	❌	❌	✅
Logs Splunk	✅	✅	❌	✅	✅
MEP / Release	✅	✅	✅	❌	✅

Une commande, tout est configure

bun run install.ts --team=booking-api-legacy --role=dev --target=/path/to/project

1

loadConfig

Charge claude-config.json, roles.json, catalog.json, servers.json, team.json, variables.json

2

detectPlatform

OS, container runtime (docker/podman), preference mode MCP

3

checkPrerequisites

Verifie Bun, Git, deps optionnelles (docker, java, maven)

4

backupExisting

Cree .claude.backup.YYYYMMDD si .claude/ existe deja

5

copyFiles

Templates → projet, filtrage role, substitution {{VAR}}, manifest SHA256

6

cleanupOrphans

Detection interactive des fichiers orphelins (3 niveaux de confirmation)

7

assembleClaudeMd

Concatene common + team + role CLAUDE.md avec substitution variables

8

generateMcpConfig

.mcp.template.json avec selection mode serveur (bun/docker, npx futur)

9

generateSettings

Produit hooks.template.json, permissions.template.json, env.template.json

✓

Pret !

bootstrap.ts merge les templates au demarrage de chaque session Claude Code

Automatisations a chaque etape du workflow

🔌 Pre-commit & Pre-action

Pre validate-commit-message — Format WCBOO-XXXX [emoji] description

Pre protect-secrets — Bloque les commits avec secrets (.env, .conf, tokens)

Pre validate-lint — Checkstyle / SonarQube avant commit

Pre enforce-jira-template — Verifie references template Jira

Pre validate-teams-template — Valide les cartes Teams (webhooks, placeholders)

📢 Post-action & Session

Post notify-mr-created — Notification Teams a la creation d'une MR

Post escalate-on-error — Escalade Teams quand une erreur critique survient

Post notify-action-taken — Notifie chaque action prise

Jira notify-mep — Notification creation tickets MEP

Jira notify-ticket-assigned — Notification assignation ticket

Session audit-trail — Log de toutes les actions dans .logs/audit

Session reflect — Rapport de reflexion en fin de session

Filtrage par role : PO exclut validate-lint et validate-commit-message. QA exclut validate-lint, validate-commit-message et notify-mr-created. Agent herite de tous + 3 hooks supplementaires (audit, escalation, notification).

Integrations externes via Model Context Protocol

Serveur	Usage	Bun	Docker	NPX futur	Roles
Jira	Tickets, sprints, epics	✅	✅	🕐	All
GitLab	MR, branches, pipelines	✅	✅	🕐	Dev, TL, Agent
Confluence	Wiki, sync docs	✅	✅	🕐	Dev, TL, PO
Splunk	SPL queries, logs	✅	✅	🕐	Dev, TL, QA
Teams	Notifications, webhooks	✅	✅	🕐	All
masked-read	Config/secrets masques	✅	✅	🕐	Dev, TL, QA
context7	Documentation librairies	—	—	✅	Dev, TL
n8n	Workflow automation	—	—	✅	Dev, TL, Agent
n8n-accor	Workflows Accor cloud	—	—	✅	Dev, TL

🕐 = prevu — le mode NPX pour les serveurs internes (Jira, GitLab, Splunk...) n'est pas encore en place. context7, n8n et n8n-accor utilisent deja NPX car ce sont des packages publics.

Modes d'execution

⚡ Bun (monorepo) actif

bun run ${MCP_SERVERS_PATH}/...
Le plus rapide. Necessite le monorepo mcp-servers clone localement.

📦 Docker (images) actif

docker run --rm -i mcp-servers/...
Isolation complete. Images pre-buildees avec presets.

📦 NPX (fallback) futur

npx -y @accor/mcp-jira
Aucun pre-requis. Ideal pour PO/QA sans Docker.
Necessite la publication npm des serveurs internes.

Flux bidirectionnel

💻

Projet enfant A

booking-api-legacy

← /reverse-sync

install.ts →

/update-config →

⚙

claude-config

Referentiel central

/reverse-sync →

← install.ts

← /update-config

💻

Projet enfant B

wcoff

→ Forward: install.ts

Distribution initiale du referentiel vers le projet enfant.
• Filtrage role
• Substitution {{VAR}}
• Tracking SHA256 (manifest)
• Backup automatique

← Reverse: /reverse-sync

Remonter les modifications d'un projet enfant vers le referentiel.
• Reverse-substitution automatique
• Classification: common / team / ignore
• Ajout au catalog.json
• Plan de synchro avant application

🔄 Update: /update-config

Tirer les dernieres modifications du referentiel.
• --branch=feature/xxx
• --pull-only (git pull seul)
• --dry-run (preview)
• Preserve les fichiers modifies localement

Manifest SHA256 : A chaque installation, un hash SHA256 est calcule pour chaque fichier copie. Lors d'une mise a jour, les fichiers modifies par l'utilisateur sont detectes et preserves — aucun risque d'ecrasement.

Execution autonome sans intervention humaine

🔌 Triggers

🌐 Webhook — port 8080, /api/trigger
🔑 SSH — connexion directe au container
📁 File watch — /app/inbox/*.json

🔒 Permissions

✅ Auto-approve toutes les actions
🔐 Git push: branch-only
📄 MR: draft uniquement (jamais merge)
🚫 Branches protegees: main, master, develop, release-*

🚨 Escalation

❌ on_error → cree ticket Jira + notifie Teams
⚠️ on_low_confidence → cree ticket + notifie
🔄 on_test_failure_after_fix → revert + escalade

🔌 3 hooks supplementaires

📝 audit-trail — log complet de chaque action
🚨 escalate-on-error — alerte automatique
📢 notify-action-taken — transparence totale

Cas d'usage : CI/CD automatique, taches planifiees (cron), remediation d'incidents, execution de taches Jira en background. L'agent fonctionne dans un container Docker isole avec son propre CLAUDE.md et ses propres regles d'escalation.

Ajouter une nouvelle equipe en 3 etapes

1

Detection automatique du stack

bun run tools/onboard-team.ts --detect --target=/path/to/project
Analyse le pom.xml, package.json, Dockerfile, etc. pour determiner la stack.

2

Generation interactive de la config

bun run tools/onboard-team.ts --create --team=my-api --target=/path
Genere team.json + variables.json (50+ variables documentees avec _doc_*).

3

Installation one-command

bun run install.ts --team=my-api --role=dev --target=/path/to/project
Copie, substitution, merge CLAUDE.md, generation MCP, settings, hooks — tout est pret.

✓

Pret a utiliser !

Ouvrir Claude Code dans le projet → le bootstrap resout les templates → 83 skills disponibles.

Template equipe : Le dossier config/teams/_example/ sert de modele. Chaque variable dans variables.json est documentee avec une cle _doc_ expliquant son role.

Validation : bun run validate verifie les variables non resolues, la coherence des references, et teste la resolution sur toutes les equipes.

Le projet claude-config a ses propres skills — non distribues aux enfants

🔄 reverse-sync

Remonte les modifications d'un projet enfant vers le referentiel.
• Scan git status .claude/ du projet source
• Classification : common team-specific ignore
• Reverse-substitution : remplace les valeurs concretes par {{VAR}}
• Mise a jour automatique de catalog.json

👥 team-onboarding

Integre une nouvelle equipe dans le referentiel.
• Detection automatique du stack (pom.xml, Dockerfile...)
• Generation team.json + variables.json (50+ variables)
• Chaque variable documentee avec _doc_*
• Dry-run de validation avant application

📁 create-mr

Cree une MR GitLab pour claude-config avec reviewers et notification Teams automatique.

📋 po (adapte)

Gestion backlog Jira multi-equipe — demande l'equipe cible avant creation du ticket.

Validation de coherence inter-equipes

🛡 validate-config — 6 phases de verification

1. Common Templates Scan
Detecte les valeurs specifiques a une equipe qui se seraient glissees dans templates/common/ (URLs, ports, container names...)

2. Variables Resolution
Verifie que chaque {{PLACEHOLDER}} existe dans _example/variables.json et est resolu pour toutes les equipes

3. Inter-Team Coherence
Chaque variable du template doit exister dans toutes les equipes. Verification de coherence de type.

4. Git Diff Analysis
Analyse les lignes ajoutees dans les templates communs pour detecter des valeurs hardcodees specifiques

5. Skill Routing Collision
Detecte les collisions de keywords entre skills visibles pour une meme equipe. Verifie le WHEN/THEN du CLAUDE.md.

6. Report Generation
Rapport avec status FAIL WARN OK par categorie. Bloque si FAIL > 0.

Objectif : Garantir que ce qui est remonte par un projet enfant (/reverse-sync) ne casse pas les autres equipes. Un skill specifique a l'equipe A ne doit pas entrer en conflit avec les keywords de l'equipe B. Une variable ajoutee dans les templates communs doit etre definie pour toutes les equipes.

Benefices

📈
Standardisation

                        Un referentiel unique, des pratiques communes a toutes les equipes
                    

⚡
Productivite

                        83 skills prets a l'emploi, onboarding en 3 minutes
                    

🔒
Securite

                        Hooks de protection, filtrage par role, audit trail
                    

📝
Tracabilite

                        Rapports, notifications, manifest SHA256
                    

Contribution & Evolution

🔄 Bidirectionnel

Chaque equipe peut enrichir le referentiel via /reverse-sync. Les innovations locales beneficient a tous.

🚀 Extensible

Ajout de teams, roles, skills, hooks sans impact sur l'existant. Architecture modulaire par design.

⚙

claude-config v2.1.0

83 skills • 82 commandes • 14 hooks • 10 MCP • 5 roles

bun run install.ts --team=<your-team> --role=<your-role> --target=<your-project>

Standardiser • Distribuer • Evoluer