BUILD YOUR PROCESS

AI writable.
Human readable.

Tell your agent how you want the work to happen. Keep the answer in a workflow file you can read, review, and run again.

Start with the included software development flow. Change the YAML when your process needs to change. The engine, workers, and work records are already there.

See the YAMLWrite your own plugin →
THE RULE / THE HANDOFF IT CONTROLS
.weft/process.yaml · excerpt
gate_bindings:
  - transition: {from: in_progress, to: completed}
    gate: verification
    auto: true
  1. 01 / AGENTImplement
  2. 02 / REQUIRED GATEBuild + testverification
  3. 03 / AFTER IT PASSESCompleted

The binding names an included executable check. The workflow file says where it must pass.

Complete the task only after the check passes.
  1. 01

    Use the included flow.

    Run a small change before customizing anything.

  2. 02

    Edit the workflow.

    Change stages, handoffs, and required checks in YAML.

  3. 03

    Write a plugin if you need one.

    Supply new tools, checks, or domain capabilities.

A SMALL CHANGE TO THE PROCESS

Docs changed?
Check them before moving on.

The first rule runs repository build and test verification before the task enters completed. Add a second binding to require the included generated-document check on that same handoff.

Both gates must pass. auto: true keeps this handoff under the runner’s checks; an agent cannot simply mark it completed.

This example uses checks supplied by the local software development plugin. Connect your repository’s build and test commands when setting up verification.

.weft/process.yaml · gate_bindings excerpt

gate_bindings:
  - transition: {from: in_progress, to: completed}
    gate: verification
    auto: true
+ ADD THE DOCUMENT CHECK
  - transition: {from: in_progress, to: completed}
    gate: docs_current
    auto: true

Also declare docs_current: {} under gates. The complete file below includes both.

OPEN THE WHOLE FILE

No new service to build.

Save the example as .weft/process.yaml in a configured Weft OSS project. Inspect its definition with weft workflow show before dispatching work.

Download the YAML ↓
Read the complete workflow
process:
  name: checked-change
  version: "1.0"
  description: A small change with repository verification

states:
  - name: todo
    claimable: true
    claim_target: claimed
  - name: claimed
  - name: in_progress
    executor_action: implement
  - name: completed
    terminal: true
    terminal_kind: success
  - name: cancelled
    terminal: true
    terminal_kind: failure

initial: todo
transitions:
  - from: todo
    to: [claimed, cancelled]
  - from: claimed
    to: [in_progress, cancelled]
  - from: in_progress
    to: [completed, cancelled]
universal_transitions: [cancelled]

gate_bindings:
  - transition: {from: in_progress, to: completed}
    gate: verification
    auto: true
  - transition: {from: in_progress, to: completed}
    gate: docs_current
    auto: true

preconditions: []
gates:
  verification: {}
  docs_current: {}
params:
  claim_timeout: 60m
  max_attempts: 2
  poison_task_escalation: false

A small custom workflow, rather than the complete included SDLC flow. Your project definition takes precedence for the next dispatch; a running task keeps the definition it started with.

A PROCESS YOU CAN KEEP IMPROVING

The workflow belongs
in the review, too.

Commit the YAML beside your code. Read the diff when a check changes. Inspect task outcomes, adjust the definition, and reuse it.

Stages can also declare an execution engine, model, and session relationship. Your agent can help write those settings for the execution mode you use.

Engine and session settings →

Thinking of Kubernetes?

The familiar part is the declarative file: version it, review it, and let an engine interpret it. Here, you describe the stages and checks of a work process.

A CHANGE YOU CAN REVIEW
−Implement → Verify
+Implement → Verify + docs
COMMIT THE DEFINITION“Require current docs before verification.”The next task uses the revised process.
Commit the definition. The next task uses the revision.

WHEN YOUR WORK NEEDS SOMETHING NEW

Your own plugin.
Your own kind of work.

Software development is the included plugin. The engine itself runs workflows; plugins supply the tools and domain capabilities around them.

A gate can be as simple as calling a CLI tool or a shell script you already use. For a new check, your coding agent can write the plugin wrapper that runs it and reports the result.

You can write and run your own plugins locally. No Cloud subscription or plugin purchase is required.

Open the plugin authoring guide →
DEFINE THE PROCESS / SUPPLY THE CAPABILITY
YOUR WORKFLOW YAMLWhen should the check run?

Bind a gate to a transition.

YOUR PLUGINWhat does the check do?

Run your CLI or script. Return the result.

WEFT ENGINERun the process.

Call the provider and enforce the result.

The engine calls the provider and enforces the result.

TAKE THE NEXT STEP

Start small. Keep the useful parts.

Use the included flow for your first task, or open the authoring guide if you already know the process you want.

Follow a first task →Read the workflow authoring guide →Local OSS or shared Cloud state? →