Tes propres blocs et pages
Ta propre page d’accueil et tes propres pages, construites dans le chat ou à partir de modèles.
Tu écris tes règles, Skills et Agents une seule fois. Trinity en fait les fichiers pour Claude Code, Copilot, Cursor et compagnie, te montre en direct ce que fait ton agent, et partage ce qui marche avec ton équipe.
Ce que d’autres ont construit, tu le reprends en un clic. Ton IA regarde d’abord où ça va dans ton projet, et rien n’est écrit avant ton OK.
Un dossier dans ton projet. Pour chaque IA.
Fini les cinq instructions IA qui se contredisent.
Tout ce dont ton IA a besoin pour le projet, au même endroit.Aujourd’hui, c’est éparpillé dans CLAUDE.md, les instructions Copilot, les règles Cursor, des notes et le wiki. Trinity rassemble tout dans ton projet et donne à chaque IA exactement le fichier qu’elle attend.
Fini de copier la même règle dans CLAUDE.md, le fichier Copilot et celui de Cursor.
Tu crées la règle une fois dans le Brain. Trinity l’écrit là où Claude Code, Copilot, Cursor, Windsurf et OpenClaw vont regarder.
Fini les « On en est où, au juste ? » au daily.
Brainstorm, Plan, Tasks ou tes propres phases par type de tâche. Quand une phase est finie, un agent vérifie en arrière-plan si elle est vraiment remplie. Ensuite seulement, l’agent suivant reçoit sa mission.
Fini de deviner ce que l’agent a fait.
Chaque fichier lu, chaque règle utilisée, chaque Skill et chaque modification, au moment où ça se passe. Ensuite, tout le run est dans l’historique et sur la tâche.
Fini les bons Skills qui prennent la poussière dans un seul repo.
Repère un Skill dans le feed, reprends-le, utilise-le tout de suite.Quelqu’un partage un Skill comme une publication. Tu le reprends, et dès lors chaque IA de ton projet peut s’en servir. Les quatre étapes défilent toutes seules, ou tu cliques dessus.
Fini les projets où personne n’a de vue d’ensemble.
Décris ce que tu veux voir, ou prends un modèle. L’IA en fait des blocs et des pages, aux couleurs de ton entreprise.
Voici comment une tâche se déroule avec Trinity, de l’idée au commit dans le repo.
Aurora Mobility est un service inventé de location de trottinettes et de vélos électriques. Clique librement, ou avance pas à pas avec « Suivant ».
Page d’accueil, look, règles, Agents, IA et langues se définissent par projet. Aucun projet n’a à ressembler à un autre ni à fonctionner pareil.
Ta propre page d’accueil et tes propres pages, construites dans le chat ou à partir de modèles.
Couleurs, polices et formes par projet, à l’image de l’entreprise.
Des règles, Skills et Agents valables uniquement dans ce projet.
Quel Agent passe après lequel.
Quelles IA participent : Claude Code, Copilot, Cursor ou d’autres.
Interface, travail et chat, chacun dans la langue que tu veux.
Le Workbench tourne dans le navigateur, directement dans ton projet. Chat avec planche, tâches, vue en direct et un tableau de bord que vous construisez vous-mêmes.
Brain et Memory : règles, Skills, Agents et état du projet, en fichiers dans le repo. Pareil pour chaque IA.
internal-trinity tourne sur votre propre serveur. Les équipes y partagent leurs Skills et Puzzles. Une Community publique est prévue.
CLAUDE.md, AGENTS.md, copilot-instructions.md, .cursor/rules, Skills, Hooks et MCP. Trinity n’invente pas de format maison pour vos fichiers d’IA.
Brain et Memory sont dans votre repo. Trinity ne fait que committer ; pusher et saisir les clés, c’est un humain qui le fait. internal-trinity tourne sur votre serveur.
Trinity n’apporte ni IA ni crédits à elle. Vous continuez simplement avec Claude Code, Copilot ou Cursor.
| Type | Dans le Brain | Claude Code | Copilot | Cursor |
|---|---|---|---|---|
| Instructions | Règles | CLAUDE.md | copilot-instructions.md | .cursor/rules/ |
| Skills | skills/ | .claude/skills/ | .github/prompts/ | .cursor/commands/ |
| Hooks | hooks/ | .claude/settings.json | .github/hooks/ | .cursor/hooks.json |
| Outils (MCP) | mcp/ | .mcp.json | .vscode/mcp.json | .cursor/mcp.json |
Un dossier nommé trinity-workbench que tu copies dans ton projet. Il contient un Brain (règles, Skills, Agents), une Memory (état du projet, tâches, historique) et une interface qui tourne dans le navigateur. Chaque IA du projet travaille avec.
Ni l’un ni l’autre. C’est toujours ton IA qui écrit le code : Claude Code, Copilot ou Cursor. Trinity veille à ce que chaque IA connaisse les mêmes règles et te montre ce qu’elle fait en ce moment.
Ces fichiers ne valent chacun que pour certains outils. Dans Trinity, tu gères vos règles à un seul endroit, et Trinity en tire le bon fichier pour chaque outil, plus les Skills, Hooks et entrées MCP. Ce que tu écris toi-même dans ces fichiers reste en place.
Le Brain, ce sont les règles selon lesquelles ton IA travaille (règles, modules, Skills, Agents). La Memory, c’est l’état de ton projet (projet, tâches, assets, historique). Un Skill est un mode d’emploi réutilisable que l’IA appelle pour une tâche précise, comme « écrire des tests ». Un Puzzle, c’est tout ce que tu peux partager et reprendre : Skills, règles, Hooks ou pages.
Les étapes d’une tâche, par exemple Brainstorm, Plan et Tasks. Chaque type de tâche peut avoir ses propres phases. Avant de continuer, un Agent vérifie en arrière-plan si la phase en cours est vraiment terminée.
Tout reste dans ton repo. Trinity committe, mais ne pushe jamais. Les clés d’API sont saisies par un humain, l’IA ne les voit jamais.
Chaque entreprise héberge internal-trinity elle-même, sur son propre serveur. trinity-community, la plateforme publique, est prévue.
Pas encore. Trinity n’est pas encore disponible au public. Pose tes questions à l’adresse de contact en bas de la page.
Chat, planche, tâches avec phases, Console Board et vue en direct.
Règles, Skills, Agents et l’état de ton projet.
Feed, profils et Skills à reprendre en un clic.
Trinity n’est pas encore disponible au public. Le contact se trouve en bas de la page.
Le Workbench est dans ton projet et tourne dans le navigateur. Que ce soit Claude Code, Copilot ou Cursor qui y travaille, c’est toi qui décides, et tu peux changer à tout moment. Règles, Skills, tâches et historique restent tels quels.
Une équipe décrit dans le chat ce dont elle a besoin. Trinity construit la page, et tout le monde dans le projet l’a aussitôt. Chaque projet a son propre look. Un peu plus d’une minute, sans son.
Trinity garde les règles, les Skills et l’état du projet, l’IA n’est que le moteur. Tu la choisis en bas du chat, et chacune reçoit le même savoir.
Fini de tout réexpliquer quand vous changez d’IA.
Tu choisis l’IA en bas du chat. Claude Code, Copilot et Cursor connaissent alors tous la tâche, sa phase, vos règles et vos Skills, parce que Trinity les leur transmet.
Fini de synchroniser des règles à la main dans cinq fichiers.
Trinity les écrit là où chaque IA regarde en premier. Via MCP, chaque IA lit et écrit aussi directement dans le projet, avec les mêmes possibilités que l’interface.
Fini les cinq terminaux où tu ne t’y retrouves plus.
Le Console Board lance toute IA dotée d’un CLI, comme Claude Code, Copilot, Codex, Gemini, Ollama ou OpenClaw. Tu les ranges en groupes, tu confies la direction à l’une d’elles et tu répartis sous-agents et passations. Quand l’une t’attend, tu entends un son.
Règles, Skills, Agents, Workflows, Hooks, tâches et historique sont au même endroit, et Trinity les donne à chaque IA dans son propre format. Chaque développeur travaille donc avec l’IA qu’il veut : Claude Code, Copilot, Cursor ou une autre. Changer de modèle ou de fournisseur ? Aucun problème, le harness reste le même.
Projet d’exemple aurora-app, chiffres inventés.
Fini l’agent censé planifier, coder et relire en même temps.
Dans Brain › Agents › Workflows, tu définis quel agent passe après lequel et quel Skill il utilise, par exemple planificateur, puis réalisateur, puis vérificateur. Un type de tâche lance le workflow, et le direct montre où il en est.
Fini de copier les Skills des autres à l’aveugle dans le repo.
Quand tu reprends un Skill, ton IA regarde d’abord où il va et s’il en existe déjà un similaire. Rien n’est écrit avant ton OK. Après l’exécution, Trinity vérifie que tout ce que le Skill doit livrer est là.
Des extraits du film, avec des projets d’exemple inventés.
Chat, planche, tâches, console et Live réunis dans une seule interface.
Ce que tu planifies avec l’IA devient une tâche sur le tableau et un croquis sur la planche.
Chaque projet reçoit une page d’accueil faite de blocs, construite toi-même ou à partir de modèles.
Décris la page dans le chat, et l’IA la construit directement dans ton interface.
Des modèles pour les types de tâches, les blocs et les pages donnent tout de suite une base à chaque nouveau projet.
Toute la Workbench tient dans le dossier trinity-workbench. À côté, Trinity crée seulement les fichiers que tes IA lisent en premier, comme CLAUDE.md, .github, .cursor, etc. Trinity ne touche pas à ton code.
ton-projet/ ├─ trinity-workbench/ │ ├─ trinity-app/ # l’interface │ ├─ trinity-brain/ # Règles, Skills, Agents │ └─ trinity-memory/ # Tâches, docs, historique ├─ CLAUDE.md # pour Claude Code ├─ .github/ # pour Copilot ├─ .cursor/ # pour Cursor ├─ .windsurfrules # pour Windsurf ├─ ai-assistant.md # pour toute autre IA └─ src/ … # ton code
Le framework, ce sont tes règles, Skills, Agents et l’état du projet. Tout est rangé en fichiers normaux dans le repo, et Claude Code, Copilot, Cursor et les autres en reçoivent la même chose.
Deux dossiers dans ton projet. Le Brain contient les règles, Skills, Agents et Hooks. Le Memory donne à chaque nouvelle session l’état du projet, pour que tu n’aies rien à réexpliquer.
Tu crées les règles, Skills et Agents une seule fois. Trinity les écrit dans CLAUDE.md, les instructions Copilot, les règles Cursor et les fichiers des autres IA, et te montre ce qui arrive chez chacune.
Fini de deviner ce que l’IA sait au démarrage.
Pour chaque IA activée, Trinity montre ce qui figure dans ses instructions au démarrage, ce qui ne s’ajoute que pour les fichiers concernés et ce qu’elle ne reçoit pas du tout. Avec un nombre approximatif de tokens.
Fini les outils qui écrasent ton CLAUDE.md.
Dans CLAUDE.md et les autres fichiers d’IA, Trinity ne gère que les blocs marqués. Ce que tu écris toi-même reste tel quel.
# aurora-app On répond en français. Releases le mardi uniquement. <!-- trinity:own-rules (géré par Trinity) --> ## Règles - trinity-brain/rules/api.md - trinity-brain/rules/sicherheit.md <!-- /trinity:own-rules --> Les questions sur le paiement vont à l’équipe Caisse.
Fini les règles que l’IA saute tout simplement.
Chaque règle et chaque Skill reçoit un poids. Pour une règle obligatoire, tu décides ce qui se passe si l’IA l’oublie : Trinity la lui rappelle, ou elle s’arrête et explique pourquoi. À la fin, un script ou un agent de vérification contrôle que la règle a été respectée.
Fini les IA qui doivent deviner comment ton projet est construit.
Y a-t-il un README avec de vraies commandes, l’architecture, une description du produit, un glossaire, des conventions et des instructions par IA ? Ce qui manque, Trinity le crée à partir d’un modèle ou le confie à l’IA, mais seulement avec ton accord.
La règle est écrite une seule fois dans le Brain. Trinity la place au bon endroit pour chaque IA.
Le Memory transmet à chaque nouvelle session le projet, la doc, les tâches et l’historique.
Ce qui est obligatoire, Trinity le vérifie après chaque exécution, par script ou agent de vérification.
internal-trinity, c’est le feed interne de ton entreprise pour les Skills, Agents et Workflows, et vous l’hébergez vous-mêmes. Les équipes y partagent ce qui marche, voient ce qui est le plus utilisé dans l’entreprise et le reprennent dans leurs projets.
Vous hébergez internal-trinity vous-mêmes. Vos Skills et Puzzles restent dans l’entreprise.
Un bon Skill est partagé une fois, et chaque équipe qui en a besoin le reprend.
L’IA propose où va chaque élément. Trinity vérifie la proposition, et tu donnes ton OK.
Tu vois qui est là et quels Agents tournent. Seuls ceux qui l’activent eux-mêmes sont visibles.
Voici à quoi ressemblerait internal-trinity chez Aurora Mobility, sur son propre serveur. Parcours le feed, une publication avec commentaires, la reprise avec l’IA, le partage, les personnes, Explorer et les projets.
trinity-community sera la face publique de Trinity. Des gens de nombreuses entreprises y partagent des Skills, Agents et Workflows, se suivent et reprennent ce dont ils ont besoin. Ton IA vérifie d’abord où ça va dans ton projet.
Le projet : des gens de nombreuses entreprises partagent leurs Puzzles, se suivent et reprennent ce qui leur convient. Voici à quoi ça pourrait ressembler, tous les contenus sont des exemples.
api-tests 3.0 est là : des tests pour chaque nouvel endpoint, désormais aussi pour GraphQL.
Repère les nouveaux endpoints dans le diff et écrit les tests qui vont avec.
Notre Agent de revue vérifie maintenant aussi que chaque changement a une tâche. Ça nous fait gagner des heures chaque semaine.
Lit le diff, la tâche et les règles, puis écrit une revue avec les risques.
Des tests pour chaque nouvel endpoint.
Cherche des clés avant chaque commit.
Changelog, numéro de version et notes avec quatre Agents.
Revue avec risques, tâche et règles.
Vérifie chaque import par rapport au schéma et aux données d’exemple.
L’accessibilité sous forme de règles pour chaque IA.
Changelog, numéro de version et notes de release, écrits par quatre Agents. Fonctionne avec chaque IA qui a Trinity dans le projet.
Platform chez NNorthbay Logistics · partage des Skills pour les releases et les reviews
C’est pour ça que partager vaut le coup. Tu vois dans combien de projets ton travail tourne et combien de fois d’autres l’ont repris.
Trinity est encore en cours de développement. Dès qu’il sera disponible, tu trouveras ici tout pour l’installer et travailler, dans chaque langue du site.
Vous définissez vos standards d’entreprise une seule fois dans le Brain, et chaque IA s’y tient. Tout reste dans votre repo, et rien ne sort sans qu’un humain le valide.
Les standards de l’entreprise sont dans le Brain. Chaque IA de chaque projet s’y tient.
Trinity ne pousse jamais tout seul. Un push n’a lieu que si un humain le déclenche.
C’est un humain qui saisit les clés. L’IA ne les voit jamais.
Chaque exécution figure dans l’historique et dans la tâche, avec tout ce qui a été lu, utilisé et modifié.
Le Brain reste le même, que ce soit Claude Code, Copilot ou un autre outil qui travaille demain.
Vous définissez une seule fois ce qui vaut partout et ce qui ne vaut que pour le frontend, le backend ou les données.
L’IA travaille avec vous, mais les étapes critiques sont toujours faites par un humain. Et tout ce qu’elle fait, vous pouvez le relire ensuite.
Fini les clés d’API qui atterrissent dans l’historique du chat.
Les clés des modèles et des outils restent uniquement sur la machine où elles ont été saisies. L’IA sait qu’une clé existe, mais jamais sa valeur.
Fini le code qui part sans qu’un humain l’ait regardé.
Les Agents peuvent travailler et faire des commits. Ça ne part dans le repo commun que quand quelqu’un de l’équipe clique sur « Push ». C’est intégré en dur, pas juste un réglage.
Fini les équipes qui ont chacune leurs propres règles d’IA.
Ce qui vaut partout, vous le définissez une fois. Ce qui ne vaut que pour le frontend, le backend ou les données aussi. Les nouveaux projets récupèrent les standards à l’installation, et vous voyez où ils tournent.
Fini de deviner ce que l’Agent a fait.
Quelle IA, quelle tâche, quelles règles elle a lues et quels fichiers elle a modifiés. C’est dans la tâche et ça reste dans le repo, y compris pour un audit.
Un classement issu d’internal-trinity. Il compte dans combien de projets de l’entreprise un Puzzle tourne.
Trinity n’est pas encore disponible publiquement. Cette page montre comment il fonctionne.