複数の独立したローカル作業を安全性と依存関係を確認して実行計画にまとめ、対応環境では並列化やAppleシリコン向け処理の選択を支援します。
- ビルドやテストの独立した処理を並列化したいとき
- 複数段階の作業計画を安全に実行したいとき
- Appleシリコン向け処理の候補を確認したいとき
複数のLLM CLIに計画のレビューや質問、タスク生成、実装、コードレビューを依頼し、各モデルの結果をまとめて進行するスキルです。
Orchestrate plan reviews, task generation, implementation and code reviews across several LLM CLIs in parallel, or ask every model one free-text question about a plan. Use when the user says: review my plan, multi-llm, run a code review, generate tasks from a plan, implement this plan, ask the models about my plan.
実行スコア 未検証
インストール方法を見る複数のLLM CLIに作業を振り分け、計画のレビュー、計画からのタスク生成、実装、コードレビューを進めます。計画について自由記述の質問を送り、複数モデルの回答を集める用途にも使えます。結果の状態や失敗したモデル、レビュー時の検証件数、追加対応が必要な項目をどう確認するかも定められています。実行は専用の multi_llm ツールを通じて行い、次の段階が提示された場合は指定された引数で続行します。
計画を複数のモデルに見てもらいたいときや、実装前に作業を分解したいときに役立ちます。モデルごとの意見を集めたい場合や、コードレビューを依頼したい場合にも利用できます。実行結果に一部失敗や人の判断が必要な項目が含まれるときは、案内されたレポートや次の手順を確認できます。
このホストでは multi_llm ツールが唯一の実行方法です。ツールが利用できない場合は codex mcp get multi_llm で起動コマンドを確認し、Python 3.9以上が PATH に必要です。
この紹介文は、公開されている SKILL.md をもとに AI(OpenAI Codex)が作成しました。正確な仕様は下の原文を確認してください。
インストールする前に、エージェントに与えられる指示の中身を確認できます。
Call the multi_llm tool with the argument text, converted to its four properties exactly
as that tool's own argument descriptions specify. The tool is the only supported entry point
on this host: it appends the flags this host requires, refuses the ones it owns, and
supervises the run to a terminal result. Do not reach the dispatcher any other way. The tool
runs outside the exec sandbox, and on the modes that apply changes it writes to the workspace. A call can run for up to its 15-minute budget. When you call this tool from an exec cell, start the cell with // @exec: {"yield_time_ms": 900000}, so the cell waits for the result. If a cell hands back "Script running" anyway, call wait until this call returns, and never end your turn while it is running.
Read the result's exit and next the way the dispatcher's own contract reads them; on state: partial, name the failed models and their reasons from progress.models; when the result carries validation_counts (a review phase's does), report them, and if needs_human_decision or validation_failed is non-zero point at report.md for those groups; they are decided later, when the suggestions are applied. A result without that key has no counts to report, so do not mention them. When the result carries a notice (result.notice, a finished run's: what it left out or could not check, such as items it did not apply or that nothing ran this repository's tests), report what it says, every part of it, as plain text. Put it above the closing section, and repeat nothing that section says.
On this host next arrives as arguments for this same tool, not as a command: "running" it means calling the tool again with exactly those arguments, never a shell.
Run next verbatim when it is not null on 0 and 2. On 3 stop: report to the user which phase stopped, on which plan or commit range, the last error line it printed, whole (on a stop it says what stopped, what it reported, what did not run and whether anything ran the repository's tests), and the options its output names (next included); do not run a different mode. Do not perform the work this run was going to review, plan, or implement: doing it yourself is never a substitute for a failed run. Run an option only after the user has picked it. Never edit driver.write_paths, or any other multi-llm setting in .multi-llm/providers.yaml, yourself. At a stop, offer only the ways forward the stop itself names, as it words them: when it names a change to driver.write_paths that lets a refused file be written (adding it to allow, or removing or narrowing a deny rule that covers it), that is one of them and the user's call; add no advice about the write policy of your own. user_next_step is the phase after this one, for the user to type: never run it yourself; end your report with its markdown, copied as it is (its words and order, each command alone in its fenced block, each why and note plain text, the manual tasks it lists included, no caption of your own). Only that markdown says "Workflow complete.": never write those words yourself. Copy it word for word, never wrapped in a fenced block of your own (its commands are fenced already), and say none of it twice: its whys, notes, manual tasks and "Workflow complete." appear only in it, never above it. It is never a tool call, unlike next, which is one. At a stop, resume_markdown is the stop's options, already written: end your report with it the same way, in place of any list, recap or summary of the options or ways forward of your own.
If that tool is not listed, the plugin's server did not start: codex mcp get multi_llm
names the command it tried, and python3 >= 3.9 must be on PATH.
まだレビューはありません。使ってみた感想をお寄せください。
ログインなしで書き込めます。使ってみた感想、質問、動かなかった環境などを気軽にどうぞ。
まだコメントはありません。最初のコメントを書いてみませんか。
複数の独立したローカル作業を安全性と依存関係を確認して実行計画にまとめ、対応環境では並列化やAppleシリコン向け処理の選択を支援します。
将来の読み手が理由を知りたくなる未決定や暫定対応を、技術的負債として登録し、後から項目ごとに整理できるスキルです。
LangChain、EINO、AutoGen、AgentScope、CrewAI向けのコード雛形やAPI対応、プロジェクト構成を参照し、バージョン確認を踏まえてAIエージェント開発を支援します。
エラーやテスト失敗、画面の異常などを再現して原因を特定し、テストで確認しながら影響を絞った修正を進めるデバッグ用スキルです。
対話を通じてAI Agentの要件整理から設計、ツール定義、コード生成、動作確認まで6段階で進め、実行可能なプロジェクトを作ります。
プロジェクトの範囲拡大や作業の分岐、命名・設計の不整合を読み取り専用で点検し、根拠と深刻度を添えた診断や、続行・分割・一時停止などの判断材料を報告します。