ワークフロー

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、自分の鍵を使う)です。modelparams は 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 つの経路がつなぎます:

  1. run の出力 — エージェントが emit-output で JSON を出し、run-completed で購読している workflow がそれをフィルタでき(if: event.output.severity == "high")、トリガー context として受け取ります。
  2. dispatch — エージェントが dispatch-workflow で別の workflow を発火させると 決め、入力の payload を渡します。対象は allowed リストに載っている必要があり、 dispatch 自体も policy 評価を受けます。
  3. ファイルシステム — ファイルを書き、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 が 偽れない pathstool で突き合わせるべきです。