Configuration

Library and chains

The sections of library.yaml, the keys a library task takes for each kind, and how chains/*.yaml files compose them into chain templates.

library.yaml defines reusable components, and each chains/*.yaml file composes them into a chain template. Chain file keys defines every key a chain or a library component takes; this page maps the files.

`library.yaml`: reusable components

library.yaml has four sections. Each maps a name to a definition, which any chain takes with extends: <name>.

config/library.yaml

tasks:
  implementer:
    kind: agent
    harness: claude
    profile: strong
    prompt: Implement the approved plan.
  code_review:
    kind: agent
    harness: claude
    prompt: Review this work item's change for defects its passing tests do not catch.
    skill: kraft:code-review
    inputs: [review_package]

Section	Holds
`tasks`	Reusable tasks of any kind: `agent`, `subprocess`, `builtin`, `forge`.
`steps`	Reusable ordered groups of tasks. A step may set `read_only: true` (read_only).
`nodes`	Reusable nodes, with their own steps, `on_failure`, `fix_loop` and `escalation`.
`steering`	Named guidance (a steering profile), `{instructions: "..."}`, that an agent task selects with `steering: [name]` and a repository selects with its `repos.yaml` `steering:`.

Keys of a library task

Every kind takes scope, steering, on_failure, policy, skippable and icon. Then each kind takes its own keys. A library step or node may set an icon too (Icons).

Kind	Its own keys
`agent`	`harness`, `prompt`, `skill`, `produces`, `profile`, `model`, `effort`, `fallback`, `inputs`
`subprocess`	`command`
`builtin`	`ref`, `execution`
`forge`	`target`, `wait`

Chain file keys defines each key.

Extending a library step

A chain step extends a library step inside a node's steps:. The chain step names its own id. Its tasks come from the library step unless it sets tasks: of its own, which replace them. A component extends one parent of its own kind; the rest of the rule is in The library and extends.

config/library.yaml

steps:
  checks:
    tasks:
      - id: lint
        kind: subprocess
        command: just lint

config/chains/mine.yaml

nodes:
  - id: verify
    kind: exec
    steps:
      - id: checks
        extends: checks   # runs verify.checks.lint

Inspect and edit the library

kraft admin templates library lists every component as <section>.<name> (tasks.implementer) with the chains that use it.
kraft admin templates library ID shows one component with its definition and any lint issue that names it.
Templates › Library shows the same and edits the file. Kraft refuses a save that would break any chain that loads today, and writes nothing.

Qualified names

An installed Kraft add-on adds its own components and chains beside yours. Each is named <namespace>:<name>, where the namespace is the add-on's name or the alias it was installed under.

config/chains/mine.yaml

nodes:
  - id: implementation
    kind: exec
    tasks:
      - id: implement
        extends: release:implementer   # the add-on's task

extends, steering, skill and profile take a qualified name. So does a chain id wherever one is named: --chain, default_chain in repos.yaml, a schedule's chain.
A bare name is always your own. A key of library.yaml and a chain's id never contain :, and Kraft refuses one that does.
An add-on's components and chains are read-only. Extend one, or copy it with Copy to my library on the Templates screens.
kraft admin templates library lists an add-on's component with its add-on, as tasks.release:implementer (release@acme 1.0.0), and kraft admin templates show release:ship heads the chain the same way.
kraft admin templates lint --dir PATH loads no add-on. It prints each reference to one as not checked (add-on) and does not count it as an error.

Names has the whole rule, including what a bare name means inside an add-on.

`chains/*.yaml`: chain templates

Each file in chains/ is one selectable chain, named by its id (or the file name), with an optional one-line description. The keys are in Chain file keys. Concepts walks through the shipped default and quick-task chains as worked examples.

kraft admin templates show ID --resolved prints a chain with its library components expanded.
Templates › Chains edits the file itself.

Kraft never overwrites these files on upgrade.

Write your own chain: add a node with a command task, a fix loop and a judge.
Upgrade your configuration: take what a new release ships.
Chain file keys: every key of a node, step and task.
Add-ons and collections: components and chains an installed add-on adds.

Edit this pageorReport an issue

policy.yaml

Every field in policy.yaml: caps, budget, concurrency, archiving, defaults and maxima, and the policy fields a layer may set.

harnesses.yaml

Every field in harnesses.yaml: the harnesses section (harness profiles) and the profiles section (agent profiles).