DeliverKit

DeliverKit

AI 交付大脑：给 Agent 用的全生态交付编排工具。

DeliverKit 不是一个"把 Linux 软件塞进 Windows 跑"的兼容层，而是一个给 AI（Agent）使用的交付大脑：它把各生态（Linux / Windows / 苹果 / 鸿蒙）的打包、签名、上架知识变成 AI 能读懂、能执行、能验证的能力，让 AI 理解用户需求后，规划出一条合法合规的交付链路，把已经开发好的产品送达每一个生态。

采用信号（公开可验证，实时）

徽章实时取自 npm 注册表；下列条目均带可点验链接。项目无默认遥测，所有采用数据都来自公开渠道（npm / GitHub / 目录收录），每周快照存档于 metrics/。

• npm 周下载：见顶部徽章（npx -y deliverkit-mcp 即可验证安装真实可用）
• 官方 MCP Registry 已收录：io.github.muzimu217/DeliverKit（status: active，2026-09-11 起）
• 中国独立开发者列表（程序员版）已收录（合并记录，2026-09-14 起）
• 每次 CI 都在真实交付：Actions 在 Ubuntu 22.04 与 24.04 两个 runner 上用真实 Docker 构建 deb/rpm/AppImage 并在干净容器安装运行验证，产出 verified 状态的 ReleaseManifest 证据（artifact 可下载）
• awesome-mcp-servers 与 mcp.so 收录审核中

发布于 2026-09-11。上面的徽章与链接就是当前采用状态的全部事实——我们只展示可验证的数据，不刷不夸。

30 秒上手

npx -y --package=deliverkit-mcp -- deliverkit doctor            # 先看本机现在能交付哪些目标，缺什么、怎么补
npx -y --package=deliverkit-mcp -- deliverkit inspect .         # 识别项目语言与入口
npx -y --package=deliverkit-mcp -- deliverkit plan . --goals deb,rpm   # 生成可评审的 Forge.md 交付契约
npx -y --package=deliverkit-mcp -- deliverkit pack-deb . --plan Forge.md   # 构建 + 干净容器安装运行验证（需 Docker）

doctor 会把「这台机器现在能产出哪些包」摊开讲清楚——不能产出的目标不是缺陷，而是各生态用签名和官方工具链锁定了产出位置，DeliverKit 的做法是把它们规划到正确的 runner 上，而不是在本机伪造产物。

失败时不会只丢一个日志路径给你：错误结果里带 log_excerpt（日志尾部片段）、suggested_fix 和 next_actions，Agent 和人都能直接看到原因与下一步。

它解决什么问题

"一次开发、各生态安装包自动产出"之所以难，不是因为没人想做，而是各生态官方用代码签名 + 官方工具链 + 官方账号把这条路锁死了：

生态	产出安装包的硬约束
苹果（macOS/iOS）	签名与公证只能在 macOS + Xcode + Apple 开发者账号上完成
Windows	代码签名需要 Windows 代码签名证书
鸿蒙	需要 华为 DevEco 工具链 + AGC 签名
Linux（deb/rpm/AppImage）	唯一能在一台机器上多目标产出，无强制签名门槛

所以 DeliverKit 不假装一台机器产出全生态——它懂得"每个安装包该在哪、用什么合法方式产出、怎么验证它真的能装能跑"，并指挥 AI 在正确的环境（本地 / CI 对应平台 runner / 云构建）里完成。这就绕开了各生态的硬约束，而不是去翻墙。

現在の機能（v0.3.1 · インストール可能な MCP + Agent Skill + Linux 3 目標の一貫した検証）

DeliverKit は MCP（stdio）を通じて、計画、オーケストレーション、ビルド用ツールを公開します。

