レイヤー

レイヤーはパイプラインを構成する個々のステップエージェントであり、それぞれが独自のサブプロセス内で固有のプロバイダー、モデル、そして新しいコンテキストウィンドウを持って実行されます。レイヤーは setting.json の step 配列で指定された順序で実行されます。各レイヤーからは自由テキストの要約のみが次のレイヤーに引き渡され、会話履歴全体やツール出力は引き渡されません。

レイヤーファイルの構造

step に含まれる各名前は、.stepper/layer/<name>/index.md にレイヤーファイルを持つことができます。このファイルは YAML frontmatter ブロック（構成）に続いてレイヤーのシステムプロンプト本文が記述される構造です。

---
description: implementation layer        # required
model: omlx/deepseek-coder               # or provider: + the default model
temperature: 0.2                         # sampling overrides → the request
top_p: 0.9
tools:
  allow: [read_file, write_file, edit_file, bash]
  deny:  [web_fetch]
permission:                              # per-layer overrides (tighten-only)
  Bash(rm *): deny
  Write(**): ask
mcp:
  allow: [context7]                      # which MCP servers this layer sees
skills: [rust-style]                     # skill bodies injected into the system prompt
steps: 40                                # step cap (ReAct iterations)
on-failure: skip                         # stop (default) | skip the layer and continue
retries: 1                               # extra attempts before applying on-failure
color: green
---
You are the implementation layer. Carry out the plan using the tools.

Frontmatter フィールド

• description（必須）— レイヤーの役割に関する簡潔な説明です。
• model または provider — このレイヤーのデフォルトモデルを上書きします。provider/model-id 形式を使用します（例: omlx/deepseek-coder）。
• temperature と top_p — API リクエストに渡されるサンプリングパラメーターです。
• tools.allow と tools.deny — このレイヤーが呼び出せるツール（例: read_file、write_file、bash）を制御します。
• permission — グローバルルールとマージされるレイヤーごとの権限ルールで、制限を強化することのみ可能です（下記セクションを参照）。
• mcp.allow — このレイヤーがアクセスできる MCP サーバーのリストです（例: [context7]）。
• skills — このレイヤーで利用可能なスキル名の配列で、本文は必要に応じて遅延ロードされます。
• steps — レイヤーが停止するまでの ReAct イテレーションの最大回数です。
• on-failure — stop（デフォルト; パイプラインを停止）または skip（次のレイヤーに進む）のいずれかです。
• retries — on-failure が適用される前に追加で試行する回数です。
• color — レイヤー用のオプションの TUI カラーラベルです。

権限の強化

レイヤーごとの permission ルールはグローバルルールの上にマージされ、deny > ask > allow の解決順序に従います。つまり、レイヤーは制限を**強化**することのみ可能であり、ベースの deny ルールを緩和することはできません。たとえば、グローバル構成が Bash(rm *) を拒否している場合、レイヤーがそれを許可することはできませんが、グローバルに許可されたツールに対してレイヤーが確認を求めるようにすることはできます。

並列レイヤー（ファンアウト）

レイヤーはファンアウトとして実行できます。サブタスクごとに 1 つの並行ワーカーが、それぞれ独自の新しいコンテキストウィンドウと同じレイヤー構成を持って実行され、次のレイヤーが結果を処理する前にすべて結合されます。並列実行を有効にするには、レイヤーに parallel: true を指定します。

タスク割り当て

並列レイヤーの**直前**のレイヤーには assign_tasks ツールが提供されます。このレイヤーは assign_tasks({ tasks: [{label, prompt}, …] }) を呼び出して作業をサブタスクに分割します。各サブタスクは並列レイヤーの 1 つのワーカーになります。直前のレイヤーがタスクを割り当てない場合、並列レイヤーはタスクコンテキストなしで 1 回だけ実行されます。

並行性とワーカーパネル

parallel-max を使用すると、同時に実行されるワーカー数を制限できます（例: parallel-max: 4）。これは並行性を制限するだけで、タスクを破棄することはありません。タスクはキューに入り、ワーカーが終了するにつれて実行されます。TUI はワーカーごとに 1 行を表示するライブの**ワーカーパネル**を表示し、現在のステータス、最後に呼び出されたツール、トークン数を示します。すべてのワーカーが終了すると、それぞれの要約が次のレイヤー向けの単一のハンドオフへと収束します。

---
description: implementation layer
parallel: true            # fan out — one worker per assigned subtask
parallel-max: 4           # max workers running AT ONCE (concurrency cap; no task is dropped)
model: omlx/deepseek-coder
tools:
  allow: [read_file, write_file, edit_file, bash]
---
You are one implementation worker. Complete only your assigned subtask, then
end with a concise summary of what you changed.

ワークフローの例

step: ["plan", "implement", "test"] で implement に parallel: が指定されている場合、plan レイヤーは要約を出力し、assign_tasks を呼び出して作業を実装サブタスクに分割します。各サブタスクは完全なレイヤー構成を持つ 1 つの implement ワーカーを起動します。すべてのワーカーが完了すると、test はすべてのワーカーの変更がマージされた要約を受け取ります。モデルから呼び出し可能な dispatch ツール（dispatch.enabled: true の場合）は、そのサブエージェントに同じワーカーパネルを使用します。