Skip to content
Weaveweave / docs
Get started ↗
Docs/Reference/DSL Configuration

DSL Configuration

Complete guide to the Weave DSL configuration language

The .weave configuration language is a block-structured, declarative DSL for declaring agents, categories, workflows, prompts, delegation intent, model preferences, and settings. It is not TypeScript, JSON, or YAML.

Weave loads configuration from up to three layers, merged in priority order:

Scope Path Purpose
Builtin Embedded in @weaveio/weave-config Eight core agents shipped with Weave
Global ~/.weave/config.weave User-level defaults, shared across projects
Project .weave/config.weave Project-level config, overrides global
~/.weave/ # Global config root
├── config.weave # Global agent/category/workflow definitions
└── prompts/ # Global prompt files
└── my-agent.md
.weave/ # Project config root
├── config.weave # Project agent/category/workflow definitions
├── prompts/ # Project prompt files
│ ├── loom.md
│ ├── shuttle.md
│ └── custom-agent.md
├── plans/ # Plan files (created by Pattern agent)
└── workflows/ # Additional workflow files (optional)

Plan files are always stored under .weave/plans/. Plan-related learnings and execution artifacts should also stay under .weave/, not in top-level plans/, learnings/, or state directories.

Configuration is assembled from three layers in priority order (lowest to highest):

┌─────────────────────────────────────────────────────────────┐
│ Layer 1 (lowest priority) — Built-ins │
│ packages/config/src/builtins.ts — BUILTIN_WEAVE_SOURCE │
│ │
│ Layer 2 — Global │
│ ~/.weave/config.weave │
│ │
│ Layer 3 (highest priority) — Project │
│ <projectRoot>/.weave/config.weave │
└─────────────────────────────────────────────────────────────┘
Value type Behavior
Scalar (string, number, boolean, enum) Last-defined wins (project overrides global overrides builtin)
Object (e.g. agents, tool_policy) Recursive deep-merge (only keys present in the override are updated; all other keys are preserved from lower layers)
Array (e.g. models, disabled.agents) Union-merge (override entries come first, then base entries not already present, deduped by JSON.stringify equality; order reflects priority, highest-priority first)
Workflow (when extends is set) Step-aware merge (see Workflow Extension below)

A project config with this declaration:

agent loom {
temperature 0.5
}

leaves all other loom fields (models, prompt_file, tool_policy) intact from the builtin layer. Only the temperature field is overridden.

Builtin layer:

agent shuttle {
description "Shuttle (Domain Specialist)"
prompt_file "shuttle.md"
models ["claude-sonnet-4-5"]
mode subagent
temperature 0.2
tool_policy {
read allow
write allow
execute allow
delegate deny
network ask
}
}

Project layer:

agent shuttle {
temperature 0.1
models ["gpt-4o", "claude-sonnet-4-5"]
tool_policy {
network deny
}
}

Merged result:

agent shuttle {
description "Shuttle (Domain Specialist)"
prompt_file "shuttle.md"
models ["gpt-4o", "claude-sonnet-4-5"] # Array union-merge: project first
mode subagent
temperature 0.1 # Scalar override
tool_policy { # Object deep-merge
read allow
write allow
execute allow
delegate deny
network deny # Overridden from project
}
}
Feature Syntax
Comments # line comment
Strings "double-quoted"
Multi-line strings """ ... """
Arrays ["item1", "item2"]
Booleans bare true / false
Enums bare identifiers (allow, deny, primary, …)
Numbers bare numeric literals (0.1, 1)
Named blocks keyword name { ... }
Scalar key-value key value (no colon, no semicolon)
# This is a comment
agent my-agent {
description "My custom agent"
prompt """
You are a helpful assistant.
You answer questions concisely.
"""
models ["claude-sonnet-4-5", "gpt-4o"]
mode subagent
temperature 0.3
tool_policy {
read allow
write deny
}
}

Agents are the primary declaration unit. Each agent block declares a named agent with its prompt source, model preferences, mode hint, tool policy, and optional delegation triggers.

