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