mcpField
A
aep-executor

aep-executor

github.com/memorysaverエージェントワークフロー1858 回インストール6 週間前に更新
リポジトリ

aep-executor について

aep-executor は、AEP のワークフロースキルが実装作業を隔離ワークスペースで実行するための抽象化です。ホストに応じて実行モードを選び、ワーカーを起動せずに検出結果を確認することもできます。

主な機能

  1. 01ホスト機能の検出とモード選択
  2. 02Git worktree で実装エージェントを起動
  3. 03評価エージェントの起動
  4. 04指示の送信と稼働状況の確認
  5. 05人間の判断・レビュー用画面の提供
  6. 06ワーカーとワークスペースのクリーンアップ

活用シーン

  1. 01実装作業に適した実行バックエンドの選択
  2. 02隔離 worktree での実装・評価の実行
  3. 03ワーカーを起動せずに検出モードを確認

インストール

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

$npx skills add https://github.com/memorysaver/agentic-engineering-patterns --skill aep-executor

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

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

references/
action-list.schema.json
backends.md
claude-native.md
codex-native.md
dogfood-validation.md
tmux-session.md
scripts/
detect-backend.sh
spawn-liveness-probe.sh

詳細

Executor 抽象化

実装作業を隔離されたワークスペースで実行するための再利用可能な抽象化です。どのエージェントホスト（Claude Code、Codex）を使うか、どの実行方式を利用できるかに依存しません。ライフサイクルスキルでは一貫した操作名を使い、このスキルが各モードの操作を具体的な手順に対応付けます。/aep-launch、/aep-build、/aep-autopilot からライブラリとして利用でき、単独で検出のドライランを実行することもできます（単独での使用を参照）。

ネイティブ方式を優先： Claude Code の起動では、ネイティブのインプロセス・バックグラウンドサブエージェント（native-bg-subagent、デフォルト）を使います。また、claude --bg フラグが存在する環境では、ネイティブのバックグラウンドセッション（claude-bg）を使います。Codex の起動では、ネイティブのサブエージェント（codex-subagent）またはヘッドレス実行ワーカー（codex-exec）を使います。tmux+cmux は**legacy**モードであり、明示的な固定指定（git config aep.executor-backend tmux）がある場合、または汎用ホストでのみ選択されます。すべてのモードで、ワーカーは AEP が作成した .feature-workspaces/<ws> 内の git worktree で実行されます。

他のスキルでの使用方法

スキル使用内容操作
/aep-launch実装エージェントを起動し、レビューできる状態にするdetect、spawn、present
/aep-build Phase 5適切な実行コンテキストで評価担当を起動するdetect、spawn_evaluator
/aep-buildビルド中に人による判断を求めるgate
/aep-autopilot定期チェックを低コストで実行し、ワークスペースを誘導するdetect、check、nudge、liveness、gate
/aep-wrapマージ後にワーカーと worktree を破棄するteardown
/aep-dispatch引き継ぎモードを解決し、「…with workflow」実行を振り分けるdetect

操作コントラクト

すべてのコンシューマーは、これらの動詞を使用します。レシピファイルがモードごとの実装を提供します。

操作目的
detect()ホスト、ネイティブ機能、固定設定を解決し、モードを選択します
spawn(ws, branch, prompt)AEP ワークツリーに紐づけられた実装エージェントを起動します
spawn_evaluator(ws, role)モードの評価コンテキストで評価エージェント（ワークツリーに紐づく）を起動します。オプションで、ティアから導出したエフォートヒントを受け取ります（backends.md を参照）
nudge(ws, msg)作業中に指示を送信します（調整可能なモード。claude-bg ではプル方式です）
liveness(ws)エージェントは現在作業中ですか？（モード固有のシグナルと Git 差分による裏付け）
gate(ws)ワーカーから人間の判断を提示します。needs-human.md とモードのトランスポートを使い、メインエージェントを介したハブ・アンド・スポーク方式で回答します（その場でブロック、またはゲートを設けて待機）
check(prompt, schema)低コストでコンテキストを分離したエージェントで読み取り専用の分析プロンプトを実行し、JSON の結果を返します。長時間稼働するオーケストレーターセッションのコンテキストを小さく保てます
monitor(ws).dev-workflow/signals/status.json を読み取ります（ホストに依存せず、変更されることはありません）
present(ws)人間によるレビュー画面（TaskOutput / claude attach / Codex スレッド / cmux タブ / シグナル）
teardown(ws)ワーカーとワークツリーをクリーンアップします

