marcosmodly/marketing-skill/publish-pipeline

Publish Pipeline

Purpose

Final handoff step: package finished content and any asset references into a structured JSON payload, then send it to the user's own automation system (n8n, Make, or anything else that accepts an incoming webhook) so it can take over scheduling and posting. By default this skill hands off to automation the user already owns rather than posting directly — direct platform posting exists only as an explicit, optional alternate path (see step 5) for users who've set up their own platform API credentials.

Step-by-step process

Plugin root: if a path below still shows an unexpanded CLAUDE_PLUGIN_ROOT placeholder (Claude Code fills it in; other agents such as Codex don't), resolve it before using any of them: take the output of printenv CLAUDE_PLUGIN_ROOT if it prints a path, otherwise walk up from this file's folder to the first folder that contains references/brand-voice.md, and if neither works, ask the user where this plugin lives. Use that absolute path in every file path and shell command below.

1. Check onboarding status. Read

${CLAUDE_PLUGIN_ROOT}/references/brand-voice.md. If it doesn't exist, or its first line is <!-- MARKETING-SKILL:UNCONFIGURED -->, ask the user this plugin's 4 setup questions (priority task; content types to produce; target audience + tone; default output format — same as /marketing-skill:marketing-setup) before continuing, then save the answers and flip the marker to CONFIGURED with today's date. If the file is unconfigured but the user already said to skip setup or use the defaults, don't ask: use its placeholder defaults for this run, say so in one line, and leave the marker as it is.

1. Confirm scope.

• Which content pieces are ready to send (from content-repurposer,

visual-brief-generator, short-form-video, clip-montage, montage-video, community-post-generator, a row in state/content-calendar.md, or pasted directly)?

• If the source is community-post-generator, confirm its Go/No-Go

section actually said go — never send a draft that skill flagged as blocked by the target community's own rules.

• If the user is pointing at a calendar entry (e.g. "send the queued

post for Tuesday"), read ${CLAUDE_PLUGIN_ROOT}/state/content-calendar.md, find the matching row, then read the post file named in that row's Notes column (state/posts/<date>-<platform-slug>.md) — that file, not the calendar table, holds the actual content to send. A row with no post-file path in Notes, or whose named file doesn't exist, isn't a usable source — say so and stop rather than improvising content from the short Topic/Hook label. Refuse to re-send a row already marked Sent without the user explicitly confirming they want to send it again.

• Destination webhook URL, if not already set via MARKETING_WEBHOOK_URL.
• Is this a real send, or a dry run to inspect the payload first?

1. Assemble the JSON payload using the exact structure below.

1. **Show a clear, human-readable confirmation before any real send —

never a raw JSON dump as the only thing shown — and get explicit user go-ahead. This step fires an external side effect the user may not be able to easily undo — never skip it, even if the original request sounded like blanket authorization (e.g. "just publish it"). Silence, a timeout, or no reply in this conversation is never a yes** — only an actual affirmative reply counts, and if none arrives, stop here without sending. This applies exactly the same way whether an interactive chat or something else (a scheduled or automated trigger) invoked this skill — there is no framing of "the run itself is standing authorization" that substitutes for a real reply.

• Single item: show four labeled lines before anything else —

Account (which identity this goes out as: the destination automation itself for a webhook handoff, e.g. "your n8n webhook," or the specific platform identity for a direct post, e.g. "dev.to — personal account, not the Organization" or "Instagram Business account linked to [Page]"), Destination (URL, subreddit, channel, or recipient), Attachments (each asset's type and source, or "none"), and Final Text (the actual post/message body, in full, not a summary) — then the JSON payload or script command underneath as the technical detail, not the primary thing being confirmed.

• Batch (more than one item ready at once): never loop through

items one at a time asking "send this? ... send this? ..." — that pattern gets a "yes" to everything without anyone actually reading past the first item or two. Instead list every ready item together, numbered, each with its own Account/Destination/Attachments/Final Text breakout, and require the reply to name specific numbers (e.g., "1 and 3, yes — skip 2") rather than accepting an unqualified "approve all"/"send them" with no numbers attached — treat an unqualified blanket reply to a numbered list the same as silence for any item it doesn't actually name. Cap a single batch at 10 items; if more than 10 are ready, present them in waves of 10 or fewer instead of one long list, so the format itself never invites skimming.

• Staleness. For any item sourced from a state/content-calendar.md

or state/outreach-log.md row, compare that row's Date to today. Flag anything more than 14 days old (7 days for an outreach-log row, since personalized prospect research ages faster) as Stale right in the listing, not in a separate report — a batch mixing fresh and stale items must show the flag per-row so it can't be missed inside a larger "yes to all." Don't refuse to send a stale item outright; just make its age impossible to approve past without seeing it.

• If the source is a state/content-calendar.md row, this is the

point where — and only where — its Status may move to Approved, immediately after the affirmative reply and immediately before sending, and only for the specific numbers actually named. No skill in this plugin sets Approved at any other time; content-calendar in particular never writes it.