プロジェクトの途中再開

2週間離れていたプロジェクト。あるいは記憶のない fresh なエージェントセッションだ。ファイルを読んで今どこにいたか推測するな。

先にresumeを実行

/flow resume

プロジェクト途中にコールドで入るとき最初に入力する動詞だ。読み取り専用で、ロックを取らず、ディスク上の既存状態からセッションストーリーの概要を組み立てる：

最後のセッション（コマンド名のみ——生の引数は決して）
進行中のカードと放置時間（dwell）
現在のゲート状態
正確に1つの NEXT -> 行

NEXT -> 行を読んで、それを実行する。/flow status が使うのと同じ決定ヘルパーが生むので、両者が食い違うことはない。

スキップしてよいとき

この会話にライブのコンテキストが既にあるなら resume をスキップする——1分前に next や card を実行したのが自分なら、再実行しても何も増えない。コールドな入場のためのものであり、毎コマンドのためではない。

次に作業ビューを取る

/flow

素の /flow は status だ：今どこにいるか、何が止めているか、現在のステージdwell、カードリスト（10枚超は要約に圧縮）、1行のメモリ要約。再入場には resume、作業継続には status を使う。

Recallとpromote

/flow recall

ステージやカードの開始時、何かを書く前に recall を実行する。耐久層を読み戻す：未解決debt、最新のレトロ、前カードのスコープ、ハーネスの摩擦とbacklog、監査の健全性、promote済みプレイブック。出力はノイズではなく、適用すべきコンテキストとして扱う。作業は再発見ではなく、過去の痛みを見た状態で始まる。

捕捉は自発的ではなくエンジン発火だ：ステージ01の通過がintakeを生み、通過したカードチェックがtier採点済みtraceを記録し、意図的スキップがdebtをログする。status は1行のメモリ要約を示す。card は前カードのスコープを自動注入する。改善も機械的だ：harness audit はエントロピーとドリフトを採点し、harness propose は反復する摩擦をパターンが2回以上発火したら改善backlogに掘り起こし、harness decision outcome は予測対実績のループを閉じる。

会話ウィンドウは忘れる。耐久記録は忘れない。

プレイブックのpromote

教訓が1つのプロジェクトより大きいとき、持ち上げる：

/flow promote <playbook.md>

プレイブックをクロスプロジェクトのナレッジベース ~/.claude/flow/playbooks にコピーする。以降、recall は学んだ場所だけでなく、すべてのプロジェクトでそれを浮かべる。

ループは捕捉・再利用・改善だ：next と check が自動で記録を書き、recall が読み戻し、promote が価値のあったものを共有する。

追加エンジン（CodexとAntigravity）と耐久ループの残りはエージェントオーケストレーション。

古いセッションのロック解除

flow はプロジェクトごとに1セッションだ。2セッションが1つの計画を共有すると互いの状態を上書きする。ランナーは flow/.lock を保持する：next、card、skip、auto のような変更コマンドは見知らぬ fresh なロックを拒否し、status は警告し、ロックはTTL後に自動回収される——FLOW_LOCK_TTL、デフォルト900秒。

/flow unlock

相手セッションが本当に死んでいるときだけ使う——クラッシュした端末、放棄されたウィンドウ。相手セッションが生きているなら、止まって実行者と調整する。生きているロックを力ずくで越えない。並行実行は計画を壊す。

FLOW_FORCE=1 は死んでいると確信するロックを奪取する。/flow unlock でクリアする。ランナーが BLOCKED by another session’s lock と報告したら、止まって調整する——生きているセッションに FLOW_FORCE しない。

警告ではなく硬い保護が欲しければ、セッションごとに安定したセッションidを一度exportし、毎呼び出しに渡す：

export FLOW_SESSION_ID=$(uuidgen)
FLOW_SESSION_ID=$FLOW_SESSION_ID bash ~/.claude/skills/flow/runner/flow.sh next

これがないとランナーは競合セッションが別物であることを証明できず、警告しかできない——自ら止まることは決してない。

ブラウンフィールドを評価する

コードはあるが flow/ ディレクトリがないプロジェクトはブラウンフィールドだ。回復すべきセッションストーリーはまだない。resume から始めない。既存コードベースはIdeaステージから始めない。/flow assess が flow/00-inspect.md を足場掛けしてゲートをかける——現状マップ——計画ステージが開く前に。既存システムの計画は、リポジトリのREADMEの主張ではなく、そこにあるものに根ざすべきだ。

グリーンフィールドプロジェクトはこれをスキップし、/flow next（Idea）から始める。

オペレータ手順

プロジェクトルートで実行：
```
/flow assess
```
初回実行はinspectテンプレートを flow/00-inspect.md にコピーし、自動スキャン（スタック、CI、コンテキストファイル、ランク付き面）を生み、lawファイルを生む。まだゲートは通過しない。
全セクションを証拠から埋める（コードを読む）：
- 実ファイルからのスタック / ビルド / テスト / 実行コマンド
- 主要コンポーネント、モジュール、エントリポイント
- 現在の機能（動作 / 部分 / スタブ / 欠落）をファイル証拠付きで
- プロダクトの表明目標に対するUI/UX状態、または「UIなし」と記す
- 上位リスク、技術的負債、既知の問題
- テストと品質のベースライン（何がカバーされ、スイートの実行方法）
- Verdict：コードベースはその上にビルドできるほど健全か。何を先に直すべきか？
機能とリスクの通過はランク付き面の自動スキャンから始める。それらのファイルが最高レバレッジのコードだ——コードベースの大半が依存する面であり、横断的リスクが潜む可能性が最も高い場所だ。

Functionality / Risks / Verdict の重要な主張はすべて証拠台帳にタグ付けする。タグが Authoritative でない限り、プロダクト方針を事実として書かない。

タグ	意味
Authoritative	指示、受け入れ済み決定、プロダクト契約、文書化された手順
Observed	コード/設定/テストが現在の振る舞いを示す
Derived	観測された実装の直接的な運用上の帰結
Decision required	まだ権威のない規範的/プロダクト的選択
Unknown	リポジトリでは答えが立たない

人間が評価をレビューする。ブラウンフィールドはオペレータゲートだ。teach モードではエージェントは報告する。ボックスを tick したり、成果物を代筆したりしない。
/flow assess を再実行する。機械的PASSは [FILL] の残りがなく、すべてのゲートボックスがチェックされたことを意味する。FAILは残りの穴を列挙する。証拠から埋めて再実行する。
機械的PASSの後、計画の前に意味チャレンジを適用する：
- 重要な主張は Authoritative / Observed / Derived / Decision required / Unknown でタグ付けされているか？
- Observed や Derived の主張が、オペレータの権威なしに build 必須のプロダクト法に黙って昇格していないか？
- Decision required / Unknown の項目はオペレータ向けに列挙されているか——Scope/PRDに捏造されていないか？
- 空の台帳、またはボックスがチェック済みなのに [FILL] 行だけの台帳は中身がない：機械的通過だが質的に弱いと報告する。
両層が合意したら、/flow next で計画に進む。

証拠集めには scout / researcher（または bmad-document-project）を再利用できる。ゲートは依然として裁く。オペレータは依然としてレビューする。

サブディレクトリからの実行

frontend/ のように自分の flow/ を持たないサブディレクトリから flow を実行すると、断片化した第2ルートを作るのではなく、最も近い祖先のflowプロジェクトを採用し、stderrに1行メモを出力する。自分の flow/ や cards/ を持つサブディレクトリは常に尊重される。明示的な FLOW_PROJECT_ROOT も同様だ。