• inspect_project —— プロジェクトの言語、エントリーポイント、既存のパッケージ設定を特定し、複数のエコシステムにまたがるリリース目標を提案します。特定に失敗した場合や誤って特定された場合は、language（python/javascript/typescript/go/arkts）とentrypointsを渡して手動で指定できます。結果はそのまま Forge.md 契約に反映され、行き詰まることはありません。
• generate_packaging_plan —— レビュー可能なForge.mdリリース契約（対象エコシステム／成果物／判断根拠／リスク）を生成します。
• get_ecosystem_knowledge —— 登録済みエコシステムの構造化されたパッケージ、署名、配布、検証ルールを読み込みます。
• pack_deb —— Forge.mdに基づき、分離された Ubuntu コンテナ内で.debをビルドし、新しいコンテナでインストールと実行を検証します。systemdパラメーターに対応しており、systemd サービスユニットとメンテナンススクリプトを同時にインストールします（実際のホストでは postinst により自動でenable --nowが実行されます）。検証段階ではsystemd-analyzeによる構文チェックも行います。
• pack_rpm —— Forge.mdに基づき、分離された Rocky Linux コンテナ内で.rpmをビルドし、新しいコンテナでインストールと実行を検証します。systemdパラメーターに対応しており、unit は%files（/usr/lib/systemd/system）に含まれ、実際のホストでは%postにより自動でenable --nowが実行されます。検証段階ではsystemd-analyzeによる構文チェックも行います。
• pack_appimage —— Forge.mdに基づき、分離された Ubuntu x86_64 コンテナ内で AppImage をビルドし、extract-and-run/AppRun による検証を実行します。
• generate_ci_workflow —— Forge.mdに基づき、GitHub Actions のマルチプラットフォームワークフローを生成します。Windows/Apple の証明書は secrets 経由でのみ注入され、HarmonyOS job には Linux self-hosted DevEco runner が必要です。
• pack_windows_msi —— Windows runner で WiX を使用して MSI をビルドし、Authenticode 署名とサイレントインストール／アンインストールの検証を実行します。
• pack_macos —— macOS runner で codesign/hdiutil を使用して DMG をビルドするか、productbuild/productsign を使用して PKG をビルドし、notarytool による公証、spctl、stapler による検証を実行します。
• pack_harmonyos —— Linux/Windows DevEco runner で hvigorw を使用して HAP/APP をビルドし、hdc でインストールを検証します。
• generate_release_manifest —— 各プラットフォームの JSON 結果、SHA256、検証証跡を集約し、共通のReleaseManifest.jsonを生成します。

3 つの Linux ビルドツールはいずれも、利用可能な Docker デーモンが必要です。npm run test:e2e:linuxでは、Python Flask、TypeScript、Go 標準ライブラリ HTTP の 3 つの実際の fixture を使用して、同一の複数目標Forge.mdを再現し、deb/rpm/AppImage のビルド、インストール、実行を検証して、verified状態の Release Manifest を生成済みです。リポジトリの CI でも Ubuntu 22.04 と 24.04 の runner で同じ matrix を再実行し、JSON の証跡をアップロードします。その他の Linux ホストでの再検証も引き続き推奨します。

すべてのプラットフォームビルドツールは、次の 2 つの鉄則を守ります。

1. 計画が先（Plan-before-build）：Forge.md契約がなければビルドしません。
2. 実際の検証（Real verification）：終了コードを見るだけでなく、成果物をインストールでき、実行でき、署名が有効であることを検証します。

失敗時に次の行動へつなげられることも、契約の一部として扱います。Docker が利用できない場合は、「未インストール／デーモン未起動／権限不足／検出タイムアウト」を区別し、それぞれの修正方法を提示します。ビルドがタイムアウトした場合に、通常のビルド失敗として装うことはありません。失敗のたびにログ末尾の抜粋と次に実行するコマンドを提示します。Forge.mdのsource_dir比較では、シンボリックリンクの違い（macOS の/tmpと/private/tmpなど）を許容します。実際に一致しない場合は、両方のパスの値をエラーメッセージに表示します。

CLI 側でも手動指定に対応しています（--entryは複数回指定できます）。

npx -y --package=deliverkit-mcp -- deliverkit plan . --goals deb --language python --entry server.rb

接続

サイト（MCP の導入窓口）

