dorfl
It Claims Its Own Work

A small CLI that discovers, schedules, and runs work across many repos, autonomously and as a guided human loop, on a file-based work/ contract with an atomic git-ref claim protocol. Folders hold the durable status, lock refs hold the live one. No database.

Words In The Heart Can Not Be Taken

What it is

Four jobs, one tireless golem: discover, schedule, claim, run.

>_

Discovers

Point Dorfl at your repos. It finds the ones participating in the file-based work/ contract and surveys what is ready to build.

>_

Schedules

Ready tasks are picked and ordered across many repos at once, as a guided human loop or as an unattended autonomous runner.

>_

Claims

Claiming a task acquires its own per-item lock ref with a single create-only push. First to create it wins; the loser is told no. No coordination server, no lock table.

>_

Runs

Each claimed task is built in its own isolated worktree, taken to a green acceptance gate, and integrated. Then Dorfl moves on.

How it works

No coordination server, no shared index. Git refs and folders do the bookkeeping.

01

Durable status is the folder

Every work item is one markdown file, on a Kanban board of folders (tasks: backlog → todo → done). Its resting status is the folder it lives in, never a field. No database to keep in sync.

02

Claiming is a lock ref

Claiming a task acquires a per-item lock ref, not a file move: a create-only push that is self-arbitrating, with no retry budget. The task stays in the pool, so a worker can even claim on a protected main.

03

Build, verify, integrate

A worker builds the task on a work/<slug> branch, runs the acceptance gate, and proposes or merges. Conflicts rebase-or-abort, never auto-resolve.

Get started

Dorfl comes in three layers, in this order. Adopt the contract with a skill; that gives you the file-based work/ substrate; then the CLI executes against it. Adopt is a skill, execute is a command.

01

Adopt the contract (a skill)

The front door. Install the dorfl skills, then point your agent at from-idea (from scratch) or setup (an existing repo). Runner-agnostic — nothing to install globally; the skills go in via npx dorfl, and adopting the contract needs no dorfl runtime.

# install the dorfl skills into your agent (no install needed — run via npx)
npx dorfl skills add
# (or install the CLI once — `npm install -g dorfl` — then `dorfl skills add`)

# then, in your agent:
from-idea   # from scratch: idea → scaffolded work/-contract repo + spec
setup       # existing repo: onboard onto the work/ contract
02

The work/ contract, versioned with your code

What adoption gives you: a durable, file-based substrate the CLI later consumes. One markdown file per item; status is the folder it lives in, never a field. No database.

# what setup / from-idea scaffold into your repo
work/
  tasks/       # backlog/ → ready/ → done/ (+ cancelled/)
  specs/       # proposed/ → ready/ → tasked/ (+ dropped/)
  notes/       # ideas / observations / findings — capture buckets
  protocol/   # vendored WORK-CONTRACT.md, ADR-FORMAT.md, templates
dorfl.json   # the per-repo acceptance gate (verify / prepare) + the pinned dorfl (dorflCmd)
03

Execute (the CLI) & CI

Once the contract is in place, the CLI is the runner that consumes it. Use dorfl do in one repo, or dorfl run across many. In CI, dorfl intake is the issue → spec/task front door.

# install the runner
npm install -g dorfl

# register a repo and let Dorfl pick a ready task
dorfl remote add <url>
dorfl do            # one repo, in place
dorfl run           # across every registered repo, in parallel

# CI: turn an issue into a spec or task
dorfl intake

Full docs and the work/ contract live in the repository.