DSL Configuration
Complete guide to the Weave DSL configuration language
DSL Configuration
Section titled “DSL Configuration”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.
Configuration Locations
Section titled “Configuration Locations”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 |
Directory Layout
Section titled “Directory Layout”~/.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.
Merge Behavior
Section titled “Merge Behavior”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 │└─────────────────────────────────────────────────────────────┘Merge Rules
Section titled “Merge Rules”| 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) |
Override Example
Section titled “Override Example”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.
Concrete Merge Example
Section titled “Concrete Merge Example”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 }}Syntax Conventions
Section titled “Syntax Conventions”| 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) |
Example
Section titled “Example”# This is a commentagent 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
Section titled “Agents”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 promptagent my-helper { prompt "You are a helpful assistant that answers questions concisely." models ["claude-sonnet-4-5"] mode subagent temperature 0.3}Agent Fields
Section titled “Agent Fields”| 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. |
Tool Policy
Section titled “Tool Policy”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
Section titled “Review Models”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_rejectaction. - Builtin agents omit
review_modelsby default; users opt in explicitly to avoid unexpected cost.
Categories
Section titled “Categories”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."}Category Fields
Section titled “Category Fields”| 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
Section titled “Workflows”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 }}Workflow Fields
Section titled “Workflow Fields”| 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) |
Step Fields
Section titled “Step Fields”| 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 "..." } |
Step Types
Section titled “Step Types”| Type | Meaning |
|---|---|
autonomous |
Agent works alone without user intervention |
interactive |
User can intervene during execution |
gate |
Approve/reject checkpoint; execution pauses for a verdict |
Completion Methods
Section titled “Completion Methods”| 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 |
Workflow Extension
Section titled “Workflow Extension”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:
- Resolve base steps (if
extendsequals the workflow’s own name, the base steps come from the lower-priority layer) - Same-name replacement (override steps whose
namematches a base step replace the base step in place, preserving position) - Anchored insertion (remaining override steps with
insert_beforeorinsert_afterare inserted at the resolved index relative to the post-replacement step list) - Append (remaining override steps with no anchor and no same-name match are appended to the end)
extend before-plan Directive
Section titled “extend before-plan Directive”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 |
Settings and Disables
Section titled “Settings and Disables”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}disable Directives
Section titled “disable Directives”| Form | Effect |
|---|---|
disable agents ["name", ...] |
Exclude named agents from materialization |
disable hooks ["name", ...] |
Disable named lifecycle hooks |
disable skills ["name", ...] |
Disable named skills globally |
settings Block
Section titled “settings Block”| 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. |
continuation Block
Section titled “continuation Block”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 |
analytics Block
Section titled “analytics Block”| Field | Type | Description |
|---|---|---|
enabled |
boolean | Enable analytics collection |
use_fingerprint |
boolean | Include device fingerprint in analytics |
Prompt Templates
Section titled “Prompt Templates”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}}Template Context Fields
Section titled “Template Context Fields”| 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) |
Unsupported Features
Section titled “Unsupported Features”Partials ({{> footer}}), delimiter changes, helpers, and lambdas are rejected at composition time with a typed PromptTemplateError.
Complete Examples
Section titled “Complete Examples”Agent with Full Configuration
Section titled “Agent with Full Configuration”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 with Overrides
Section titled “Category with Overrides”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 with Multiple Steps
Section titled “Workflow with Multiple Steps”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 }}Settings and Disables
Section titled “Settings and Disables”# Disable specific agentsdisable agents ["spindle", "warp"]
# Disable specific skillsdisable skills ["experimental-feature"]
# Configure loggingsettings { log_level DEBUG}
# Configure session continuationcontinuation { recovery { compaction true } idle { enabled true work true workflow false }}
# Configure analyticsanalytics { enabled false use_fingerprint false}Design Principles
Section titled “Design Principles”- 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; flatkey valuefor 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)