← 実例マッピング | livt
ストーリー ルール 提案中のルール テストが自動化している 具体例 疑問点 ユビキタス言語
表示
livt経由で各実装リポジトリに自動化Issueを起票する→

ルール

11
#R-01
ルールメンテナーはlivtリポジトリのルールを指定して、対象実装リポジトリへ自動化Issueを起票できる
具体例2
#EX-01
story-keyとrule-idを指定すると、そのルール1件分のIssueが起票される
#EX-02
story-keyのみ指定すると、そのストーリーの未起票ルール全件が起票される
#R-02
起票したIssueのURLは、スキルがマッピングYAMLのruleに書き戻す
具体例2
#EX-01
起票に成功すると、該当ruleのissuesにそのURLが追記される
#EX-02
書き戻しがそのままlivtリポジトリへの記録（record-rule-automation）になり、手作業を要しない
#R-03
dedupeはlivtリポジトリ側の記録で判定し、同じルール×対象リポジトリを二重起票しない
具体例2
#EX-01
ruleのissuesに対象リポジトリのIssueが既にあればスキップする
#EX-02
別の実装リポジトリへの起票は、既存の紐づけがあっても妨げない
#R-04
Issue本文はルール・具体例の本文とlivtリポジトリへのバックポインタを運ぶ
具体例4
#EX-01
本文にルール名と具体例の一覧を含む
#EX-02
バックポインタとしてstory-key・rule-idと、リビングドキュメントのルールアンカー（#rule-{ID}）へのリンクを含む
#EX-03
起票時点のlivtリポジトリのrevをspec_versionとして記す
#EX-04
バックポインタが指すルールIDは起票後も不変で、記録・ルール変更のAIスキル共通ポリシーとして担保する
#R-05
ストーリーにUS Issueが紐づいていれば、ルールIssueはそのsub-issueとして起票する
具体例2
#EX-01
US Issueがあるストーリーのルールは、起票時にsub-issueとして親へ紐づく
#EX-02
US Issueがなくてもルール単位の起票は成立する
#R-06
起票は実装リポジトリのコードを読まず、Issueというポインタだけを送る
具体例1
#EX-01
起票は対象リポジトリのチェックアウトを必要としない
#R-07
本ストーリーはAIスキルとして提供し、livtのCLIコマンドやMCPツールは追加しない
具体例2
#EX-01
スキルはlivtリポジトリを読み、gh CLI（既存の認証）で対象リポジトリへ起票する
#EX-02
書き戻しはワーキングツリーの編集までとし、コミットやPRは通常のレビューフローに委ねる
#R-08
実例マッピングYAMLの各ruleは、対応する自動化IssueのURLをissuesとして持てる
具体例3
#EX-01
1つのルールが複数の実装リポジトリで自動化される場合、issuesに複数のURLを列挙する
#EX-02
issuesに置くのはIssueのURLに統一し、PR・テストへの直リンクは置かない
#EX-03
issuesのないruleは未紐づけとして扱われる
#R-09
紐づけの正はlivtリポジトリが持ち、GitHub側の構造には依存しない
具体例2
#EX-01
親子関係はstory⊃ruleというlivtリポジトリの構造から把握し、GitHubのsub-issueグラフは読まない
#EX-02
livt経由でないIssueも、URLをruleに貼れば同じ紐づけになる
#R-10
対象実装リポジトリは、ストーリーのfrontmatterのreposで宣言する
具体例3
#EX-01
reposはowner/repo形式のリポジトリのリストで、複数の実装リポジトリを宣言できる
#EX-02
ルールIssueの起票先は、所属ストーリーのreposを参照する
#EX-03
livtリポジトリ自身もreposに宣言でき、自リポジトリへの起票も同じ手順で成立する
#R-11
Issue本文の一次参照はlivt URIで、デプロイ済みURLは補助にとどめる
具体例3
#EX-01
ルール・具体例のlivt URIをIssue本文に載せる
#EX-02
人が踏めるHTTPリンクは併記してよいが、一次はlivt URI
#EX-03
他リポジトリのIssueは後から直せないので、デプロイ先に依存させない
ユビキタス言語
livt URI→ livtリポジトリ→ 実例マッピング→ ストーリー→ ディスカバリー→