monitor() はすでに抽象化されています。 どの実行環境でも、フェーズの境界でシグナルファイルを通じて進捗が報告されます。ネイティブのプッシュチャネル（SendMessage、send_input）は高速化レイヤーです。シグナルファイルは引き続き、永続的でホストに依存しない信頼できる情報源です。

モード（概要）

モードライフタイム選択条件
native-bg-subagentセッションに紐づくClaude Code のデフォルト ＋ 長時間稼働するオーケストレーター
claude-bgOS に紐づくClaude Code で claude --bg が利用可能（cron ドライバー／OS に紐づく必要がある場合）
codex-subagentセッションに紐づく稼働中のメインスレッドがある Codex（デスクトップアプリまたは対話型 CLI）
codex-execOS に紐づくCodex ＋ cron ドライバー、または強い隔離が必要な場合
legacyOS に紐づく明示的な固定設定（aep.executor-backend tmux）、または tmux を備えた汎用ホスト
workflowセッションに紐づく明示的なオプトイン（「…with workflow」）＋ Claude Code（/aep-workflow を参照）
headlessセッションに紐づく最終手段

各モードの仕組み、検出手順、選択順の全容、ドライバーとバックエンドの互換性マトリクス、人間によるゲートのプロトコル、孤立したプロセスの再取り込みについては、references/backends.md を参照してください。

参照ファイル

ファイル内容読むタイミング
references/backends.mdモードマトリックス、検出、選択順序、ドライバーの互換性、ゲートプロトコル、孤立プロセスの再引き継ぎ、check()起動または制御を行う前に必ず
references/claude-native.mdnative-bg-subagent（デフォルト）と claude-bg のレシピ、--bg の利用可否に関する注記選択されたモードが Claude ネイティブの場合
references/codex-native.mdcodex-subagent と codex-exec のレシピ、aep-builder／aep-evaluator のロール TOML、デスクトップアプリのマッピング選択されたモードが Codex の場合
references/tmux-session.mdlegacy のレシピ（tmux の起動／促し／稼働状況、cmux のタブ選択手順）legacy が固定または選択されている場合
references/dogfood-validation.mddogfood_method() によるホスト × モードの検出、e2e_tool()、target_url() の解決dogfood 検証の実行時（/aep-build、/aep-launch、/aep-watch、自動操縦のマージ後ガードで使用）

このスキルにはプローブも 2 つ同梱されているため、参照資料から正確な bash を 書き写す必要はありません。bash は一か所にまとめられています。

  • scripts/detect-backend.sh [--lifetime long|ephemeral] [--opt-in workflow|tmux] [--json] — ホスト、実行コマンド、ネイティブ機能、固定指定、表示面、および 選択された MODE。使用するには eval "$(bash scripts/detect-backend.sh)" を実行します。
  • scripts/spawn-liveness-probe.sh <name> <agent_id> — すべての起動処理が実行する、起動後の稼働状況 プローブ（references/backends.md § 起動後の稼働状況プローブ）。

単独での使用

このスキルを直接呼び出すと、何が起こるかを報告します。

  1. bash scripts/detect-backend.sh を実行します（一回限りの cron／launchd 呼び出しの場合は --lifetime ephemeral を追加します。スクリプトではこれを検出できません）。
  2. 出力される各フィールドを報告し、どの先行ルールに一致しなかったためにその MODE が選ばれたのか、 理由を説明します。
  3. ユーザーが「workflow ではなく、なぜ tmux でもないのか」と尋ねた場合は、オプトイン／固定指定の ゲートについて説明します。

これは何も起動しません。detect() のドライランです。

理由

ネイティブモードを優先し、tmux を固定指定が必要な legacy モードにしている理由、AEP が ワークツリーを所有する理由、セッションに紐づくか OS に紐づくかを主要な軸としている理由、人間によるゲートを ハブアンドスポーク型にしている理由、および自動操縦が制御可能なモードのみを駆動する理由は、 docs/decisions/native-first-executor.md、 docs/decisions/host-agnostic-executor.md、および docs/decisions/remove-claude-team.md に記録されています。

次のステップ

検出／起動後、制御は呼び出し元のスキルに戻ります。

  • /aep-launch → ブートストラップは起動プロンプト（ネイティブモード）として使われるか、 tmux 経由で送信され（legacy）、その後 /aep-build がワークスペースで実行されます
  • /aep-autopilot → ティックループを再開します
  • /aep-dispatch → 引き継ぎを完了します

コメント

Markdown 対応