mcpField
M
mempalace-task

mempalace-task

github.com/mempalaceエージェントワークフロー59.8k1.3k 回インストール3 日前に更新
リポジトリ

mempalace-task について

mempalace-taskは、MemPalaceのlogstreamを介してエージェント間の作業を調整するスキルです。承認、引き継ぎ、実行、パッチ提出、制御されたヘッドレス起動を扱い、IDと作業環境の確認を求めます。

主な機能

  1. 01承認済み内容によるタスク作成
  2. 02エージェントIDと作業環境の確認
  3. 03logstreamによる引き継ぎと監視
  4. 04パッチ提出と受領確認
  5. 05制御されたヘッドレスタスク起動

活用シーン

  1. 01リポジトリ作業を別のエージェントに依頼
  2. 02タスクリクエストの受信と検証
  3. 03明示的に許可されたランナーの起動

MCP 対応

`mempalace_task_create`、`mempalace_event_list`、`mempalace_patch_submit`などのMemPalace MCPツールを使い、共有logstreamで作業を調整します。リモート専用クライアント向けには、MCP経由でイベントを待機する方法も説明します。

インストール

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

$npx skills add https://github.com/mempalace/mempalace --skill mempalace-task

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

詳細

MemPalace タスク

エージェント間で引き継ぐ、進行中の作業のためのクイックスタートワークフローです。タスクはメモリの引き出しではなく、ログストリームに記録します。正式なライフサイクルと監視の手順については、公開されている 調整プロトコルを参照してください。

調整の接点を確認する

  1. mempalace --version が成功することを確認します。 また、mempalace task --help と mempalace_task_create が利用できることも確認します。どちらかが見つからない場合は、古いランタイムに更新認識コマンドがあると想定しないでください。互換性がないことを説明し、mempalace セットアップスキルに引き継ぎます。また、パッケージマネージャーに適したアップグレード方法(uv tool upgrade mempalace、pipx upgrade mempalace、またはアクティブな MemPalace コマンドを実行するインタープリターで -m pip install --upgrade mempalace を実行)と、それに続く npx skills update mempalace mempalace-recall mempalace-task を提案します。何かを実行する前に、明示的な許可を求めてください。
  2. MemPalace MCP ツールが接続されていることと、アクティブなパレスが意図した共有ブレインであることを確認します。
  3. 現在のエージェントの安定した host:harness:project ID を確立します。 別のエージェントになりすましてはいけません。ウィンドウを分けるために、ハーネスのサフィックスをもう一つ作ってはいけません。
  4. 可能であれば、宛先エージェントの監視状態を確認します。貼り付けた引き継ぎ内容によってターンベースのエージェントを起動できますが、ログストリームのイベントだけでは起動できません。

セットアップが完了していない場合は、作業を中断して mempalace セットアップスキルを使用してください。

タスクを作成する

ユーザーまたは現在のリポジトリの状態から、次のフィールドを収集します。

  • プロジェクトのルーティング名。
  • 依頼元と宛先のエージェント ID。
  • 正確な目標。
  • 対象ブランチ。
  • 正確な 16 進数のベースコミット ID(ブランチやタグは不可)。
  • 完了の定義。

ブランチと 16 進数のベースコミット ID は、無関係なリポジトリではなく、作業者が使用するチェックアウトから解決します。変更される可能性のあるブランチやタグをベースコミットとして渡してはいけません。何かを追記する前に、正規化したタスクの正確な内容をユーザーに提示します。内容には ID、プロジェクト、目標、ブランチ、ベースコミット、完了の定義、および引き渡しを MemPalace 経由で完了する必要があることを含めます。ログストリームのイベントは変更できないため、ユーザーがこのターンですでに明示的に承認している場合を除き、その内容について承認を得てください。

生の task.request を組み立てるのではなく、高レベルのインターフェースを通じてタスクを作成します。MCP が接続されている場合、特にクライアントがリモートの共有ブレインハブに接続する場合は、承認済みのフィールドを指定して mempalace_task_create を呼び出します。保存された task と handoff が返され、意図しないローカルパレスではなくハブに書き込まれます。

パレスを所有するマシン上、またはシェルを使ってローカルパレスを意図的に操作する場合、同等の CLI は次のとおりです。

mempalace task create \
  --project <project> \
  --from-agent <requester> \
  --to-agent <worker> \
  --goal <exact-goal> \
  --branch <branch> \
  --base-commit <commit> \
  --done <exact-definition-of-done>