See the Agents guide for detailed information about agent roles, delegation patterns, and builtin agents.

agent loom {
description "Loom (Main Orchestrator)"
prompt_file "loom.md"
models ["claude-sonnet-4-5", "gpt-4o"]
mode primary
temperature 0.1
variant "preview"
tool_policy {
read allow
write allow
execute allow
delegate allow
network ask
}
triggers [
{ domain "Orchestration" trigger "Complex multi-step tasks" routing_hint "Use for work spanning multiple files or components" }
{ domain "Architecture" trigger "System design and planning" routing_hint "Use when design decisions need to be made before implementation" }
]
skills ["tdd", "code-review"]
}
# Minimal agent with inline prompt
agent my-helper {
prompt "You are a helpful assistant that answers questions concisely."
models ["claude-sonnet-4-5"]
mode subagent
temperature 0.3
}
Field Type Description
description string Human-readable label shown in harness UI
display_name string Optional display name shown in harness UI. If omitted, the agent’s block name is used.
prompt string Inline prompt text. Mutually exclusive with prompt_file.
prompt_file string Path to a .md file, resolved relative to the config scope’s prompts/ directory. Mutually exclusive with prompt.
prompt_append string Inline text appended after the primary prompt source. Rendered as a Mustache template. Mutually exclusive with prompt_append_file.
prompt_append_file string Path to a .md file appended after the primary prompt source. Mutually exclusive with prompt_append.
models string[] Ordered model preference list. Adapters translate to concrete harness model fields.
mode primary | subagent | all Adapter-facing context hint. primary = main/user-facing; subagent = delegated specialist; all = usable in both.
temperature number Sampling temperature hint passed to adapters.
variant string Free-form string for model variant selection (e.g. "preview", "latest"). Passed through to adapters; runtime validation of supported variants is harness-owned.
tool_policy block Abstract capability map. See Tool Policy below.
triggers array Delegation metadata for router agents. Each entry: { domain "..." trigger "..." routing_hint "..." }. The routing_hint field is optional and provides prescriptive “Use when…” guidance for delegation routing.
skills string[] Skill names to load for this agent.
routing block Per-agent routing configuration. Currently supports delegation_exclude: a string array of agent names to exclude from this agent’s delegation targets.
review_models string[] Optional. One or more model identifiers materialized as independent reviewer variants when config is loaded/composed.

The tool_policy block declares abstract capabilities. Adapters map these to harness-specific tool names and permission models. See the Tool Policy guide for detailed evaluation semantics.

tool_policy {
read allow
write allow
execute allow
delegate deny
network ask
}
Capability Values Meaning
read allow | deny | ask File/resource read access
write allow | deny | ask File/resource write access
execute allow | deny | ask Process/command execution
delegate allow | deny | ask Spawning subagents
network allow | deny | ask Network/HTTP access

review_models is an optional field on any agent block. It nominates one or more alternative models as independent reviewer variants. Each nominated model is materialized as a first-class agent descriptor (named {agent}-{model}, with / replaced by -) whenever config is loaded or composed.

agent warp {
description "Warp (Security Reviewer)"
prompt_file "warp.md"
models ["claude-sonnet-4-5"]
mode subagent
review_models ["openai/gpt-4o", "anthropic/claude-opus-4-5"]
}

Key behaviors:

  • One read-only review variant descriptor is generated per entry, named {agent}-{model} with / replaced by - (e.g. warp-openai-gpt-4o, warp-anthropic-claude-opus-4-5).
  • Variant routing is available whenever Loom/Tapestry prompts are composed with review variants in delegation targets.
  • Partial failures (some variants fail) are logged as warnings; the step still completes from the successful variants.
  • All variants failing causes the step to fail and transition to the on_reject action.
  • Builtin agents omit review_models by default; users opt in explicitly to avoid unexpected cost.

Categories define domain routing (glob patterns that direct work to specialized shuttle agents). Each category automatically generates a shuttle-{name} agent descriptor that inherits from the base shuttle agent with category-specific overrides.

