Welcome to Lyriks. The installation is done, well played!

Lyriks does not read your repository: your coding agent does, from inside the repo, and writes the specification into Lyriks through the connector. You have nothing to write.

With the help of the Lyriks MCP, ingest this entire codebase into the Lyriks
project {project}.

1. In the portfolio, New project, then From a codebase. Lyriks hands you one line to paste, with the project already named in it.
2. Open your agent inside the repository (Claude Code, Codex, Gemini CLI, Copilot) and paste that line. On the first run it asks you to sign in to Lyriks in your browser.
3. Come back to the project. The sections fill in as the agent authors them, and it asks you only for the decisions your sources cannot settle. The wait is your agent's, not a job running somewhere in Lyriks.
4. You can finally read what your software does, and why. Its intents, its business rules, its constraints, and the points the code alone could not settle.

The line stays on the project's Kickoff page, one click from Foundation, so you can hand it to another agent later.

The project opens on Foundation, and the left column holds the rest: Users & Permissions, Features, Experience, Data & Architecture, Glossary. Evolution is not one of them: it is a tab inside Features, beside the tree it changes. Open a feature to see its intent, its rules and what depends on it.

Using the Lyriks MCP, tell me what the specification of {project} says about
the coherence score: what it measures, and where to start raising it.

1. Read the scores at the foot of that column. Coherence is how free of contradictions the specification is, Coverage what is present, Build readiness whether there is enough depth to build on.
2. Click a score to open the Control Center. Every issue is listed there, the worst first, each with the place to fix it.
3. Take the contradictions before the gaps. A contradiction distorts everything that rests on it; a gap only limits what is covered.
4. You stop digging through the code to find out why a rule exists. The answer, and everything that depends on it, is a few clicks away.

A change stays apart from the specification until it is built and verified. Lyriks calls it an evolution, and it is made in features that already exist: whatever new it needs shows up in the impact report, never as a feature you create by hand.

1. Features, its Evolution tab, then New evolution. Say the change in one sentence, then pick the features it touches.
2. Sign the values. Five questions per touched feature: objective, problem, value, measurable effect, acceptance criteria. The assistant proposes an answer with its sources; you accept it, reword it or refuse it, and accepting writes it on the feature.
3. Compute the impact report. Three readings, never merged into one: if we add it, if we change it, if we remove it. Removing does not break what adding breaks.
4. You know what the change costs before a line of code is written. The rows marked direct are the work itself. The knock-ons have nothing to edit, they merely rest on what changes, so they have to be re-read, re-run or re-approved: that is what breaks quietly.

In the Lyriks project {project}, open an evolution for this change: {change}.
Tell me which features it touches and what it will ask me to sign.

Compute the impact of the evolution {name} in the Lyriks project {project},
and give me the three readings rather than one number.

Here the specification is the authority and the model executes. That is what makes models interchangeable, and what often lets a more modest one do the job: most of an LLM's mistakes come from having to guess the intent.

1. Freeze the specification into a version, then ask your agent to implement the evolution.
   Prompt Build the evolution Copy

   Implement the evolution {name} of the project {project} in Lyriks, strictly
   respecting the values signed on it. If a decision is not settled there, stop
   and ask me rather than choosing.

2. It stops and asks whenever the evolution left a decision open, instead of improvising one.
3. Verify: the code against the frozen specification, one line per expectation, each one yours to decide. A line you refuse comes with a brief you copy straight back to the agent.
4. What ships is what you signed, and the gap between the two is a list you read, not a surprise in production.