القائمة
ローカルにインストール済みの mmxcode (MiniMax バックエンドの Claude Code 互換 CLI) を使って、別 LLM (MiniMax) からのセカンドオピニオン・コードレビュー・意見交換を取得する。Claude が出した結論に別系統の目を入れたいとき、設計判断で複数モデルの見解を突き合わせたいとき、`ask-mmx` / `/ask-mmx` と言われたときに使用。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | ask-mmx |
| description | ローカルにインストール済みの mmxcode (MiniMax バックエンドの Claude Code 互換 CLI) を使って、別 LLM (MiniMax) からのセカンドオピニオン・コードレビュー・意見交換を取得する。Claude が出した結論に別系統の目を入れたいとき、設計判断で複数モデルの見解を突き合わせたいとき、`ask-mmx` / `/ask-mmx` と言われたときに使用。 |
このマシンには mmxcode (/Users/kohei/.local/bin/mmxcode) が入っている。これは MiniMax をバックエンドにした Claude Code 互換 CLI で、-p/--print で非対話の一発質問ができる。Claude Code (このセッション) から別 LLM (MiniMax) の意見を取るための「セカンドオピニオン」ツールとして使う。
これらの特性から、事実確認 (ファクトチェック) や 素早い別系統チェック が必要な場面で特に有用。
逆に 使わないほうがいい: 単純な質問・自分で十分判断できる作業・既に並列の Claude agent / codex を回している場合 (重複)。
mmxcode -p "ここに質問やレビュー依頼を書く"
-p / --print = 非対話のワンショット実行。stdout に最終回答が出るmmxcode -p "$(cat <<'EOF'
<質問本文>
EOF
)"
cat prompt.md | mmxcode -p
回答をファイルに残したいときはリダイレクトする:
mmxcode -p "..." > /tmp/mmx-answer.md
mmxcode -p "$(cat <<'EOF'
私 (別 AI) は以下の方針で実装しようとしている。これに反対する立場で論点を出してほしい。
盲点・見落とし・代替案を遠慮なく指摘してほしい。
# 背景
<タスクの背景>
# 提案中の方針
<Claude の結論>
# 制約
<制約条件>
EOF
)"
ポイント:
mmxcode -p "$(cat <<EOF
以下の diff を 1) ロジックバグ 2) エッジケース漏れ 3) テスト不足 4) 命名 の観点でレビューして。
\`\`\`diff
$(git diff)
\`\`\`
EOF
)"
結果を見て Claude 側で対応の要不要を判断する。MiniMax の指摘を鵜呑みにせず、根拠を確認すること。
mmxcode -p "$(cat <<'EOF'
以下の 2 案で迷っている。トレードオフを整理し、推奨案とその理由を述べてほしい。
## 案 A
<内容>
## 案 B
<内容>
## 評価軸
- 保守性
- パフォーマンス
- 実装コスト
EOF
)"
timeout 引数を伸ばすか、長い質問は run_in_background: true で投げる-p の非対話モードを使い、ファイル変更を伴うフラグ (--allow-dangerously-skip-permissions 等) は付けないdev系パイプライン（dev-pr-review / dev-pr-review-resolve / dev-issue-implement / dev-issue-review）を人間の確認なしで自律的に1タスク回すオーケストレーター。main を最新化した後、レビュー系を優先する固定順で対象を探し、最初に見つかった1件を対応するスキルで処理する。途中で解決済みIssueを見つけたら理由を書いてcloseする。needs-info によるユーザー確認待ちは禁止で、必ず自律判断する。ユーザーが「devパイプライン回して」「自律で開発回して」と言ったとき、または /dev-hotl を実行したときに使用。
reviewed ラベルがついたIssueを見つけて実装する。対象Issueに WIP ラベルをつけ、git worktree で main を汚さずに開発し、テストがPASSすることを確認した上でIssueに紐づくPR（Closes
現在のリポジトリの開発Issueが妥当かどうかをレビューする。リポジトリの目的に沿っているか、調査内容・設計に問題がないかをチェックし、WebSearch や Parallel Search MCP で裏取りして本文を追記・修正する。レビュー着手時に in-review ラベルで排他し、問題なければ reviewed ラベルをつけ、あまりに見当違いな場合は理由を記述してcloseする。Issue番号・URLを引数に取るか、未レビューのIssueを自動で探す。ユーザーが「Issueレビュー」「Issueの妥当性チェック」と言ったとき、または /dev-issue-review を実行したときに使用。
reviewed ラベルがついたPRを見つけて、レビュー指摘事項を検討・修正する。着手時に in-review ラベルで排他する。妥当な指摘は worktree 上で修正し、反論がある場合は根拠をコメントに記述して、各レビュースレッドをresolveしていく。すべてのレビューをresolveしたら必ずmergeする。PR番号・URLを引数に取るか、対応待ちのPRを自動で探す。ユーザーが「レビュー指摘を解消して」「reviewedのPRを片付けて」と言ったとき、または /dev-pr-review-resolve を実行したときに使用。
in-review ラベルがついていないオープンPRを見つけてレビューする。git worktree でPRのコードをローカルに取得し、変更箇所以外との整合性・紐づくIssue通りの実装かを確認する。問題なければmerge、軽微な指摘なら修正してmerge、問題が多い場合はレビューを記述して reviewed ラベルをつけ、見当違い・修正済みのPRは理由を記述してcloseする。PR番号・URLを引数に取るか、レビュー待ちのPRを自動で探す。ユーザーが「PRレビューして回して」「レビュー待ちPRを処理して」と言ったとき、または /dev-pr-review を実行したときに使用。
ローカルにインストール済みの Codex CLI (OpenAI) を使って、別 LLM からのコードレビュー・セカンドオピニオン・意見交換を取得する。Claude が書いたコードに対して「別モデルの目」を入れたいとき、設計判断で複数モデルの見解を突き合わせたいとき、`codex` / `/codex` と言われたときに使用。