Your team's product decisions, living in text — context for AI.

Teams decide what to build on a whiteboard, often an online one such as Miro or FigJam. livt keeps those decisions in the repository as a log of the opportunities the team is working on, not a specification of everything the product already does. Each board keeps its own format, so that every role on the team owns it. Coding agents read it as context and follow it as one thread, from the opportunity to the tests.

Open the live demo Get started

discoveries/example-mappings/collect-automations.yaml

Collect what the implementation repository's tests automate into a report

✓ automated A test shows what it automates with a livt URI behind a marker ✓ livt: scan_test.go:112 #R-01

✓ automated A comment line puts livt:automates next to one livt URI ✓ livt: scan_test.go:44 #EX-01

✓ automated A bare livt URI without the marker is only a reference, and does not count as automation ✓ livt: scan_test.go:83 #EX-03

The scan picks up rules and examples independently, and infers no structure #R-02

✓ automated Citing a rule's URI makes the rule automated; citing an example's URI makes that example automated ✓ livt: scan_test.go:127 #EX-01

Even if every example is cited, the rule itself does not become automated #EX-02

Questions

In a flat test with no enclosing block, where does the rule's livt URI go? (…) #Q-01

internal/automation/scan_test.go:112 // livt:automates livt://mapping/collect-automations/rule/R-01

An excerpt of livt's own example mapping, translated from Japanese. The test below marks R-01 as the rule it automates. livt collects such marks into a report, and each sticky's ✓ comes from it.

See the whole board

What livt builds on

The ideas behind livt come from BDD, as Gáspár Nagy and Seb Rose set it out in The BDD Books, and from Jeff Patton's User Story Mapping. livt and BDD covers how livt relates to BDD.

Opportunity Canvaswhy to buildJeff Patton, Opportunity Canvas
User Story Mappingwhat to buildJeff Patton, User Story Mapping
Example Mappinghow it should behaveMatt Wynne, Introducing Example Mapping (2015)
Ubiquitous Languagewhich words to useEric Evans, Domain-Driven Design

Why livt

Problems

Decisions made in discovery keep changing during development, yet stay on the board and go stale.
Opportunities, stories and rules sit on separate boards, with no way to follow one to the next.
What was decided goes unread from the implementation side, and how much of it is implemented and automated is hard to tell.

Customers & Users

Every role on a team that runs discovery through development together: product managers, designers, developers, testers
Engineers who leave implementation to coding agents

Solutions Today

Keep the board as it was, share its URL, and look back at it later
Copy the decisions into tickets or documents, and stop syncing from there
Have people mark in tickets or flags whether something is implemented or automated

Solution Idea

Record each practice's board in the repository in its own format, and layer changes on it as diffs
Link opportunities to their story maps and Example Mappings with URIs
Leave automation to coding agents, gather the rules their tests cite, and show where each opportunity stands

What Will Users Do To Get Value?

Have a coding agent record what the board decided, and follow changes in the same place
Follow an opportunity down to its Example Mappings on one site
See where each opportunity stands, and pick the next place to work on

Get started

Install livt and add its plugins to your coding agent. The README has the steps.

Read Getting started Releases