| name | publish |
| description | Publish a previewed Rubicon programming write batch via programming_write_publish using the confirmationToken from the preview step. Use this as stage 4 (final) of the Rubicon programming pipeline, after the coach has explicitly approved the preview. |
Publish
Stage 4 of 4 in the Rubicon coach programming pipeline:
sheet-read → programming-inference → preview → publish
Input: the exact same operation batch that was sent to
programming_write_dry_run in preview, plus the confirmationToken that
call returned. Output: the operations are actually written to Rubicon.
Before you call this
Do not run this skill unless:
- The coach has seen the
preview output and explicitly said to proceed
(e.g. "publish it", "looks good, go ahead" — not just silence).
- You still have the exact operation batch and
confirmationToken from
that specific preview run. If any time has passed, the coach asked for
changes, or you're unsure the batch is identical, go back to
programming-inference → preview and get a fresh token rather than
reusing an old one.
What to do
- Call the Coach MCP Surface tool
programming_write_publish with:
- the same operations array used in the matching
programming_write_dry_run
call, unmodified
- the
confirmationToken from that dry run
programming_write_publish requires the programming:admin OAuth
scope. In practice this is satisfied because the coach's Rubicon account
already holds the coach role — canPublishProgramming checks the
authenticated user's role, not how the OAuth client itself was
provisioned. Ordinary Codex OAuth dynamic client registration + the
coach's own login + consent is sufficient. No special client
provisioning or pre-approval step is needed beyond the coach
authenticating as themselves.- Server-side safety gate: the server recomputes the expected token
from the exact operation set + requester + track slug and rejects the
publish if it doesn't match the supplied
confirmationToken. This
plugin does not implement or duplicate that check — it's an existing
hard gate on the Rubicon side. If publish is rejected for a token
mismatch, do not retry with a stale token; restart from
programming-inference with the corrected operations and get a fresh
preview.
- Report the result back to the coach in plain terms: what was created vs.
patched, and a link/reference to view it in Rubicon if the tool response
includes one. If the call fails, surface the raw error — don't
paraphrase it into something reassuring.
After publish
This is the end of the pipeline for this batch. If the coach has more rows
to bring in (e.g. the next week, or the batch was split because of the
25-operation cap), start a fresh cycle at sheet-read or
programming-inference as appropriate — don't chain another publish off
this same token.
