Shared work, checkpoints and handoffs

Handing over a branch name hands over the code and leaves the reasoning on your laptop. Shared work hands over both: a Git checkpoint of what your session changed, with the decisions, dead ends and open blockers attached to it.

What sharing work does#

1. You choose a live session to share#

   It has to be your own session, still running, and not already shared. Shared work is a hand-over of work in flight, not an archive of a finished one.

2. Runi shows you the Git preview first#

   Before anything is pushed: the exact paths that will be committed, the base branch, the base commit, and a count of unrelated changes in your working tree that will not be included. You approve that, or you cancel.

3. The commit is assembled without touching your working state#

   Through a temporary index. Sharing work never switches your branch, never stages unrelated files, and never rewrites your existing index. Only paths the session recorded may enter it, and ignore rules apply here as everywhere else.

4. The handoff is published with the context attached#

   The commit, the task card, the decisions and their reasons, the approaches that failed, the open blockers, and the recorded next action. Your teammate gets the reasoning and the code as one thing.

A checkpoint is not your checkout#

This distinction causes more confusion than anything else in this part of the product, so Runi states it instead of hoping you infer it:

A shared checkpoint is what Runi observed on the author's machine. It is not in your checkout until you fetch it.

When your agent asks to continue a piece of shared work, the answer says whether that code is in this checkout yet. An agent that assumes it is will spend a turn confused about files that are not there.

Picking up shared work#

Two routes, for different moments.

In the app#

Shared work lists what has been handed to you or to the repository. Open it and you get the checkpoint, the reasoning and the next action in one place.

From inside your agent#

runi_continue is the tool written for this. It returns the card, where the work stands, the sessions that worked it including finished ones, the shared work and its checkpoint, whether that code is in this checkout, what it depends on, open blockers, failed approaches, decisions and their reasons, discoveries, verification, files touched, and the recorded next action.

It runs under a larger budget than a briefing, because it is the one answer meant to replace asking the author. Whatever the budget still cut is named by kind, so you know what you have not been told.

Branch names#

Runi suggests a branch in the handle/key-title shape, the one people already reach for and review tooling already parses. Names are sanitised to what Git will accept, and a name Git would refuse is caught before the work is created instead of at push time.

Handoffs are written by people#

No adapter generates a handoff. Every one is authored by the person whose session produced the work. Runi assembles what it already observed so writing one is nearly free, but the act of handing over is a human decision and stays one.

When to share work, and when not to#