See the Categories and Delegation guide for detailed information about delegation topology and routing rules.

category backend {
description "Backend APIs, services, persistence"
models ["anthropic/claude-sonnet-4-5"]
patterns ["src/api/**", "src/server/**", "src/db/**", "**/*.go"]
prompt_append "Focus on API contracts, data integrity, and backwards compatibility."
temperature 0.2
tool_policy {
read allow
write allow
delegate deny
}
}
category frontend {
description "Frontend UI, styling, accessibility"
models ["openai/gpt-5"]
patterns ["src/components/**", "src/pages/**", "**/*.tsx", "**/*.css"]
prompt_append "Preserve accessibility, responsive behavior, and design-system consistency."
}
Field Type Description
description string Human-readable label
models string[] Model preference list for this category’s shuttle agent
patterns string[] Glob patterns that route files to this category
prompt_append string Text appended to the base shuttle prompt for this category
prompt_append_file string File path appended to the base shuttle prompt
temperature number Temperature hint for this category’s shuttle agent
variant string Free-form string for model variant selection, passed through to the generated shuttle agent.
tool_policy block Tool policy overrides for this category’s shuttle agent

Generated shuttle agent names follow the pattern shuttle-{category-name} (e.g. shuttle-backend, shuttle-frontend).

Workflows define multi-step execution pipelines with agents, completion conditions, and artifact passing.

Usage model: Workflows are explicit, user-invoked constructs. They are not the default path for ordinary Weave usage. Ordinary usage is Loom-led: Loom handles conversational triage, delegates bounded tasks to Shuttle, and asks Pattern to create a plan when needed. A workflow begins only when a user explicitly invokes one (e.g. via /weave:start or an equivalent adapter command).

See the Workflows guide for detailed information about workflow execution, step types, and artifact passing.

workflow secure-feature {
description "Plan, implement, build, and review a feature with security audit"
version 1
step plan {
name "Create implementation plan"
type autonomous
agent pattern
prompt "Create a detailed implementation plan for: {{instance.goal}}"
completion plan_created {
plan_name "{{instance.slug}}"
}
outputs [
{ name "plan_path" description "Path to the generated plan file" }
]
}
step review-plan {
name "Review the plan"
type interactive
agent shuttle
prompt "Review the plan at {{artifacts.plan_path}} for: {{instance.goal}}"
completion user_confirm
}
step implement {
name "Execute the plan"
type autonomous
agent shuttle
prompt "Execute the plan at {{artifacts.plan_path}} for: {{instance.goal}}"
completion plan_complete {
plan_name "{{instance.slug}}"
}
inputs [
{ name "plan_path" description "Path to the plan to execute" }
]
}
step security-review {
name "Security audit"
type gate
agent warp
prompt "Perform a security audit of all changes for: {{instance.goal}}"
completion review_verdict
on_reject pause
}
}
Field Type Description
description string Human-readable workflow label
version number Schema version for migration compatibility
step named block One or more step declarations (see below)
Field Type Description
name string Display name for the step
display_name string Human-readable display name for the step. In DSL syntax, the block name becomes name and the inner name property becomes display_name.
type autonomous | interactive | gate Step execution mode
agent identifier Agent to execute this step
prompt string Prompt template for this step. Supports {{instance.*}} and {{artifacts.*}} placeholders.
role planning Optional step role hint. Currently only "planning" is supported.
completion identifier or block Completion method. See Completion Methods below.
on_reject pause | fail | retry Action when a gate step rejects. pause halts execution for user intervention, fail terminates the workflow, retry re-runs the step.
prompt_append string Inline text appended after the step’s primary prompt. Mutually exclusive with prompt_append_file.
prompt_append_file string Path to a file appended after the step’s primary prompt. Mutually exclusive with prompt_append.
inputs array Artifact inputs consumed by this step: { name "..." description "..." }
outputs array Artifact outputs produced by this step: { name "..." description "..." }
Type Meaning
autonomous Agent works alone without user intervention
interactive User can intervene during execution
gate Approve/reject checkpoint; execution pauses for a verdict
Method Syntax Meaning
agent_signal bare Agent emits a completion signal
user_confirm bare User explicitly confirms completion
plan_created block with plan_name A plan file was created at the given path
plan_complete block with plan_name A plan file was fully executed
review_verdict bare A gate agent emits approve or reject

