Un repo Meta unique pour que Claude ait accès à tous vos repo à jour

Il y a des Usecases hyper utiles où on aimerait que Claude ait accès à tous nos repo à jour:

🤔 permettre à nos métiers de poser des questions sur la base de code sans connaître git

🔍 faire de l’analyse support

💼 mettre de la configuration en commun sur tous nos repos

On va voir dans cet article comment le faire simplement via un repository meta.

Qu’est ce qu’un meta repository ?

C’est un repo git qui va pointer vers vos autres repository et qui a des commandes pour interagir avec: 

• une commande unique pour installer les projets et leurs dépendances
• une commande unique pour les mettre à jour 

Ca peut être fait via des libs toutes faites comme meta npm (pas vraiment maintenu), des subtree git ou l’outil repo ou simplement via des scripts maisons.

C’est tellement simple de demander à Claude de faire la configuration lui même via Make, Powershell ou autre qu’on va partir sur ça dans cet article: pas de dépendance à un tool externe, c’est juste un ou deux scripts hyper simples.

Mise en place

Le plus simple c’est de donner vos contraintes à Claude pour qu’il fasse tout lui même:

Je veux faire un repo "meta" c'est à dire qui va permettre de cibler mes repository: back front mobile comme actuellement, qu'il va pouvoir installer en une commande et avec un claude MD racine qui va entre autre avoir pour instruction "met à jour tous les projets sur main avec un checkout main + pull avant de répondre à la question ou faire de l'analyse". Propose des approches stp.  

Une fois fait, vous aurez un résultat de ce genre:

Uses Cases

1. Une source de vérité pour les équipes non-techniques

Vous pourrez faire un skill “ask-question” qui va pull tous les repo sur main (si vous êtes en déploiement continu) avant de répondre aux questions afin que les personnes non techniques puissent poser des questions sur le code. 

Conseil: Générez un document à la racine avec la description des repository et leur but afin que Claude n’ait pas à tous les scanner à chaque question et sache dans lesquels “piocher”.

Note: faut que les personnes aient accès aux repos Git en lecture évidemment, sinon c’est perdu 🙂

Résultat:

2. Une source d’investigation pour le support

Faites un skill “investigate” qui va mettre le  code à jour pour faire l’analyse de bug suivant  votre besoin:

Exemple: Si vous avez plusieurs versions en production, il pourrait vous demander la version avant chaque analyse

Résultat:

3. Mutualiser votre configuration

Hyper pratique pour vous et qui peut booster aux hormones les 2 usecases ci-dessus: mutualiser tous les skills / MCP communs à tous les projets.

Exemple: le MCP qui va lire vos logs, un autre qui a accès à votre base de données, un autre sur votre product analytics etc.. (en bonne intelligence évidemment: accès en lecture seule, rate limité avec les validations sécu de votre entreprise pour n’avoir accès qu’aux données en adéquation avec la RGPD et toutes normes auxquelles vous êtes contraints) 

Note: vous pouvez aussi mutualiser vos skills communs comme le déplacement d’état d’une issue ou autre.

Si vous faites tout ça, la valeur est énorme:

Une investigation support avec la trace, le code à jour du moment de l’incident, l’accès à votre stack d’observabilité et vos données: vous mettez vraiment toutes les chances de vos côtés !

Niveau métier c’est pareil: une question basée sur le code c’est bien, agrémenté de vraies données de production c’est vraiment game changer. On peut poser la question “comment ça marche, est-ce que c’est vraiment utilisé ? Si oui comment mesurer l’impact de la nouvelle feature que j’ai en tête ?

Conclusion

Le Meta repository c’est plus qu’un répertoire pratique pour ranger de la configuration, ça permet à tous le monde, tech et non-tech de profiter à pleine puissance des bénéfices de Claude. Le rapport gain / temps de mise en place est tellement énorme que je peux que vous conseiller de le mettre en place 😀