Examples — WOUF

Illustrated scenario

A project lead in an authority

A project lead in an authority runs a project with a phase-based method such as HERMES and wants its phases, results, decisions and dates in files anyone can follow, without writing code.

You
WOUF, draft our project plan from the documents in this folder: phases, results, decisions and dates. Show it to me before anything else.
WOUF · lead
I'll ask the worker to draft a plan and the review bot to check it.
WOUF · a question from the worker
What date should the plan use for the first decision?
You
March 3.
Done · worker and review
The reviewed draft is ready for you: a plan and decision notes in the task files.

An illustrated scenario, not a transcript: what the bots say depends on the model, your setup and your answers.

In the folder at the end

The plan and the decision notes, in the task files.
The board with the task and its state, a file you can open.
Team events and readable summaries can live in your Git repository, so you can follow the work over time.

Who took part

The lead, WOUF: talks to you, writes the brief and brings the questions to you.
The worker: drafts the plan.
The review bot: checks the result against the brief before it comes to you.

Where it runs

You decide where team, files and model run. No WOUF cloud, no WOUF server. Compliance depends on the model and how you run it.

A cloud agent CLI works through its provider's model API over the network: it sends content to that provider. A compatible local model can be configured with Codex, subject to your setup and model support.

What you must settle yourself

Which information the team may see at all, decided with your data protection and information security officers. WOUF has no classification of its own: what is in the folder and the briefs is what the bots can work with.
Where the folder, the bots and the model run, and what the chosen model provider processes and where. A local model setup is yours to verify.
Which network destinations are allowed: container mode, never host mode, and either no network or an allowlist you approved, including the model hosts each agent CLI adds.
Your own review of the setup, the model provider, the network rules and the stored logs. The review bot checks results against briefs; it does not check legal or data protection requirements.
The legal assessment, by someone with the right expertise. Data protection and sovereignty are goals your organisation sets and checks itself; WOUF does not ensure them on its own.
Where to begin: one low-risk use, such as drafting summaries of public documents, and more only after your review.

Where the bots run, in the docs

Illustrated scenario

A small team or club without tech

A club organises a summer fair with a venue, a few suppliers, invitations and a budget in a spreadsheet, and nobody on the team writes code.

You
WOUF, make a task list for the summer fair from the notes in this folder, and show it to me before anything else.
WOUF · lead
I'll have the worker prepare a task list and review check it.
WOUF · a question from the worker
Who should own the welcome desk?
You
Sam.
Done · worker and review
The reviewed task list is ready in the task files, with Sam as owner.
You
WOUF, remind me every Monday at 8 to check the supplier answers.
WOUF · lead
Reminders come up when you open a session, unless you set up a scheduler on your computer.

An illustrated scenario, not a transcript: what the bots say depends on the model, your setup and your answers.

In the folder at the end

The task list with Sam as owner, in the task files.
The board: the open items and their state, a file you can open.
The schedule with the Monday reminder, as a readable file.

Who took part

The lead, WOUF: talks to you and passes the question on.
The worker: prepares the task list.
The review bot: checks it before it comes to you.
Later, when you need one: the writer, one of the ready example bots.

What you must settle yourself

Sending stays your step. Ask for drafts, not actions: give the bots no mail account or other way to send, and send yourself.
The rules tell the bots that routine, reversible work goes ahead and every decision beyond that comes to you. These are instructions the models follow, not a lock.
Reminders come up when you open a session; for anything more, set up a scheduler on your computer.
You choose where to run your team and which available model service to use; WOUF does not require its own cloud or server.

Use it, in the docs

Illustrated scenario

A team in a company

A team of five in a company wants a shared agent team for internal documentation and small tools.

You
WOUF, draft a page of our internal documentation from the meeting notes in this folder.
WOUF · lead
I'll ask the worker to draft it and the review bot to check it.
WOUF · a question from the worker
Who approves the page before it is shared?
You
Mia, our team lead.
Done · worker and review
The reviewed draft is ready for you in the task files, with Mia as approver.

An illustrated scenario, not a transcript: what the bots say depends on the model, your setup and your answers.

In the folder at the end

The reviewed draft, in the task files.
The board, the decisions and the logs: files your team can review regularly.
With a second team: teams can exchange signed handoffs through a shared Git repository, without a dedicated WOUF server. What arrives is held until someone applies it.

Who took part

The lead, WOUF: talks to you and brings the question about the approval to you.
The worker: drafts the page.
The review bot: checks the result in a fresh context before it comes to you.
Later: more bots for recurring work, more runners, and token budgets per day or per run.

What you must settle yourself

Who owns the setup: one person or a small group who answers the questions and holds the keys.
Where the bots run, for example on a VM or server you control, so they do not run on a laptop.
Approvals: the team's rules say irreversible, outward, paid and new-access steps wait for a person. These are instructions to the models, so you enforce them by what you give the bots: no accounts, keys or access they could use for such a step on their own.
When to let the team decide more: only for reversible work, once you trust the results.
Which network hosts the work needs, after a trial run that shows which hosts the agent CLI really uses.
For the exchange: the peers, their keys and a shared Git repository both teams can reach.
Your company's own rules for the team, and keeping sensitive material out of the folder unless the setup is approved for it.

Make it yours, in the docs

Illustrated scenario

A developer

A developer maintains a small web application in a git repository with a test suite.

You
WOUF, fix the crash when the upload is empty, and run it as a flow.
WOUF · lead
I'll brief worker and ask review to check the change.
WOUF · a question from the worker
Should an empty upload be rejected?
You
Yes. And add the check for missing titles alongside it.
WOUF · lead
For a batch, WOUF checks that the tasks' declared file areas do not overlap before starting them together.
Done · worker and review
The reviewed changes and their tests are ready on their task branches for your decision.

An illustrated scenario, not a transcript: what the bots say depends on the model, your setup and your answers.

In the folder at the end

A task branch for each change, with the change and its test.
The review of the exact commit: approved, or the changes it asks for.
The board with both tasks and their state.

Who took part

The lead, WOUF: writes each brief with its class and its paths.
The worker: makes the change. With a sandboxed setup each bot works in its own workspace, separate from your project and home folders.
The review bot: checks the result in a fresh context and approves the exact commit, or asks for changes.
No bot, but a step before review: a configurable check can catch some increases in code complexity before review without an AI call.

What you must settle yourself

Which command runs your tests: it becomes the gate, so every change is tested before review. The shipped gate is empty; the complexity check runs only once you configure it as the gate.
A sandboxed setup: container mode with Docker or Podman, or bubblewrap. Host mode has no sandbox.
Which tasks really are independent: the batch check reads the declared paths and cannot prove semantic or external independence.
The merge. The flow and the merge proposal never merge, and the team's rules are instructions, not branch protection: set up protection for your main branch and required checks in your repository host, and do the merge yourself.

How it works, in the docs