tomoking2004 対象：ユーザーが実行を求めたプログラム・スクリプトのうち，数十秒を超えて走るもの——学習・評価・データ処理・サーバ等，起動したまま会話を続けたり離席したりし得る実行．
このうち常駐するもの（サーバ・デーモン・監視プロセス）には「完了」が無い——手順4・5（完了照合・完了通知）は適用せず，起動を確認したら Monitor が異常だけを見張り続ける（ops-exit= が出たなら，それは正常終了ではなく落ちた合図である）．
対象外：数十秒で終わる実行——テスト・ビルド・lint・ワンライナー・git 操作など，結果をその場で見て次の一手を決めるもの．通常のフォアグラウンド実行で足りる（/refine:code ・ /assignment:program ・ /groundwork:impl 等が行う実行確認はここに属し，本スキルを挟まない）．所要時間が読めなければまず短命として実行し，数十秒で返らなければ中断して本スキルで起動し直す．
手順
寿命を決めて起動する．どちらの形でもログ・終了コードの刻印は下の「実行の正典」に従う．
セッション内：1時間以内に終わると見込めるもの．Bash を
run_in_background: trueで起動する——ハーネスが完了時に通知する．セッションを閉じるとジョブも終わる．分離：1時間を超えうるもの，またはユーザーの離席・セッション終了が見込まれるもの．親シェルから切り離し，セッションが閉じてもジョブを残す——切り離せているかは，別の Bash 呼び出し（＝新しいシェル）からプロセスがまだ見えることで確かめる：
mkdir -p logs; nohup sh -c '<コマンド> > logs/<名前>.log 2>&1; echo "ops-exit=$?" >> logs/<名前>.log' > /dev/null 2>&1 & echo $! > logs/<名前>.pid区切りは
;であって&&ではない——&&で繋ぐと&がその AND リスト全体をバックグラウンドに送り，echo $!がmkdirより先に走ってlogs/不在で落ちる（かつ$!がジョブでなくサブシェルを指す）．この形はハーネスの完了通知を持たない——完了は手順2の Monitor が
ops-exit=で拾い，セッションが閉じた後は /ops:progress がログから復元する．迷ったら分離を選ぶ（ジョブを失わない側に倒す）．
Monitor を張る：
persistent: trueを必ず指定する——既定5分・上限1時間のタイムアウトでは長時間ジョブの後半を見失う．tailは-n +1 -Fでログの冒頭から読む——起動直後の即死（import エラー・パス誤り・権限）が Monitor を張る前に済んでいても取りこぼさない．したがって起動後に待って生存確認する手順は要らない（フォアグラウンドのsleepはハーネスで禁じられており，そもそも打てない）．tail -n +1 -F logs/<名前>.log | grep -E --line-buffered "<進捗マイルストーン>|ops-exit=|Traceback|Error|Exception|Killed|OOM|Segmentation fault|Fatal"- 失敗を必ず捕らえる：「今このジョブがクラッシュしたらこの grep は何か出すか」を問う——出ないなら広げる．
ops-exit=は常に含める：これがあれば，正常終了も異常終了もハングも，沈黙のまま見過ごされることがない． - 進捗は間引く：毎ステップ出る行を入れてはならない．Monitor はイベントが溢れると自動停止され，肝心の失敗を取り逃す．エポック完了・評価結果など，数分に1回程度に落ちるマイルストーンだけを選ぶ．
- 失敗を必ず捕らえる：「今このジョブがクラッシュしたらこの grep は何か出すか」を問う——出ないなら広げる．
状況把握手段を案内する：対象がライブダッシュボード・TensorBoard・進捗 URL 等を自分で提供していないか探す（生成される HTML/JSON，ログ冒頭の URL）．見つかればその URL を，無ければログの場所と所要時間の見積もり（過去の同種実行や進捗の速度から分かるとき）を一言で伝える．確認は求めず，伝えるだけでよい．
終了したらログ全文と成果物を照合する：
ops-exit=の値（またはハーネスの完了通知）を鵜呑みにせず，ログを実際に読んで裏取りする．完了時に生成されるはずの成果物（チェックポイント・出力ファイル等，特定できるとき）が実在するかも確かめる——ログにエラーが無いことは成果物の存在を保証しない．離席が見込まれたジョブは，成功・失敗を問わず完了時に1回 PushNotification を送る（
status: "proactive"，200字以内）：離れている間に終わったことこそ知らせるべき情報である．失敗ならどこで何が起きたかの要点を，成功なら主要な結果（accuracy 等）を一言で．ユーザーが今まさに会話中で見ているものには送らない．Monitor を止める：プロセス終了を確認したら TaskStop で閉じる．
実行の正典
- シェル：起動も監視も Bash ツール（Windows では Git Bash）で行う——POSIX のコマンドが両プラットフォームで通る．
- ログ：
logs/<名前>.logにリダイレクトだけで書き出す（> logs/<名前>.log 2>&1）．| tee等の中継パイプは付けない——パイプラインの終了コードは最後のコマンドのものになり，本体の異常終了が 0 にマスクされる．logs/が git 管理下に入るなら.gitignoreへの追加を促す（実行の痕跡であって成果物ではない）． - 終了コードの刻印：本体の直後に
echo "ops-exit=$?" >> logs/<名前>.logを必ず続ける——これがログだけから完了・失敗を判定できる唯一の痕跡であり，Monitor の完了シグナルであり，セッションが尽きた後に /ops:progress が拾う手掛かりになる． - 起動はこちらが打つ：ユーザーがターミナルで直接起動したプロセスの標準エラーは，そのセッションと共に失われ後から追跡できない．
自己点検
- 対象判定：数十秒で終わる実行に本スキルを被せていないか．
- 寿命判定：離席が見込まれるのにセッション内モードで起動していないか．
- Monitor の広さ：失敗シグネチャと
ops-exit=を含み，クラッシュ時に必ず何か出るか． - Monitor の細かさ：進捗行が細かすぎてイベントが溢れないか．
- 沈黙を成功と読まない：完了は
ops-exit=と成果物の実在で裏取りしたか．
制約
- 会話は止めない：起動・監視・案内（手順1〜3）を終えたら完了を待たず，指示も待たずに通常の会話を続ける——手順4以降はジョブが終わった時点で働く．状況確認が来たら /ops:progress の手順で答える．
- 不可逆・有償・占有は起動前に承認を得る：データの削除・上書き，本番環境への反映，課金の発生する実行（API の大量呼び出し・クラウド計算資源），GPU 等の長時間占有を伴うなら，何が起きるかを告げて承認を得てから起動する——バックグラウンドで走り出したものは取り消しが利きにくい．
- 実行内容そのもの（コマンド・引数・設定）は勝手に変えない．変える必要があれば問う．
失敗時
/heal:skill を呼ぶ．