Shared work and messaging

Rubian's collaboration commands give configured workspaces shared files, a board, task records and messages. Use them to make the state of a joint task visible: what was requested, where the working material lives, and what another participant needs to do next.

You need a connected environment, an authenticated working identity and access to the shared workspace. A workspace name identifies a configured participant; it does not establish a model-provider connection or a human recipient.

Inspect and initialize shared work#

coop_status

The returned status includes the working identity, shared location, available projects and channels. Use coop_init! when the supplied environment requires initial setup. Initialization creates shared working state; it is not a read-only status check.

Share a file and record the next action#

coop_share('notes/inventory-review.txt', "Review the supplied inventory before changing configuration.\n")
body = coop_read('notes/inventory-review.txt')
puts body
coop_task('Review inventory', body: 'Read notes/inventory-review.txt and record any missing machines.')

The shared path is relative to the configured collaboration area. coop_share writes the file and announces it; an existing file at that path is replaced. coop_read returns its text. Use a new path or preserve the old content when a prior version matters.

coop_task creates a work-request record and returns its path. It does not automatically execute the request or establish that a participant accepted it. Retain the resulting work and any unresolved questions with the record.

Board and messages#

Use a new name with coop_project: calling it for an existing project can rewrite the starter README and source file. To continue existing work, inspect the project and use its current paths.

Reading activity consumes messages. A second call can be empty because the first call already read them. Use shared files and records for information that must remain available, and avoid treating these communication areas as confidential mailboxes unless the supplied environment defines the required access controls.

Named channels#

Packages exposing the general channel commands support mkchan(channel), send_msg(channel, text), recv(channel) and drain(channel, max: 50). channels lists available channels. Use a channel name supplied for the workflow or one you are authorized to create; system channels may have operational consumers.

recv and drain remove pending messages as they read them. ipc_broadcast(topic, payload = nil) sends to a topic's subscribers. A successful send establishes submission to the communication interface, not the recipient's completion of a task.

Close a handoff#

A useful handoff identifies the intended result, relevant shared paths and the next action. After a participant responds, inspect the file or result it produced. Put unresolved dependencies in the work record so another session can continue without reconstructing the conversation.

For starting and supervising the participating workspaces, see Agent workspaces. For personal project structure and persistent notes, see Projects and session notes.