When a project or global config declares a workflow with the same name as a builtin (or lower-priority) workflow and sets extends, the merge engine applies step-aware merge instead of the generic deep-merge.

workflow plan-and-execute {
extends "plan-and-execute" # name of the base workflow
version 1
# Insert a new step before an existing one
step spec {
name "Write spec"
type autonomous
agent pattern
prompt "Write a spec for: {{instance.goal}}"
completion agent_signal
insert_before "plan"
}
# Replace an existing step by same name
step implement {
name "Execute the plan (custom)"
type autonomous
agent shuttle
prompt "Custom implementation prompt"
completion plan_complete { plan_name "{{instance.slug}}" }
}
}

Step-aware merge algorithm:

  1. Resolve base steps (if extends equals the workflow’s own name, the base steps come from the lower-priority layer)
  2. Same-name replacement (override steps whose name matches a base step replace the base step in place, preserving position)
  3. Anchored insertion (remaining override steps with insert_before or insert_after are inserted at the resolved index relative to the post-replacement step list)
  4. Append (remaining override steps with no anchor and no same-name match are appended to the end)

The extend before-plan directive inserts steps into the before-plan slot of any workflow that publishes extension_points { before-plan }. It is a composition directive (separate from the extension_points { before-plan } publication syntax inside a workflow block).

extend before-plan ["write-spec", "review-spec"]

v1 contract: there is exactly one global before-plan bucket (no per-workflow targeting). The config layer applies the step list to every workflow that publishes extension_points { before-plan }. Multiple extend before-plan directives in the same config are union-merged into a single ordered step list.

Constraint Detail
Step names Must be non-empty strings matching declared step block identifiers
At least one step An empty step list is rejected at validation time
Global scope Applied to all workflows that publish before-plan; no per-workflow targeting in v1
Union-merge Multiple directives accumulate steps in declaration order
disable agents ["warp", "spindle"]
disable hooks ["on-session-idle"]
disable skills ["tdd"]
settings {
log_level INFO
}
continuation {
recovery {
compaction true
}
idle {
enabled true
work true
workflow true
}
}
analytics {
enabled true
use_fingerprint false
}
Form Effect
disable agents ["name", ...] Exclude named agents from materialization
disable hooks ["name", ...] Disable named lifecycle hooks
disable skills ["name", ...] Disable named skills globally
Field Values Description
log_level TRACE | DEBUG | INFO | WARN | ERROR | FATAL Runtime log level
runtime.journal.strict boolean Enable strict journal write mode. When false (default), journal write failures are best-effort warnings. When true, journal write failures are hard errors.

Controls session recovery and idle behavior.

Field Type Description
recovery.compaction boolean Enable context compaction on recovery
idle.enabled boolean Enable idle detection
idle.work boolean Resume work on idle
idle.workflow boolean Resume workflow on idle
Field Type Description
enabled boolean Enable analytics collection
use_fingerprint boolean Include device fingerprint in analytics

Every prompt, prompt_file, prompt_append, and prompt_append_file value is a Prompt Template rendered by the engine with Mustache before adapters receive the final composed prompt.

See the Prompt Composition guide for detailed information about template syntax, context fields, and delegation rendering.

