Lesson 1 of 6 · 5 min read
What Livra does
Understand how Livra takes a feature from Jira tickets to reviewed merge requests and documentation, and who decides what.
What you’ll learn
- What a feature is in Livra.
- The five phases every feature goes through.
- Which decisions always stay with you.
- What each role in an organisation can do.
From tickets to merge requests
Livra takes a piece of work from its Jira tickets to merge requests and documentation. Claude does the searching, planning, coding and writing. You stay in charge of every decision that matters: what gets built, where, and what reaches GitLab.
A feature is a named piece of work made of one or more Jira tickets, usually from one epic. Each feature belongs to the person who created it.
Take a realistic example. Your team must let customers invite their teammates. The work is described in three Jira tickets, APP-101, APP-102 and APP-103, under one epic. You create a feature called team-invites with those three tickets. From then on, everything about that work — the setup, the plan, the code, the merge requests and the documentation — lives on the team-invites page.
The five phases
Every feature goes through the same five phases. The feature's page shows them under Progress:
- Set up — you pick the tickets; Claude finds the repositories each one touches and fills in the technical setup. This is read-only.
- Check — the app checks the setup and the branches on GitLab by itself. You can ask Claude for the checks that need judgement.
- Plan — Claude writes what will change, per repository and ticket. You read it and approve it. Nothing is branched before that.
- Build — Claude implements the tickets stage by stage and opens one merge request per repository. You confirm each stage and approve each push.
- Document — the run documentation and the API collections are written for you.
The main button on the feature's page always takes you to the next useful step, so you never have to remember where you are.
What stays with you
Livra is built so that nothing happens behind your back:
- Every
git pushand every merge request Claude creates waits for your Allow. - Claude can never force-push, publish packages, or merge or approve merge requests. Merging is always done by a person, in the app or in GitLab.
- When you connect your own GitLab and Jira accounts, Claude works as you: commits and comments are yours.
Tip: if a phase seems stuck, look at the feature's page. It always says what it is waiting for, often a question or an approval only you can give.
Roles in an organisation
Everyone belongs to one organisation:
- Members work on their own features.
- Admins also manage the organisation's settings (Claude, connectors, environments, plugin rules) and invite members.
- The Org Owner can also make admins, hand over ownership, manage billing and set the merge request rules.
- The Livra team runs the service itself: hosting, security, updates and backups.
Pages only show what your role allows, and the server checks it again on every action.
Check yourself
1. Who merges a merge request that Claude opened?
A person — in the app with their own GitLab account, or in GitLab. Claude can never merge or approve.
2. In which phase do you approve what will change, before anything is branched?
Plan. Claude writes the plan; nothing is branched until you approve it.
3. Can another member of your organisation work on your team-invites feature?
No. Each feature belongs to the person who created it. Admins can look at it, but only its owner runs its steps.