mcpField
G
grok-subagent

grok-subagent

github.com/chuxubankエージェントワークフロー048 回インストール6 日前に更新
リポジトリ

grok-subagent について

grok-subagentは、実装タスクをGrokに委任するためのスキルです。親エージェントが範囲設定、レビュー、検証、公開を担い、CLIの確認と変更内容の独立した検証を重視します。

主な機能

  1. 01CLIのバージョンと引数の確認
  2. 02タスク境界と制約の設定
  3. 03Grokのヘッドレス実行
  4. 04停止理由とリポジトリ変更の確認
  5. 05実装の独立したレビューと検証
  6. 06範囲を絞った修正パス

活用シーン

  1. 01範囲を限定したコード変更の委任
  2. 02互換性のないGrok CLI間の混同防止
  3. 03ヘッドレス実行の完了状況の確認
  4. 04コミット前の委任変更のレビュー

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/chuxubank/skills --skill grok-subagent

インストール後、Claude Code で/grok-subagentを入力して読み込まれたか確認します。

詳細

Grok サブエージェント

実装作業者として Grok を使用します。スコープの決定、レビュー、検証、コミット、外部への公開は親エージェントが担当します。

ワークフロー

1. ローカル CLI の仕様を確認する

次を実行します。

grok --version
grok --help
jq --version

インストール済みバイナリが報告するフラグを優先してください。Grok Build 1.0.5 では次を使用します。

  • -p, --single <PROMPT>：ヘッドレスで 1 ターン実行します
  • --prompt-file <PATH>：プロンプトファイルを指定します
  • --cwd <PATH>：作業ディレクトリを指定します
  • --permission-mode auto：非対話型の実装に使用します
  • --output-format json：実際の停止理由を確認できるようにします
  • --no-subagents：ネストした委任を防ぎます

Grok CLI という名前の別のプロジェクトでは、--prompt や --directory など、互換性のないフラグが使われています。 --help を確認せずに、異なる CLI の例を流用しないでください。

2. 作業範囲を定める

委任する前に、次を行います。

  1. リポジトリの状態と現在のブランチを確認します。
  2. 既存の変更を保持し、その内容を説明します。
  3. 完了条件を明示して、焦点を絞ったタスクを Grok に 1 つだけ渡します。
  4. 確認する価値のあるファイルやローカルの参考実装を指定します。
  5. 正確な検証コマンドを指定します。
  6. ユーザーが明示的に Grok に委任しない限り、コミット、タグ付け、プッシュ、パッケージの公開、破壊的な Git 操作は親エージェントが行います。

並列作業やリスクの高い作業では、呼び出す前に Grok の外部で隔離環境を作成します。 ヘッドレスの -p は、--worktree からワークツリーを作成しません。

3. Grok をヘッドレスで実行する

ホストがシェルサブエージェントに対応している場合は、親がほかの作業を調整できるよう、この呼び出しをシェルサブエージェントに委任します。シェルサブエージェントは、タスクを代わりに実装するのではなく、実際に Grok を実行しなければなりません。

絶対パスのリポジトリを使用し、ヒアドキュメントでプロンプトを引用します。Grok Build 1.0.5 はツール呼び出しがキャンセルされてもステータス 0 で終了することがあるため、JSON を取得します。

grok_result=$(grok -p "$(cat <<'EOF'
Work in /absolute/path/to/repository.

Task:
- <one focused implementation goal>

Requirements:
- <behavior and compatibility constraints>
- Preserve existing public APIs unless explicitly changed.
- Preserve pre-existing uncommitted changes.

Verification:
- Run <exact test/build commands>.
- Run git diff --check.

Do not commit, tag, push, publish, reset, or discard unrelated changes.
Return changed files, design decisions, test results, and unresolved risks.
EOF
)" \
  --cwd "/absolute/path/to/repository" \
  --permission-mode auto \
  --no-subagents \
  --output-format json)

printf '%s\n' "$grok_result"
printf '%s\n' "$grok_result" | jq -e '.stopReason == "end_turn"' >/dev/null

実行ファイルのパスが不明な場合は command -v grok を使用します。生成したプロンプトが非常に長い場合は --prompt-file を使用します。プロンプトに認証情報、トークン、個人データを含めないでください。auto を bypassPermissions に置き換えず、委任する作業ディレクトリとタスクの範囲を狭く保ってください。

プロセスがステータス 0 で終了していても、cancelled、max_turns、出力がない場合、JSON が無効な場合、その他の停止理由はすべて呼び出しの失敗として扱います。変更を伴うタスクでは、期待したリポジトリの差分も必須です。要求したファイルや動作がない end_turn は成功ではありません。

4. 中央でレビューする

Grok の報告は、検証が必要な主張として扱います。

  1. git status、git diff --stat、git diff --check、および関連する差分全体を確認します。
  2. 新しい公開インターフェースとセキュリティ上重要なパスをすべて読みます。
  3. 削除と依存関係の変更が意図したものか確認します。
  4. 必須のテストとビルドを独自に実行します。
  5. 古い API やパッケージを置き換えるタスクの場合は、古い参照が残っていないか検索します。
  6. 意図したファイルだけが変更されているか確認します。

親が変更後の設計を説明でき、検証の合格を直接確認できた場合に限り、このステップは完了です。

5. 焦点を絞った修正を依頼する

レビューで不具合が見つかった場合は、次の内容を含む、範囲を絞った修正を Grok に依頼します。

  • 具体的な不具合と、それが重要な理由
  • 必要な動作
  • 変更または追加が必要なテスト
  • 同じ Git 操作とスコープの制約

実装時のコンテキストを維持できるよう、可能であれば同じホストのシェルサブエージェントを再開します。そのサブエージェント内で Grok を再実行し、中央でのレビューを繰り返します。

Grok が停止した場合や編集せずに終了した場合は、.stopReason、出力、リポジトリの状態を確認します。提案されたツール呼び出しの後に cancelled になった場合、通常は権限モードの不一致を示しています。根拠のある原因を変更してから、またはタスクを縮小して完了条件を明確にしてから、1 回だけ再試行します。新たな根拠なしに同じ呼び出しを繰り返さないでください。

プロンプトのチェックリスト

  • リポジトリの絶対パス
  • 焦点を絞った目標を1つ
  • 保持すべき既存の変更
  • 具体的な動作と対象外の事項
  • 言語とアーキテクチャの制約
  • 関連するソースと参照パス
  • エラーと互換性に関する要件
  • 必須のテストとビルドコマンド
  • コミット／プッシュ禁止のガードレール
  • 最終報告に含める内容

完了レポート

次の内容を報告します。

  • Grok コマンドの形式、CLI のバージョン、JSON の停止理由
  • 実装の概要
  • 変更または削除したファイル
  • 独立して実施したテスト／ビルドの結果
  • 親によるコミットまたは公開
  • 残っているブロッカー、または実機／ランタイムでの検証事項

コメント

Markdown 対応