複数行の CLI コンテンツには --goal-file または --done-file を使用します。ユーザーの表現を一行にまとめたり、言い換えたりしてはいけません。CLI は Ready to paste の行を出力し、MCP ツールは同じ行を handoff として返します。タスク本文全体をコピーすることなく宛先エージェントを起動できるよう、変更せずにその行を返してください。リモート MCP 呼び出しに失敗したという理由だけで、ローカル CLI にフォールバックしてはいけません。接続の問題を明らかにし、解決してください。

貼り付けられたタスクを受け取り、実行する

Open MemPalace task <id> as <agent>... を受け取った場合:

  1. mempalace_event_list を使い、correlation_id=<id> で正確な task.request を取得します。貼り付けられた短い行だけをもとに作業してはいけません。
  2. 自分宛てのタスク(または受け入れることが明示されたブロードキャスト)であることを確認し、編集前にワークスペース、ブランチ、ベースコミットを検証します。
  3. mempalace_event_ack(status=claimed) でリクエストを受領します。受領すると監視トリガーが作動するため、リモート専用 MCP クライアント(下記参照)でない限り、mempalace logstream watch --agent <you> --type task.request --type task.reply --type patch.ready --json を起動します(CLI は既定でサニタイズ済みの --state-file を設定します)。まず、自分の識別情報による既存の status=claimed がないか確認します。同時に受領された場合は、HLC が最も小さいものが優先されます。
  4. 作業を行い、指定された検証を実行します。
  5. mempalace_patch_submit でパッチを提出します。作業が妨げられた場合、または失敗した場合は、代わりに改変していない task.reply を送信します。何も応答しないことは、適切な結果ではありません。
  6. リクエスト元が成果物を取得して検証し、ユーザーに明示したうえで適用し、検証を実行した後、applied または failed を確認応答します。

リモート専用の共有ブレインクライアントでは、受信トレイの監視は MCP 経由で行います。安定した宛先 ID を使って mempalace_event_wait を実行し、最後のイベント ID を since_event_id として引き継ぎます。起動時の確認には mempalace_event_list を使います。このマシンがパレスを所有しているか、意図的に同期されたレプリカである場合を除き、ローカルの SQLite mempalace logstream watch コマンドを実行しないでください。

制御されたヘッドレスモード

ユーザーがエージェントの起動を明示的に依頼した場合に限り、まずタスクで指定された正確なブランチとベースコミットで、信頼できるクリーンな Git チェックアウトを準備します。その後、次を実行します。

mempalace task launch <task-id> --runner codex --workspace <path>
mempalace task launch <task-id> --runner claude --workspace <path>

これらのコマンドは、ローカルのパレスからタスクを解決します。リモート専用 MCP クライアントでは、mempalace_event_list で完全な task.request を1件取得し、その正確なイベントオブジェクトを JSON として実行先のマシンに保存して、無関係なローカルパレスを参照せずに起動します。

mempalace task launch --task-file <task-request.json> --runner codex --workspace <path>

タスクファイルは転送時点のスナップショットであり、タスクの代わりにはなりません。編集したり、再構成したりしないでください。ヘッドレス起動は、信頼できるチェックアウトを所有する実行先のマシンで必ず行います。ハブに追記するだけで、リクエスト元がリモートからプロセスを起動することはできません。

この処理では、保存済みのリクエストを解決し、ワークスペースがクリーンな Git チェックアウトであり、保存されたブランチ上にあって、HEAD が保存されたベースコミットと一致することを証明します。また、宛先の識別情報と、慣例に従った *-codex または *-claude のハーネス接尾辞を検証し、シェルを介さずに選択したランナーを起動します。ブロードキャストを受け入れる場合に限り、--agent <identity> を使用します。別の人宛てのタスクを上書きする目的で使ってはいけません。ランチャーはサンドボックス、承認、ハーネスの権限を回避しません。ユーザーに代わって危険な権限フラグを追加しないでください。

タスクの作成とプロセスの起動は別の操作です。貼り付け可能な引き継ぎが標準の移植可能な方法であり、ヘッドレス起動は明示的な制御モード用アダプターです。

想定外の状況

  • タスクが見つからない、または重複している: どのリクエストを実行するか推測せず、停止します。
  • 識別情報が異なる: そのタスクを拒否し、誰宛てのタスクかをユーザーに伝えます。
  • ベースコミットが一致しない: 編集せず、修正したリクエストでタスクを差し替えるようリクエスト元に依頼します。
  • 宛先が監視していない: 「貼り付ける準備ができました」という行をユーザーに提示し、人による起動が必要であることを説明します。
  • MCP/logstream が利用できない: mempalace status を実行してセットアップに戻ります。連携機能を黙ってメモリドロワーに置き換えてはいけません。

コメント