Docs / Hand off work

Hand off your first piece of work

You don't fill in a form. You ask the coding agent you already use, in plain language, and it sets the work up for you.

Ask for it in plain language

Once your agent is connected, ask for the work the way you'd ask a colleague:

Your agent writes the brief, names the folder the work happens in, and either lets Oga choose the account and model or names one itself. The brief goes out as written, at whatever length the job needs — a sentence for a small job, more when there is more to say. You get an ID back as soon as the work starts. From there it runs on its own account, unattended.

Or straight from your shell

When you already know what you want done, you don't need to go through an agent. oga delegate starts the work and hands you its ID:

oga delegate "Port the CSV importer to the new parser and keep its tests green."

It runs in the folder you're standing in, on the account and model Oga picks. Name one yourself with --worker and --model, give it its own branch with --worktree, or point it at another folder with --cwd. Already know what kind of work this is? Say so with --kind, so a loved model for that kind isn't missed. Want a say in how hard the model thinks? Set --effort directly.

Pass - to take the brief from standard input, for when you've already written it down:

oga delegate - < brief.md

What's worth handing off

Handing off costs you a brief and a wait. It pays for itself on work with its own finish line — build this screen, port this module, review this branch, research this question. It doesn't pay for a rename, a typo, or a one-line change: by the time you've described those, you could have done them.

The same goes for anything you're standing over. Work you'd interrupt every two minutes belongs in your own session.

How the work gets written up

Whoever picks the work up can't see the conversation you had. Everything it needs — what to build, why, what you already worked out, what to leave alone — has to be in the write-up, and the write-up is all it gets.

Settings keeps your own instructions under Brief rules. They replace Oga's default wording; when no instructions are set, Oga's default wording applies. Use {{project}} to include the project folder path. The old {{default}} placeholder has been removed and now expands to nothing.

What it's allowed to touch

Every piece of work carries the area you approved: what it may read, and what it may change. Reading the whole folder and writing to one part of it is the usual shape.

• Naming a folder covers everything inside it.
• ** means the whole folder you're working in.
• A path that doesn't exist yet means only itself. If the work will create files under a new folder, write out/**, not out.

Approving an area once is enough — later work in the same project reuses it without asking again. The area is a permission, not a reading list; which files actually get opened is up to whoever does the work.

When the work needs something outside that area, such as a backup file in /tmp, it stops and asks you first. The question names the step and what it would reach. Allow it and the work carries on with that one step; refuse it and the work goes on without it. Or reply with what it should do instead, and it takes that as its next instruction. It waits as long as you need, and the time spent waiting doesn't count toward the task's time limit.

What it works with

Whoever does the work gets the tools you already connected for that project, alongside Oga's own. A database, a browser, an issue tracker — if your coding agent can reach it in that folder, so can the work you hand off.

Work stays where you send it: it can report back and ask, but it can't hand the job on to someone else. When a piece of work is big enough to need help, say so as you send it — ask your agent to let it hand work onward, and it gets to split the job up itself.

Who ends up doing it

Name nothing, and the work uses your default model when you set one. Otherwise Oga chooses from the workers and models you turned on — or, with Choosing a worker switched on, from the brief itself. Name a worker and model when the work needs a specific destination.

Naming a model, you can use the short name Settings shows instead of typing it in full, as long as it names only one model on that worker. A short name that could mean more than one is refused, listing the models it could mean, and a model you haven't switched on in Settings is always refused, however you asked for it.

A worker gets your brief, your project's memories, and Oga's commit attribution when it's enabled. Oga enforces the worker's file permissions without adding a scope section to the brief, and your brief says how it should report back. There is no separate worker prompt to maintain; Brief rules guide your agent as it writes the brief. The lookup understands Rust, Python, Go, PHP, Ruby, Java, Swift, C#, C, and C++ source.