リポジトリには、そのままデプロイできる静的サイトが含まれています：site/index.html。最初に表示される画面には、MCP のインストールコマンドと「10 分で Linux を動かす」初回タスクが表示されます。エコシステムのナレッジとプラットフォームの事前準備ガイドは二次的な入口として用意されており、Agent Skill についてはskills/deliverkit-mcp/SKILL.mdをご覧ください。

npx serve site

このサイトはユーザーデータを一切収集せず（フォーム、統計スクリプト、cookie はありません）、アカウント、証明書、秘密鍵も含みません。デプロイとコンテンツの範囲についてはsite/README.mdをご覧ください。

MCP（stdio）：

{
  "mcpServers": {
    "deliverkit": {
      "command": "npx",
      "args": ["-y", "deliverkit-mcp"]
    }
  }
}

CLI：

deliverkit doctor                      # 自检本机可交付目标，缺什么、怎么补
deliverkit inspect .                   # 识别项目与交付目标建议
deliverkit plan . --goals deb,rpm      # 生成 Forge.md 交付契约
deliverkit pack-deb . --plan Forge.md  # 构建并验证 deb（需要 Docker）
deliverkit pack-rpm . --plan Forge.md  # 构建并验证 rpm（需要 Docker）
deliverkit pack-appimage . --plan Forge.md  # 构建并验证 AppImage（需要 Docker）
deliverkit generate-ci-workflow . --plan Forge.md  # 生成多平台 GitHub Actions 工作流
deliverkit pack-windows-msi . --plan Forge.md  # 仅 Windows runner 可执行，要求签名 secrets
deliverkit pack-macos . --plan Forge.md  # 仅 macOS runner 可执行，按 Forge.md 构建 DMG/PKG
deliverkit pack-harmonyos . --plan Forge.md  # 仅 DevEco runner 可执行，要求 AGC secrets/设备
deliverkit generate-release-manifest . --plan Forge.md --results .deliverkit/results

CLI はデフォルトで、人が読みやすい概要（成果物、検証項目、失敗理由、次の手順）を出力します。任意のコマンドに--jsonを追加すると、MCP と同じ構造化された結果が得られ、スクリプトやエージェントで利用できます。

参加する

• issue を作成：バグ報告／エコシステム対応のリクエスト
• PR を作成する前にCONTRIBUTING.mdをお読みください（「エコシステムナレッジパックの追加」と「pack_* ツールの追加」のチェックリストを含みます）
• セキュリティ上の問題はSECURITY.mdに従って非公開で報告してください。公開 issue は作成しないでください
• ディスカッションと質問：GitHub Discussions（Q&A には 24 時間以内に返信します）
• DeliverKit で、インストールできて実行できるパッケージを作成できましたか？リリース成功のフィードバックを送信してください。実際のリリース成功は、このプロジェクトの北極星となる指標であり、star よりも重要です。明確な同意がない限り、事例は内部集計のみに使用し、外部には公開しません。

ロードマップ

docs/ROADMAP.mdをご覧ください。概要：

• A — 契約レイヤー + エコシステムナレッジパックのスキーマ（完了）
• B — Linux 複数ディストリビューションでの検証可能なリリース（ローカルの 3 プロジェクト matrix による基準は再現済み。CI／ホスト間での再検証は引き続き推奨）
• C — オーケストレーションレイヤー + CI matrix、Windows MSI（実装中。実際の署名要件は CI で検証予定）
• D — Apple エコシステム（実装中。署名／公証要件は macOS CI で検証予定）
• E — HarmonyOS の正式対応 + 統一リリースレポート（実装中。AGC／デバイス要件は検証待ち）

起源

DeliverKit の MCP プロトコルレイヤーと「計画が先／実際の検証」という 2 つの鉄則は、Docker ビルドの診断に特化したプロジェクトであるForgeKitを受け継いでいます。両者は目的が異なり、それぞれ独立して発展しています。ForgeKit は診断に特化し、DeliverKit は複数のエコシステムにまたがるリリースを広く扱います。

ライセンス

MIT