agent-package-manager について
Agent Package Manager(APM)でエージェントパッケージやMCP連携を管理するリポジトリ向けのスキルです。マニフェスト変更、依存関係の導入・更新、コンパイル、ランタイム設定、配布を検証手順とともに案内します。
主な機能
- 01リポジトリとAPM設定の確認
- 02APMマニフェストの作成・修復
- 03依存関係の導入・更新・検証
- 04指示ファイルの検証またはコンパイル
- 05スクリプト、ランタイム、バンドルの管理
活用シーン
- 01リポジトリへのAPM導入
- 02ロックファイルを確認しながらのパッケージ更新
- 03MCP依存関係の検索と設定
- 04CIや配布向けバンドルの準備
MCP 対応
APMの依存関係設定やMCP検索コマンドを使い、リポジトリ内のMCPサーバーを管理する手順を案内します。MCPサーバー自体ではありません。
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/ / github.com/ webmaxru/ web-ai-agent-skills --skill agent-package-managerインストール後、Claude Code で/agent-package-managerを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
assets/apm.yml.templatereferences/command-workflows.mdmanifest-and-lockfile.mdtroubleshooting.md詳細
Agent Package Manager
手順
ステップ 1:リポジトリと、求められている APM の成果を評価する
- リポジトリのルートで、
apm.yml、apm.lock.yaml、.github/、.claude/、.cursor/、.opencode/、apm_modules/を確認します。 apm --versionとapm configを実行し、インストール済みの CLI と現在の設定を確認します。apm.ymlが存在する場合、依存関係、スクリプト、コンパイル設定を変更する前にreferences/manifest-and-lockfile.mdを読みます。- パッケージのインストール、更新、整理、削除に関する依頼の場合、APM コマンドを実行する前に
references/command-workflows.mdを読みます。 apm.ymlが存在せず、ユーザーがリポジトリで APM を使いたい場合は、apm initまたはapm init --yesでプロジェクトを初期化します。- リポジトリがすでに別のエージェント設定フローを使用しており、ユーザーから移行を求められていない場合は、既存の設定を置き換えず、依頼された APM の範囲に変更を限定します。
ステップ 2:マニフェストを慎重に整備または修復する
- リポジトリに新規または修復済みのマニフェスト構造が必要な場合は、
assets/apm.yml.templateを読みます。 nameとversionをトップレベルに必ず記述します。これらは必須の契約フィールドとして扱います。- APM パッケージの依存関係は
dependencies.apmに、MCP サーバーはdependencies.mcpに追加します。 - インストール後は、
apm.ymlで正規の依存関係形式を優先します。GitHub でホストされているスキルやパッケージには、たとえばwebmaxru/agent-skills/skills/webmcpのように、リポジトリで使われている省略形式owner/repo/pathをデフォルトで使用し、明示的なpath、ref、aliasは必要な場合にのみ保持します。 - 再現性を自動的な変更の追従より重視する場合は、チームで共有するパッケージに固定 ref を使用します。
- ローカルパス依存関係は、ローカルで開発を続けている間だけ使用します。バンドル配布を推奨する前に、リモート参照に置き換えます。
- 依頼にスクリプトが含まれる場合は、
scriptsの下に定義し、各スクリプトをapm list、apm preview、またはapm runでプレビューまたは実行できることを確認します。
ステップ 3:推測ではなく検証に基づいて依存関係を管理する
- リポジトリにすでにインストール済みのパッケージがある場合、リスクのある変更は
apm install --dry-run、apm uninstall --dry-run、またはapm prune --dry-runで事前に確認します。 - 依頼の範囲に応じて、
apm install、apm install <package>、apm install --update、またはapm deps updateでパッケージをインストールまたは更新します。 apm install --updateまたはapm deps updateの実行後、ロックファイルのresolved_commitが実際に変更されたことを確認します。古いキャッシュからパッケージが提供された場合は、references/troubleshooting.mdの「Stale packages after update」ワークフローに従います。- リポジトリから単一のスキルをインストールする依頼の場合は、あいまいなリポジトリのみのプレースホルダーではなく、たとえば
apm install webmaxru/agent-skills/skills/webmcpのように、そのスキルのディレクトリまで指定したパッケージパスを提示します。 - 依存関係の変更後は、
apm deps list、apm deps tree、またはapm deps info <package>で解決済みの状態を確認します。 apm.lock.yamlは、解決済みのコミットとデプロイ済みファイルの信頼できる情報源として扱います。チームや CI での再現性を確保するため、コミットを推奨します。- リポジトリで MCP の検出または選択が必要な場合は、MCP のエントリーを手動で編集する前に、
apm mcp list、apm mcp search <query>、apm mcp show <server>を使用します。 - インストール時の出力に競合やスキップされたファイルが示された場合は、強制オプションで再試行する前に
references/troubleshooting.mdを読みます。 - リポジトリが自身のパッケージを使用する(自己参照依存関係)場合、APM が取得するには変更をコミットしてプッシュする必要があることをユーザーに伝えます。
references/troubleshooting.mdの「Self-referencing dependencies」セクションを読みます。 ステップ 4:価値がある場合にのみコンパイルと検証を行う - コンパイル戦略やターゲットの選択を変更する前に、
references/command-workflows.mdを読んでください。 - 目的が出力の生成ではなく正確性の確認である場合は、プリミティブを検証するために
apm compile --validateを使用してください。 - 大規模なコンパイル変更を行う前、または配置の判断を確認する際は、
apm compile --dry-runを使用してください。 - 対応ツールでは
apm installによってプロンプト、エージェント、スキル、フック、MCP 統合がすでにデプロイされることを説明してください。apm compileは主にAGENTS.mdやCLAUDE.mdなどの指示ファイルを生成するためのものです。 - リポジトリが複数のランタイムやツール群に対応する場合は、明示的なターゲットを使用してください。
- コンパイルで生成済みの出力を再スキャンしないよう、
compilation.excludeをビルドディレクトリや依存関係ディレクトリに合わせてください。 - 作成中に継続的な再生成が必要な場合は、単発の検証手順が問題なく完了した後にのみ
apm compile --watchを使用してください。
ステップ 5:スクリプト、ランタイム、配布のフローを適切に運用する
- スクリプトを実行する前に、
apm listでプロジェクトのスクリプトを一覧表示してください。 - 自動化やデバッグのワークフローで
apm run <script> -p key=valueを使用する前に、apm preview <script> -p key=valueでプロンプト駆動型スクリプトをプレビューしてください。 - リポジトリが APM 管理のランタイムに依存する場合は、
apm runtime status、apm runtime list、apm runtime setup <runtime>を使用してください。 - CI の並列実行、エアギャップ環境への配布、リリースの追跡可能性が目的の場合は、
references/command-workflows.mdを読み、インストールが正常に完了してapm.lock.yamlとデプロイ済みファイルが生成された後にのみapm packを使用してください。 - 以前にパックしたバンドルを追加で展開する場合にのみ
apm unpackを使用してください。依存関係の作成に代わるものとして提示しないでください。 - インストールを繰り返すことで、回避可能な CI コストやネットワークリスクが生じる場合は、
apm-actionまたはビルド済みバンドルを推奨してください。
エラー処理
apmが見つからない場合は、まずインストールまたは更新し、プロジェクトファイルを編集する前にapm --versionで確認してください。apm installで認証エラーが報告された場合は、references/troubleshooting.mdを読み、再試行する前にホスト認証を修正してください。apm installでファイルの競合が報告された場合は、診断の概要を確認し、必要に応じて--verboseを付けて再試行してください。--forceを使用するのは、ローカルファイルを上書きすることが明確に意図されている場合に限ってください。- ユーザーのツールチェーンで
apm compileが不要な場合は、無駄な作業として追加せず、より簡潔なインストールのみの手順を優先してください。 apm.lock.yamlがない、またはデプロイ済みファイルがないためにapm packが失敗した場合は、再試行する前にapm installを再実行してください。- リポジトリがローカルパスのパッケージに依存する場合は、それらの依存関係をリモート参照に置き換えるまで
apm packを推奨しないでください。
コメント
Markdown 対応