Bienvenue dans Lyriks. L'installation est faite, bien joué !

Lyriks ne lit pas votre dépôt : c'est votre agent de code qui le lit, depuis l'intérieur du dépôt, et qui écrit la spécification dans Lyriks par le connecteur. Vous n'avez rien à rédiger.

Avec le MCP Lyriks, ingère tout ce dépôt dans le projet Lyriks {projet}.

1. Dans le portefeuille, New project, puis From a codebase. Lyriks vous donne une ligne à coller, avec le projet déjà nommé dedans.
2. Ouvrez votre agent à l'intérieur du dépôt (Claude Code, Codex, Gemini CLI, Copilot) et collez cette ligne. À la première exécution, il vous demande de vous connecter à Lyriks dans le navigateur.
3. Revenez sur le projet. Les sections se remplissent au fur et à mesure que l'agent les écrit, et il ne vous demande que les décisions que vos sources ne tranchent pas. L'attente est celle de votre agent, pas d'un traitement qui tournerait dans Lyriks.
4. Vous pouvez enfin lire ce que fait votre logiciel, et pourquoi. Ses intentions, ses règles métier, ses contraintes, et les points que le code seul ne permettait pas de trancher.

La ligne reste sur la page Kickoff du projet, à un clic de Foundation, pour la redonner plus tard à un autre agent.

Le projet s'ouvre sur Foundation, et la colonne de gauche porte le reste : Users & Permissions, Features, Experience, Data & Architecture, Glossary. Evolution n'en fait pas partie : c'est un onglet dans Features, à côté de l'arbre qu'elle change. Ouvrez une feature pour voir son intention, ses règles et ce qui en dépend.

Avec le MCP Lyriks, dis-moi ce que la spécification de {projet} dit du score
de cohérence : ce qu'il mesure, et par où commencer à le remonter.

1. Lisez les scores au pied de cette colonne. Coherence dit à quel point la spécification est exempte de contradictions, Coverage ce qui est présent, Build readiness s'il y a assez de profondeur pour construire.
2. Cliquez un score pour ouvrir le Control Center. Tous les problèmes y sont listés, le pire d'abord, chacun avec l'endroit où le corriger.
3. Prenez les contradictions avant les manques. Une contradiction fausse tout ce qui repose dessus ; un manque ne fait que limiter ce qui est couvert.
4. Vous arrêtez de fouiller le code pour savoir pourquoi une règle existe. La réponse, et tout ce qui en dépend, est à quelques clics.

Un changement reste à part de la spécification jusqu'à ce qu'il soit construit et vérifié. Lyriks l'appelle une evolution, et elle se fait dans des features qui existent déjà : ce dont elle a besoin de neuf apparaît dans le rapport d'impact, jamais comme une feature que vous créez à la main.

1. Features, son onglet Evolution, puis New evolution. Dites le changement en une phrase, puis choisissez les features qu'il touche.
2. Signez les valeurs. Cinq questions par feature touchée : objectif, problème, valeur, effet mesurable, critères d'acceptation. L'assistant propose une réponse avec ses sources ; vous l'acceptez, la reformulez ou la refusez, et l'accepter l'écrit sur la feature.
3. Calculez le rapport d'impact. Trois lectures, jamais fondues en une : si on l'ajoute, si on le change, si on le retire. Retirer ne casse pas ce que casse ajouter.
4. Vous savez ce que coûte le changement avant la première ligne de code. Les lignes marquées direct sont le travail lui-même. Les knock-on n'ont rien à modifier, elles reposent seulement sur ce qui bouge, donc elles sont à relire, à rejouer ou à refaire valider : c'est ça qui casse en silence.

Dans le projet Lyriks {projet}, ouvre une evolution pour ce changement :
{changement}. Dis-moi quelles features elle touche et ce qu'elle va me
demander de signer.

Calcule l'impact de l'evolution {nom} dans le projet Lyriks {projet}, et
donne-moi les trois lectures plutôt qu'un seul chiffre.

Ici, la spécification fait autorité et le modèle exécute. C'est ce qui rend les modèles interchangeables, et ce qui permet souvent à un modèle plus modeste de faire l'affaire : l'essentiel des erreurs d'un LLM vient de ce qu'il doit deviner l'intention.

1. Gelez la spécification en une version, puis demandez à votre agent d'implémenter l'evolution.
   Prompt Construire l'evolution Copier

   Implémente l'evolution {nom} du projet {projet} dans Lyriks en respectant
   strictement les valeurs signées dessus. Si une décision n'y est pas tranchée,
   arrête-toi et demande-moi plutôt que de choisir.

2. Il s'arrête et demande dès que l'evolution laisse une décision ouverte, au lieu d'en improviser une.
3. Verify : le code face à la spécification gelée, une ligne par attendu, chacune à vous de trancher. Une ligne que vous refusez vient avec un brief à recoller directement dans l'agent.
4. Ce qui part en production est ce que vous avez signé, et l'écart entre les deux est une liste que vous lisez, pas une surprise.