Skip to content

distribution form github direct

Jump to bottom
Claude Lin & Lay edited this page Aug 8, 2026 · 1 revision

Li+ の配布形式は GitHub リポジトリ直配布

Question

Li+ をどの形式で利用者に配るか。Claude Code のプラグイン機構は代替になるか。

Current resolution

配布形式は GitHub public リポジトリの直配布。利用者側の Li+config.md に置かれた LI_PLUS_REPO を AI が読み、Li+update.md を実行して .claude/ 配下に展開する。

Claude Code のプラグイン方式は代替にならない（後述の仕様上の欠落による）。この形式は意図的な選択であり、消去法の結果ではない。

Edges

  • depends on: li-plus-always-on-footprint-load-bearing — rules/ が always-on であることが load-bearing だという判断が前提。この前提が崩れれば rules/ を skill 化できるので、プラグイン方式が選択肢に戻る。

Background

Claude Code v2.1.224（2026-08-07）で plugin の archive source（HTTPS 越しの zip 配布、sha256 ピンは任意）が追加された。これを起点に、配布経路一般の信頼境界を検討した際、Li+ 自身の配布形式にも同じ物差しを当てることになった。

Li+ は plugin ではないが、plugin と同等の権限を持つ：

  • .claude/hooks/ に 3 本のシェルスクリプト（on-session-start.sh / on-user-prompt.sh / post-tool-use.sh）。セッションごとに実行される。
  • rules/ と skills/ は AI の振る舞いを直接書き換える。markdown 一行の追加で挙動が変わるため、バイナリ差し替えを要しない。

かつ plugin system の外側にいるため、ホスト側の防御が一つもかからない：marketplace の追加制限（strictKnownMarketplaces）、インストール前の「Will install」インベントリ表示、workspace trust ダイアログ。入口は Li+config.md の「LI_PLUS_REPO/Li+update.md を読んで実行しろ」の一行のみ。

human はこの性質を認識した上で配布を継続している（2026-08-08 対話：「配布形態としては危険な部類なんだよね。悪用されると結構リスキー」）。

Constraints

プラグイン方式で配れないものがある（2026-08-08 時点の Claude Code 仕様を調査）。

配布可能なコンポーネント：skills / commands / agents / workflows / hooks / mcpServers / outputStyles / lspServers / experimental.themes / experimental.monitors。Li+ の相当部分（skills/*/SKILL.md、character_Instance.md、agents/、hooks 3 本）はこれで配れる。

配布不可能なもの：rules/*.md と CLAUDE.md 本体。公式仕様の明文は「plugin root の CLAUDE.md はプロジェクトコンテキストとして読み込まれない。コンテキストに常時ロードさせたい指示は skill に入れろ」。

この回避策は Li+ では飲めない。rules/ を skill に落とすと auto-invocation 依存になり、always-on 性が失われる。L1 Model Layer が「呼ばれたら効くルール」に降格することは、li-plus-always-on-footprint-load-bearing が load-bearing と判定した性質そのものの放棄にあたる。

したがって現状の Li+ にとって、プラグイン化は部分的にしか到達できず、到達できない部分が中核である。

Conclusion

採用：GitHub public リポジトリ直配布。

human が挙げた積極的理由は 2 つ（2026-08-08 対話：「だって楽だし、中身確認できるからさ」）。

  1. 運用の軽さ — 配信・履歴・版管理・権限管理が GitHub 側の既存機能で賄われる。自前運用なら全てが運用負債になる。維持コストの低い安全策だけが実際に維持される。
  2. 中身の検証可能性 — 読む行為と取り込む行為が分離している。plugin.json 相当を落とさずに 1 ファイルずつ読める。

副次的に、配布経路として以下が同時に成立する：

  • public リポジトリ = 第三者による観測が働く
  • commit 履歴 = 差し替えに足跡が残る
  • release tag = 版の固定（例：build-2026-08-08.4）
  • GitHub が配信 = 標的型配信（要求元によって別バイトを返す）が不可能

補助対策：issue と PR の書き込みを組織メンバー限定にしている。 Li+ の脅威は「AI が読んで実行する markdown に一行足されること」であり、その最安の入口が外部からの PR である。ここを閉じることが脅威モデル上もっとも費用対効果が高い。

受容した残余リスク：

  • 配布側では解けないもの：human 側アカウントの侵害、利用者が中身を検証せずに導入すること。
  • ホスト側の plugin 防御は一切適用されない。

却下：プラグイン方式（marketplace 経由）。 中核である rules/ を配れないため、部分導入にしかならず、手動インストールとの二重構成になる。

再評価条件

Claude Code 側に .claude/rules/*.md 相当を always-on で配布する手段が追加された場合。その時点でプラグイン方式が完全な代替になりうるため、ホスト側防御（marketplace 制限 / インストール前インベントリ / trust ダイアログ）を得る側に倒す判断が成立する。

Related

Li+ Wiki

この Wiki は、Li+ に基づく開発・運用を支えるための情報整理空間です。

ページ構成について

要求仕様書（数字：1–9）

数字で始まるページは、 Li+プログラムの各レイヤーの仕様を定義するページです。

  • 要求（何を満たすか）と仕様（どう振る舞うか）を一体として記述する
  • 実装前に作成または更新する
  • issue群から採用された要件を集約する

これらのページは 安定性と一貫性を重視して管理されます。

参考文書（アルファベット：A–）

アルファベットで始まるページは、 Li+の構想・設定・導入手順などの参照用ページです。

  • 設計思想・背景
  • 設定リファレンス・インストール手順

これらのページは 必要に応じて更新・拡張されます。

rules/, skills/, adapter / update 各ファイル

リポジトリ内の rules/**/*.md（L1–L4 の常時ロード分、subdir 含む）、skills/**/SKILL.md（トリガー起動分）、adapter/claude/CLAUDE.md、adapter/claude/hooks-settings.md、adapter/claude/hooks/*.sh、adapter/codex/AGENTS.md、およびルート直下の Li+config.md、Li+update.md は、 AIやランタイムが直接読む実行用プログラム / 定義ファイルです。

  • docs/ は人間向けの仕様書・要求仕様・手順書
  • rules/, skills/ および adapter / update は実行時に読み込まれる本体

両者は対応しているが、役割は同じではない。

Home | 1. Model | 2. Evolution | 3. Task | 4. Operations | A. Concept

要求仕様書 (1-6)

参考文書 (A-L)

判断構造

Clone this wiki locally