Your team's product decisions, living in text — context for AI.
livt は、オンラインホワイトボード（Miro や FigJam など）でチームが決めたことを、ボードの形のままリポジトリに残すツールです。残るのはいま取り組んでいるオポチュニティの意思決定ログで、プロダクトの既存仕様をすべて書き起こしたものではありません。チームの全職能の持ち物になり、AI エージェントはそれをコンテキストとして読んで、オポチュニティからテストまでを一続きにたどれます。
実装リポジトリのテストから自動化を集めてレポートにする
走査はルールと具体例を独立に拾い、構造を推論しない
#R-02
具体例が全て引用されていても、ルール自身は自動化済みにならない
#EX-02
疑問点
囲むブロックを持たないフラットなテストで、ルールのlivt URIをどこに引用するか（…）
#Q-01
internal/automation/scan_test.go:112
// livt:automates livt://mapping/collect-automations/rule/R-01
livt 自身の実例マッピングからの抜粋です。下のテストは R-01 を自動化の対象として示していて、livt はこうした印をレポートに集めます。付箋の「自動化済み」はそこから出ています。
ボード全体を見る土台にしたプラクティス
livt の考え方は、Gáspár Nagy と Seb Rose が『The BDD Books』で整理した BDD と、Jeff Patton の『ユーザーストーリーマッピング』に根ざしています。BDD との関係は livt と BDD にまとめています。
- オポチュニティキャンバスなぜ作るのかJeff Patton「Opportunity Canvas」
- ユーザーストーリーマッピング何を作るのかJeff Patton『ユーザーストーリーマッピング』
- 実例マッピングどう振る舞うのかMatt Wynne「Introducing Example Mapping」（2015）
- ユビキタス言語どの言葉で話すのかEric Evans『ドメイン駆動設計』
なぜ livt か
課題
- ディスカバリーで決めたことは開発のあいだも変わるが、ボードに置かれたまま古びていく
- オポチュニティ、ストーリー、ルールがボードごとに分かれ、つながりをたどれない
- 決めたことが実装の側から読まれず、どこまで実装・自動化されたかも追いづらい
顧客とユーザー
- ディスカバリーから開発までを一緒に進めるチームの全職能（PdM、デザイナー、開発者、テスター）
- AI エージェントに実装を任せているエンジニア
現在の解決手段
- ボードをそのまま残し、URL を共有してあとから見返す
- 決めたことをチケットやドキュメントに書き写し、そこから先は同期しない
- 実装・自動化したかどうかは、人がチケットやフラグで示す
解決策のアイデア
- 各プラクティスのボードを、その形のままリポジトリに記録し、変更を差分として重ねる
- オポチュニティからユーザーストーリーマップ、実例マッピングまでを URI でつなぐ
- 自動化は AI エージェントに任せ、テストが引用したルールを集めて、オポチュニティごとの現況まで示す
ユーザーは価値を得るために何をするか
- ボードで決めたことを AI エージェントに記録させ、変更も同じ場所で追う
- オポチュニティから実例マッピングまでを、同じサイトでたどる
- オポチュニティごとの現況を見て、次に手を入れる場所を選ぶ
使い始める
livt をインストールして、AI エージェントにプラグインを入れます。手順は README にあります。