You are {{agent.name}}.
{{#delegation.targets}}
- **{{name}}**{{#description}} — {{description}}{{/description}}
{{/delegation.targets}}
Path Type Description
{{agent.name}} string Logical agent name
{{agent.description}} string? Agent description
{{agent.mode}} primary|subagent|all Adapter-facing mode hint
{{agent.skills}} string[] Declared skill names
{{agent.isCategory}} boolean true for category shuttle agents
{{category.name}} string? Category name (category shuttles only)
{{category.description}} string? Category description (category shuttles only)
{{toolPolicy.effective.read}} allow|deny|ask Resolved read permission
{{toolPolicy.effective.write}} allow|deny|ask Resolved write permission
{{toolPolicy.effective.execute}} allow|deny|ask Resolved execute permission
{{toolPolicy.effective.delegate}} allow|deny|ask Resolved delegate permission
{{toolPolicy.effective.network}} allow|deny|ask Resolved network permission
{{{delegation.section}}} string? Full ## Delegation Markdown block with Mermaid diagram and bullets
{{{delegation.mermaid}}} string? Mermaid diagram block only
{{#delegation.targets}} array Iterate over eligible delegation targets
{{name}} string Target agent name (inside delegation.targets)
{{description}} string? Target description (inside delegation.targets)
{{domains}} string[] Deduplicated trigger domains (inside delegation.targets)
{{#triggers}} array Iterate over triggers (inside delegation.targets)

Partials ({{> footer}}), delimiter changes, helpers, and lambdas are rejected at composition time with a typed PromptTemplateError.

agent shuttle {
description "Shuttle (Domain Specialist)"
prompt_file "shuttle.md"
models ["claude-sonnet-4-5", "gpt-4o"]
mode subagent
temperature 0.2
variant "preview"
tool_policy {
read allow
write allow
execute allow
delegate deny
network ask
}
triggers [
{ domain "Implementation" trigger "Focused code changes" routing_hint "Use for bounded, file-scoped work" }
{ domain "Testing" trigger "Test writing and debugging" routing_hint "Use when tests need to be written or fixed" }
]
skills ["tdd", "code-review"]
}
category backend {
description "Backend APIs, services, persistence"
models ["anthropic/claude-sonnet-4-5"]
patterns ["src/api/**", "src/server/**", "src/db/**", "**/*.go"]
prompt_append """
Focus on:
- API contracts and backwards compatibility
- Data integrity and validation
- Error handling and logging
- Performance and scalability
"""
temperature 0.2
tool_policy {
read allow
write allow
execute allow
delegate deny
network deny
}
}
workflow feature-with-review {
description "Plan, implement, test, and review a feature"
version 1
step plan {
name "Create implementation plan"
type autonomous
agent pattern
prompt "Create a detailed implementation plan for: {{instance.goal}}"
completion plan_created {
plan_name "{{instance.slug}}"
}
outputs [
{ name "plan_path" description "Path to the generated plan file" }
]
}
step implement {
name "Execute the plan"
type autonomous
agent shuttle
prompt "Execute the plan at {{artifacts.plan_path}} for: {{instance.goal}}"
completion plan_complete {
plan_name "{{instance.slug}}"
}
inputs [
{ name "plan_path" description "Path to the plan to execute" }
]
}
step test {
name "Run tests"
type autonomous
agent shuttle
prompt "Run all tests and verify they pass for: {{instance.goal}}"
completion agent_signal
}
step review {
name "Code review"
type gate
agent weft
prompt "Review all changes for: {{instance.goal}}"
completion review_verdict
on_reject pause
}
}
# Disable specific agents
disable agents ["spindle", "warp"]
# Disable specific skills
disable skills ["experimental-feature"]
# Configure logging
settings {
log_level DEBUG
}
# Configure session continuation
continuation {
recovery {
compaction true
}
idle {
enabled true
work true
workflow false
}
}
# Configure analytics
analytics {
enabled false
use_fingerprint false
}
  • Readable (non-programmers should be able to read and roughly understand a config)
  • Declarative (describes what, not how; no control flow, no functions, no imports)
  • Block-structured (keyword name { ... } for named blocks; flat key value for scalars)
  • Minimal punctuation (no semicolons, no trailing commas, no colons for key-value pairs)
  • Comments (# line comments only)
  • Strings (double-quoted; multi-line strings use triple-quote """ ... """)
  • Arrays (["item1", "item2"] for familiarity)
  • Booleans (bare true / false)
  • Enums (bare identifiers for fixed value sets: allow, deny, ask, primary, subagent)
  • Numbers (bare numeric literals)