ワークフロー
workflow は markdown ファイルです。YAML frontmatter が「いつ発火し、何をしてよいか」
を宣言し、本文がエージェントへの自然言語の指示になります。workflow は
<workspace>/.loopkeep/workflows/*.md に置かれ、ほかのファイルと同じように
project と一緒にバージョン管理されます。
---
on:
schedule:
- cron: "0 3 * * *"
---
Review yesterday's commits and update CHANGELOG.md with anything user-visible.
{{ trigger }}
形式は GitHub Agentic Workflows と互換です。上流に存在するキーは
上流の意味を保ち、loopkeep は新しいキー(ローカルのトリガー、ローカルの
safe-outputs)を追加するだけです。loopkeep 固有の設定は x-loopkeep.* 名前空間に
置きます。未知のキーは警告付きで保持され、捨てられることはありません。
すべてのキーは workflow frontmatter リファレンス に記載しています。
編集と実行
アプリで ワークフロー を開きます。+ 新規 workflow は、トリガー、プロンプトの
本文、設定(engine、concurrency、budget、dispatch)のフォームと、markdown ファイル
全体を扱う Raw タブを持つエディタを開きます — 編集したブロックの外側のコメントやキーは
保持されます。Edit は既存の workflow を同じエディタで開きます。▶ 実行 は手動 run を
開始し(manual トリガーの無い workflow はヒントを出します)、workflow ごとのスイッチが
自動トリガーをオン/オフします。これらは project が信頼されていない間でも動きます。
トリガー context
すべての run は、何が発火させたのかを構造化して記述したものから始まります —
トリガーの種別、ソースイベント、上流の出力です。本文に {{ trigger }} で配置します。
書かなければ自動で先頭に付きます。これによって run-completed の workflow は上流の
run の出力を見られますし、Slack で発火した workflow は自分をメンションした
メッセージを見られます。
engine
engine: { id: claude, model: claude-sonnet-5 }
今は 2 つのエンジンがあります。claude(Claude Code CLI をサブプロセスとして動かす
— 既定)と api(Anthropic API、自分の鍵を使う)です。model と params は
workflow ごとです。軽い heartbeat の workflow は小さいモデルで動かし、重い作業は
大きいモデルで動かせます。
safe-outputs
safe-outputs は、workflow が生み出してよい効果を宣言します:
safe-outputs:
create-pull-request: {} # GitHub ネイティブ、あなたの gh 認証を使う
local-commit: {} # run の worktree で commit する
notify: {} # inbox に通知を投稿する
dispatch-workflow:
allowed: [incident-triage] # 別の workflow を発火(明示的な allowlist が必須)
emit-output: {} # chaining 用の構造化 JSON 出力
safe-output を宣言しても監督は迂回されません。エージェントが提案するすべての
アクションは、実行前になお policy 評価 を通ります。emit-output
だけが例外で、これは下流の workflow 向けのデータを生むだけなので常に auto-approve
されます。
workflow を連鎖する
run どうしが直接やり取りすることはありません。3 つの経路がつなぎます:
- run の出力 — エージェントが
emit-outputで JSON を出し、run-completedで購読している workflow がそれをフィルタでき(if: event.output.severity == "high")、トリガー context として受け取ります。 - dispatch — エージェントが
dispatch-workflowで別の workflow を発火させると 決め、入力の payload を渡します。対象はallowedリストに載っている必要があり、 dispatch 自体も policy 評価を受けます。 - ファイルシステム — ファイルを書き、
file-watchのトリガーで下流の作業を 起こします。多段のパイプライン(PDF を置く → 抽出 → 要約)に最適です。
連鎖は暴走しないよう深さで制限されます — トリガー を参照してください。
予算
x-loopkeep.budget:
tokens: 200000
time_ms: 900000
steps: 30
daily_runs: 300
daily_tokens: 500000
値はすべて整数です。予算を超えた run は理由 budget で失敗します。あなたの承認を
待っている時間は time 予算には数えられません。
並列数
x-loopkeep.concurrency:
max: 1
on_limit: skip # queue(既定)| skip | replace
queue は空きが出るまで新しい run を保留し、skip は発火を捨て(黙ってではなく
記録される)、replace は実行中のものを中断して新しいものを優先します — 最新だけが
意味を持つ heartbeat に便利です。すべての workflow を通じた daemon 全体の上限は
lk global-max で設定します。
tag
x-loopkeep.tags: [deploy, migration]
tag は policy が突き合わせられる意味的なラベルです。workflow が自己申告するものなので、
エスカレーションの便利手段として扱ってください — 硬い安全ルールは、workflow が
偽れない paths と tool で突き合わせるべきです。