ワークフローの frontmatter

workflow の YAML frontmatter がサポートするすべてのキーです。GitHub Agentic Workflows と共有するキーは上流の意味を保ちます。loopkeep 独自の設定は x-loopkeep.* の下に置きます。未知のキーは警告付きで保持されます。

on — トリガー

on:
  schedule:
    - cron: "0 3 * * *" # daily/hourly/weekly といったエイリアスも使える
  file-watch:
    paths: ["inbox/**/*.pdf"]
    events: [create, modify] # create | modify | delete
    debounce_ms: 2000
    min_size_kb: 1
    coalesce: latest # latest | all
  git:
    events: [commit, branch-created]
    branch: ["main", "release/*"]
    author_not: ["loopkeep[bot]"]
  run-completed:
    workflow: "test-fixer"
    status: [failed] # done | failed
    if: event.stats.attempts >= 3
  manual: {}
  slack: # Console 経由で届く
    events: [app_mention] # app_mention | dm
    channels: ["#ops"]
    from_not: ["*bot*"]
  issues: # GitHub イベント、Console 経由で届く
    repos: ["org/other-repo"] # 省略すると、この workspace の origin リモートに bind する

意味論 — フィルタ、集約の既定、連鎖の深さ — は トリガーガイド で扱っています。

engine

engine:
  id: claude # claude(Claude Code CLI、既定)| api(Anthropic API、自分の鍵)
  model: claude-sonnet-5
  params: {} # engine 固有のパラメータ
  permission_mode: auto # engine 自身の prompt の振る舞い。loopkeep のゲートはどのモードでも有効

bypassPermissions は明示的にオプトインしない限り拒否されます。plan は run には 使いません。

tools

tools: [edit, bash, web-fetch]

workflow が使ってよいエージェントツールの部分集合です。サポート外のツールは警告 されます。

permissions

ローカルの safe-outputs ゲートへの入力として解釈されます。gh-aw での意味に合わせます。

safe-outputs

safe-outputs:
  create-pull-request: {} # GitHub ネイティブの出力はあなたの gh 認証で動く
  local-commit: {}
  local-file-write: {}
  notify: {}
  run-command: {} # 常に policy 評価される
  dispatch-workflow:
    allowed: ["incident-triage", "inbox-processor"] # 明示的な allowlist、必須
  emit-output: {} # chaining 用の構造化 JSON。常に auto-approve

safe-output を宣言しても policy 評価は決して迂回されません。 emit-output だけは常に auto-approve です。下流の workflow に渡すだけだからです。

mcp-servers

# workspace または daemon の設定で — 定義:
mcp-servers:
  notion:
    command: "npx -y @notionhq/notion-mcp-server"
    env: { NOTION_TOKEN: "secret:notion-token" }

# workflow の中で — 名前だけで参照:
mcp-servers: [notion]

workflow はサーバを名前で参照し、接続の詳細は設定に置きます。workflow に接続情報を インラインで書くと、漏れた認証情報として扱われます — 値はログにも警告にも出力され ません。MCP のツール呼び出しも、ほかのアクションと同じように policy 評価を通ります (policy の match では tool: mcp:notion/create-page)。

x-loopkeep.concurrency

x-loopkeep.concurrency:
  max: 1
  on_limit: queue # queue(既定)| skip | replace

gh-aw ネイティブの concurrency: キーも上流の意味で尊重されます。 cancel-in-progress: true は replace のように、それ以外は queue のように 振る舞います。

x-loopkeep.budget

x-loopkeep.budget:
  tokens: 200000
  time_ms: 900000
  steps: 30 # ステップ N+1 で run を理由 budget で失敗させる
  daily_runs: 300
  daily_tokens: 500000

整数のみ。人を待っている時間は time_ms には数えません。

x-loopkeep.tags

x-loopkeep.tags: [deploy, migration]

policy の突き合わせ用の意味的なラベルです。自己申告なので — 硬い安全ルールは paths/tool で突き合わせるべきです。

x-loopkeep.execution_mode

x-loopkeep.execution_mode: attended # headless(既定)| attended | auto

run のエージェントがどこで動くかを決めます。

  • headless(既定)はエージェントをサブプロセスで走らせます。監督は受信箱から行います。
  • attended はターミナルマルチプレクサの pane で走らせ、同じセッションを直接見て steer できます。policy のゲートはどのツールにも従来どおり掛かります。
  • auto はトリガーで決めます。手動 run(あなたがそこにいる)は attended、無人の発火 — cron、webhook — は headless のままです。

attended には loopkeep が動かせるマルチプレクサが要ります。使えるものが無いときは run は headless に落ちます。ターミナルマルチプレクサのガイド を参照してください。

x-loopkeep.mux.space / x-loopkeep.mux.tab

x-loopkeep.mux.space: loopkeep # pane を置くマルチプレクサのセッション/workspace
x-loopkeep.mux.tab: automation # その中の tab/window

attended run の pane をどこに開くかです。どちらも未指定なら config の multiplexer.options、次に組み込み既定の loopkeep / automation に落ちます。pane 自体は run id で名づけられます。ターミナルマルチプレクサのガイド を参照してください。

secret の参照

本文では {{ secret:<name> }}、設定値では "secret:<name>"。 Secrets を参照してください。

{{ trigger }}

すべての run に注入されるトリガー context の配置マーカーです。なければ context は 本文の先頭に付きます。

前へCLI
次へpolicy.yaml