rehydrate

ワークフローの再構築スキル

概要

新しいセッションを開始せずに、コンテキストの自動要約後も維持されるワークフローの全体像を復元します。

このスキルが担うのは、ワークフロー状態の読み取り／復元側です。現在の状態を読み取り、git の実際の状態と照合し、ワークフローが存在するかどうかを確認します。書き込み側（初期化、更新、遷移、引き継ぎ情報の記録）については、@skills/checkpoint/SKILL.md を参照してください。

起動条件

次の場合にこのスキルを起動します。

• 要約後にコンテキストを復元する場合（rehydrate <featureId>）
• コンテキストの圧縮後、エージェントが本来の動作から逸脱している場合（イベントの出力やツールの積極的な使用をやめている）
• 中断後にワークフローに戻る場合

状態の保存場所

ワークフローの状態はファイルシステムではなく、MCP イベントストアに保存されています。exarchos:exarchos_workflow get で状態を読み取り、exarchos_view pipeline でアクティブなワークフローを確認してください。~/.claude/workflow-state/*.state.json はレガシーのパスで、古い情報が残っているか空の場合があるため、スキャンしないでください。

信頼できる情報源 — このワークフローは存在するか？

ワークフローの状態は2 つの領域に存在します。これらを混同すると、「追跡されていない」という誤った結論につながります。

1. SQLite イベントストア（events ＋ 投影された workflow_state ＋ streams）— ワークフローが存在するかどうかを示す信頼できる記録です。rehydrate／get はここを読み取ります。
2. <featureId>.state.json ファイル（状態ディレクトリ内）— イベント投影からは導出できない計画状態の情報（レビュー状況、宣言済みタスクリスト、各観点の調査結果）を保持する、*副次的な「プランナーの記録」*です。追跡対象のワークフローでも存在しない場合があり（CLI ツール、テスト、最初の update より前に進行中のワークフローなど）、存在確認には使えません。

正式な存在確認方法： rehydrate エンベロープの**_meta.workflowExists**（true／false）を使うか、同等の方法として data.workflowState.featureId が空でないことを確認してください。初期化（init）されていない featureId を新規環境で照会すると、空の初期ドキュメントと _meta.workflowExists: false を含む success: true が返されます。この照会は副作用がなく（workflow.rehydrated イベントは出力されません）、ディスク上の .state.json ファイルの有無から、ワークフローの存在を決して推測しないでください。

ワークフローを再構築する

exarchos:exarchos_workflow に action: "rehydrate" と featureId: "<id>" を指定します。正規の再構築ドキュメント（workflowState、taskProgress、artifacts、blockers、フェーズのプレイブック、次のアクション）を含むエンベロープが、1 回の呼び出しで返されます。複数の get fields=[...] を組み合わせる必要はありません。

featureId が不明な場合、またはユーザーが指定していない場合は、exarchos_view pipeline に切り替えてアクティブなワークフローを一覧表示し、どれを再構築するか確認してから、選択された featureId を指定して rehydrate を再実行します。パイプラインビューはデフォルトでリポジトリ単位に絞り込まれ、呼び出し元のリポジトリのみを一覧表示します。そのため、別のリポジトリで開始されたワークフローは表示されません。すべての応答には unscopedTotal（絞り込み前の件数）が含まれます。unscopedTotal が page.total を超える場合、非表示の行は他のリポジトリに存在するか、記録済みの識別情報がないレガシー行です。表示するには、scope: "all"（または明示的な repoRoot）を指定して再度照会してください。

状態の読み取り（対象を限定）

完全な再構築ではなく、対象を限定して読み取る場合は、exarchos:exarchos_workflow に action: "get" と featureId を指定します。

• 状態全体：featureId のみを指定して呼び出します
• 特定のフィールド：ドットパス検索用の query を追加します（例：query: "phase"、query: "tasks"）。応答の data には、クエリをキーとする値が 1 つ含まれます：{ "phase": "<phase>" }
• 複数のフィールド：投影用の fields 配列を追加します（例：fields: ["phase", "featureId", "tasks"]）

fields によるフィールド投影では、要求されたトップレベルのキーだけが返されるため、トークンの使用量を削減できます。

サマリーを取得する

要約後にコンテキストを復元する場合は、action: "rehydrate" を優先してください（1 回の呼び出しで完了し、フェーズのプレイブックと次のアクションが含まれます）。最小限の読み取りには、action: "get" と featureId を指定すると、オーケストレーターのコンテキストの再構築に適したサマリーが出力されます。

出力形式

返されたドキュメントをコンパクトな動作コンテキストとして出力します（コンパクション後のコンテキストと同じ形式）。エージェントが一度に認識を更新できるようにします。

## Workflow Rehydrated: <featureId>
**Phase:** <phase> | **Type:** <workflowType>

### House Rules (apply every action this turn forward)
**Skill:** <phasePlaybook.skillRef or "(no playbook for this phase)">
**Tools:** <phasePlaybook.tools rendered as bullets>
**Required model-emitted events:** <phasePlaybook.events rendered as bullets — e.g. `task.progressed`, `phase.advanced`>
**Auto-emitted events (runtime fires these):** <phasePlaybook.autoEmittedEvents rendered as bullets>
**Transition:** <phasePlaybook.transitionCriteria> | Guard: <phasePlaybook.guardPrerequisites>
**Validation scripts:** <phasePlaybook.validationScripts joined>

### Event Emission Hints
<_eventHints.missing rendered as bullets, or "(none — phase machinery satisfied)">

### Task Progress
<task table>

### Artifacts
- Design: <path or "not created">
- Plan: <path or "not created">
- PR: <url or "not created">

### Next Action
<suggested action, from the envelope's `next_actions`>

> **Discipline reminder:** every task transition this turn forward MUST land on the workflow event stream via `exarchos_event.append` or `delegate` subagent emission. Direct `Edit` / `Bash` / `git` actions on task branches without corresponding events will desync the workflow tracker (see RCA `docs/rca/2026-05-08-rehydrate-behavioral-gap.md`).

出力は最小限に抑え、必須の状態と動作ガイダンスのみを記載します。詳細はファイルに保持し、会話には含めません。

状態の照合

状態が Git の実態と一致することを確認するには、rehydrate <featureId> を実行します。再構成プロジェクションが最後のスナップショットより新しいイベントを反映し、返されるエンベロープで差異を明らかにします。より詳細な手動確認を行う場合は、照合スクリプトを実行します。

exarchos_orchestrate({
  action: "reconcile_state",
  stateFile: "<state-file>",
  repoRoot: "<repo-root>"
})

passed: true の場合： 状態は一貫しています。 passed: false の場合： 不整合が見つかりました。出力を確認し、action: "update" を指定して exarchos:exarchos_workflow で解決してください（@skills/checkpoint/SKILL.md を参照）。

ベストプラクティス

1. 再開時に照合する - 操作する前に、必ず状態が Git の状態と一致することを確認します
2. 記憶に頼らず状態を読む - 要約後は、メモリではなくイベントストアから読み取ります
3. 1 回の呼び出しで取得する - 1 回の rehydrate 呼び出しで正規ドキュメント全体が返されます。複数段階での読み取りは避けてください
4. _meta.workflowExists で存在を確認する - ディスク上の .state.json ファイルから存在を推測しないでください

トラブルシューティング

状態の不一致

ワークフローの状態が Git の実態と一致しない場合：

1. rehydrate <featureId> を実行します。再構成プロジェクションが最後のスナップショットより新しいイベントを反映します
2. 手動確認が必要な場合は、再構成ドキュメントの workflowState / artifacts を git log およびブランチの状態と比較します
3. action: "update" を指定して exarchos:exarchos_workflow で状態を更新し、Git の実態に合わせます（@skills/checkpoint/SKILL.md を参照）

再開時に古い状態が見つかる

状態が存在しなくなったブランチやワークツリーを参照している場合：

1. rehydrate <featureId> を実行します。再構成ドキュメントで古い参照が明らかになります
2. git branch -a / git worktree list と比較して差異を特定します
3. exarchos_workflow update で更新し、Git の実態に合わせます

複数のアクティブなワークフロー

複数のワークフロー状態ファイルが存在する場合：

1. システムは、最後に更新されたアクティブ（未完了）ワークフローを使用します
2. 古いワークフローに対して、action: "cancel" と dryRun: true を指定して exarchos:exarchos_workflow を使用し、クリーンアップをプレビューします
3. 新しいワークフローを開始する前に、古いワークフローをキャンセルします

ワークフローの例

1. コンテキスト喪失後に再開する：action: "rehydrate" と featureId: "user-authentication" を指定して exarchos:exarchos_workflow を使用し、コンテキスト復元の出力を取得します。

2. 状態を確認する：action: "get" と featureId: "user-authentication" を指定して exarchos:exarchos_workflow を使用します。

3. 存在を確認する：rehydrate エンベロープから _meta.workflowExists を読み取ります。false の場合、その機能はワークフローとして開始されていないため、ファイルシステムの確認から「追跡されていない」と判断するのではなく、その旨を報告します。