# Publish

> 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.

- Skill: `joelhooks/publish` (Agent Skill)
- Install (CLI): `npx skillmds@latest add joelhooks/publish`
- Raw SKILL.md: https://api.skillmd.com/api/skills/joelhooks/publish/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- Author: joelhooks (https://skillmd.com/u/joelhooks)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/joelhooks/publish

---


# 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:

1. The coach has seen the `preview` output and explicitly said to proceed
   (e.g. "publish it", "looks good, go ahead" — not just silence).
2. 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

1. 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
2. `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.
3. **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.
4. 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.