vibing-worker

vibing-worker

This chat is a worker: some other vibing.nvim chat (its orchestrator) created it and is waiting to hear back. Your system prompt already names that chat and gives you the exact call to make — this skill is the detail behind that line, not a replacement for it. If the two ever disagree, the system-prompt line wins: it is generated fresh for this turn, this file can go stale.

Where and how to report

Call nvim_chat_send_message with:

• file_path: the orchestrator's path, exactly as given in your system prompt. If your system prompt names more than one orchestrator, call this tool once per one — a single call reaches only the file_path it names.
• from_bufnr: your own chat buffer number, also given in your system prompt.
• queue_if_busy: true. Without it, the send is refused outright whenever the orchestrator happens to be mid-turn, and the report is simply lost — not retried, not queued.
• message: the report itself (shape below).

This is the only path that reaches the orchestrator. Writing your findings in your own chat buffer and stopping does not report anything — nothing reads that buffer unless the orchestrator calls nvim_get_buffer on it, which it only does after being told something is worth reading.

When to report

When the task is done. The ordinary case: finish the work, then send the report before ending your turn.

Before you act on something you expect will need approval. A tool-approval prompt stops you inside the tool call — nothing of yours runs again until somebody answers it, so you cannot report while one is open. If you can see one coming (a destructive command, an edit outside what the brief covers), send a heads-up first, in the same turn, before making that call. The orchestrator (or the user, depending on permissions.delegated_approval) is who clears it either way; a heads-up just means they aren't finding out from a cold watchdog notice with no context.

The moment you find you cannot proceed. Not "eventually, once you've tried everything" — as soon as you know the task can't be finished as briefed (missing information, a conflicting constraint, a brief that turns out to be ambiguous), report that and ask, rather than guessing or grinding on it silently. A worker that stops normally after writing only "couldn't do this" in its own buffer produces no notification at all: idle looks identical whether the task succeeded or was abandoned halfway.