main agent procedures moment scoped procedures move to skills - Liplus-Project/liplus-language GitHub Wiki

rules/operations/main-agent-procedures.md の場面に限られる手順は、常時ロード面の名指しが届く skill へ移す

Question

常時ロードされる rules/operations/main-agent-procedures.md から、特定の場面でしか使わない手順をどこまで外せるか。外した手順は、その場面で確実に読まれるか。

Current resolution

移すのは、場面が限られていて、その場面ごとに常時ロード面の文が移し先の skill の節を名指している手順だけである。発火条件と、書いている最中に効いている必要がある規律は常時ロード面に残す。

PR #2139（issue #2138）で 30,446 B → 27,054 B（-3,392 B）。新設 skill の description（317 B）と task-pr-review-judgment の description の伸び（109 B）を差し引いた常駐面の正味は約 -2,966 B。1 段目（理由の文を外した判断）は main-agent-procedures-carry-behavior-only にある。

移したもの

  • ## Sub-issue rules の手順本体 → 新設の skills/task-sub-issue/SKILL.md（L3）。分類リトマス、sub-issue の API、並行競合分析、scope-exceed confirm の閾値・同期集合の carve-out・confirm の形・literal に当たらない発火の禁止・PR レビュー時の発火の却下、per-sub-issue PR の事後復旧。常駐面の ## Sub-issue rules は、skill を開く 4 つの場面（sub-issue の作成・分類・リンク、複数の ready issue の実行、confirm の発火、per-sub-issue PR が既にある）を 1 文で名指す。
  • ## Review approval check → 既存の skills/task-pr-review-judgment/SKILL.md の同名節。場面はセルフレビュー pass 後に人間ゲートが立つときだけで、常駐の ## PR review が semi_auto の minor / major と trigger の 2 か所で skill の節を名指す。セルフレビュー自体がこの skill を開いており、確認手順が読んだ決定を判断するのも同じ skill である。

移し先はどちらも task-* で、メインが読める（operations-* だけがメインの読めない面、rules/operations/main-agent-procedures.md The bar and its pair）。

常時ロードに残したもの

  • 同時タスクの親子構造。 発火条件は「同じセッションで複数のタスクを扱う」ことそのもので、そこを名指せる面が他に無い。
  • scope-exceed confirm の発火条件（issue 本文の literal がスコープ境界、2 種類の literal、commit 前に発火）。サブエージェントが自分の commit 前に検出する。skill の起動に頼ると検出が想起に依存する。docs/L.-Hop-Count-Instrument.md S4 のアンカー文でもあり、文面のまま残した。
  • ## Human confirmation required。 停止語、force push、branch 削除はどの瞬間にも来る。リリースの行は不可逆な操作の確認点そのもの（li-plus-always-on-footprint-load-bearing 却下理由 3(b)）。
  • ## Release completion report discipline。 go-sign の催促に流れる既定の傾きに逆らう規律で、書いている最中に効いている必要がある。手順を探しに行く型ではないので、skill へ移すと想起に依存する。メインが読める L4 の skill の置き場も無い。
  • ## Notifications API と ## Discussions intake。 前者は場面を名指す常時ロードの文が無く、移すと description の想起だけが経路になる。後者は issue に着手するたびに来る場面で、どちらも数百 B なので新しい description の費用が利得の大半を食う。
  • ## Foreground webhook notification intake。 毎ターンの冒頭に使う。

Edges

  • depends on li-plus-always-on-footprint-load-bearing — 常時ロード面を skill へ移す案を想起の欠落で却下した判断。本件は発火を常時ロード面の名指しが担う形に限って移し、却下理由に当たる規律（毎瞬間に効く発火条件、既定の傾きに逆らう報告の規律）は移していない
  • depends on memory-entry-format-rule-carries-behavior-only — 同じ形の前例（observation 手順を evolution-* skill へ移し、各場面の名指しを skill へ向けた）
  • relates to main-agent-procedures-carry-behavior-only — 同じファイルの 1 段目（#2117）
  • relates to always-on-duplication-removal-direction — 跳躍数の合格条件。S4 は confirm の詳細までツール跳躍が 1 増え、理由は docs/L.-Hop-Count-Instrument.md S4 の追記にある

Background

issue #2138。main-agent-procedures.md は常時ロードの rules の中で最大（30,446 B、次は cold-start-synthesis.md の 10,822 B）だった。issue は候補の節を仮説として挙げ、節ごとに「移したあと、その場面で手順が確実に読まれるか」で判定することを求めた。

Constraints

  • メインが各場面で実行する手順は変えない。## Issue format は節名で他ファイルから参照されるので残す。アダプタの凍結ブロック、L1、cold-start-synthesis.md、promotion-judgment.md は触らない（issue #2138 制約）。
  • 移し先はメインの読める面に限る。

Conclusion

採用 = Sub-issue rules の手順本体を task-sub-issue へ、Review approval check を task-pr-review-judgment へ移し、常駐面には発火条件と skill の名指しを残す。

却下 = Sub-issue rules を節ごと移す案。同時タスクの親子構造と scope-exceed の発火条件は、名指す面が他に無いか、サブエージェントの commit 前の検出に要るため、移すと発火が想起に依存する。

却下 = Release completion report discipline を新しい skill へ移す案。書いている最中に効くべき規律で、置き場も task-* の語彙に合わない。

却下 = Notifications API / Discussions intake を移す案。届く経路が description の想起だけになるか、利得が description の費用を下回る。

Related