Content review and publication

This playbook reviews one authored draft against its brief, verifies factual assertions and customer permissions, collects editorial sign-off, and confirms that the exact approved revision is published at the destination. One run governs one content asset from draft intake through verified publication or formal deferral. It does not generate bulk marketing copy, orchestrate multi-channel advertising campaigns, or push unverified changes to public websites. If CMS API access or source documentation is unavailable, the agent flags the gap and works from exported drafts and manual publishing workflows.

• Look up existing intake records and content databases to confirm this draft is not already being processed under another active run or published under an existing asset identifier. If an active run or duplicate asset exists, reconcile the submission against the existing record or halt intake to avoid split reviews.
• Ingest the candidate draft, original brief, and supplied source notes from Google Docs or Notion. Extract the target audience, primary thesis, proposed canonical URL slug, and metadata descriptions. Confirm that the draft covers the intended scope without expanding into unapproved topics.
• Audit every empirical assertion, statistical metric, benchmark, and partner reference against the supplied research. Check whether numerical claims cite specific documentation or customer records. Where an assertion lacks verification or references private customer results without written consent, record the exact statement and citation gap.
• Information request. Ask the content author or subject-matter lead to supply the missing citation or written customer release for each flagged claim. Present the exact sentence, the unverified assertion, and the required evidence type. If the author provides the supporting record, attach it to the verification log and proceed. If the author removes or rewords the claim, verify the updated passage. If the author is unreachable or cannot substantiate the claim, the unverified claim cannot be published; an editor cannot waive required written customer permission or unverified factual claims merely by accepting a risk.
• Evaluate organic search positioning and internal linking against supplied Google Search Console notes and existing site taxonomy. Check that the proposed title, headers, and meta description align with target search queries without duplicating or cannibalizing existing published URLs. Verify that every outgoing link resolves to an active page and uses appropriate attribution tags.
• Assemble the editorial review packet containing the complete draft, diff against the brief, verified citation log, resolved claim permissions, and target destination settings. Where supported, stage the content in the target CMS—Ghost or Webflow—in private draft mode, capturing the preview link and target publish schedule; otherwise, provide the export draft and intended destination metadata.
• Approval. Present the editorial packet and preview link to the editorial lead. The reviewer inspects the text, positioning, and claim resolutions to choose: approve publication of the exact revision, destination, and schedule; request specific textual or structural changes; or decline publication. If changes are requested, return the draft to the author with the editor's notes; after revisions, recheck any modified claims or permissions and obtain renewed approval of the exact revision, destination, and schedule. Silence keeps the review pending. If publication is declined, move the run to Held or declined with the editor's documented rationale.
• Upon editorial approval, inspect the target CMS to check whether an asset with the approved slug or identifier already exists before publishing or scheduling. Stage or update the approved asset. If an external write fails or times out, inspect the current CMS state and effect before retrying.
• Exception. If an external write fails repeatedly, returns an authentication error, or renders layout discrepancies that break formatting, halt further automated modifications and notify the CMS administrator. Present the approved revision identifier, error details, and preview artifact. The administrator either resolves credentials, repairs formatting, or applies the approved markdown manually, providing read-back confirmation of the published post or recording an explicit owner deferral.
• Verify publication by fetching the live or scheduled post record from the target CMS. Compare normalized body text, headings, canonical URL, and open-graph metadata against the approved revision. For scheduled posts, confirm the verified scheduling state and keep the case pending until the live release is confirmed or owner deferral is recorded. If live content diverges from the approved text, do not unpublish or overwrite without authority; stop automated changes, preserve current effects, and alert the editorial lead for a repair or rollback decision. When the published content matches the approved revision, record the verified URL and close the run in Publication confirmed.
• In a fictional example, a product marketer submits an article titled "Scaling Postgres under Peak Workloads" citing a "42% latency reduction at Acme Corp" alongside benchmark metrics. During the claims audit, the agent finds internal benchmark documentation but no signed customer consent release to publish Acme Corp's name or proprietary workload figures. The agent issues an information request to the author. Because Acme Corp's legal sign-off cannot be obtained, and internal benchmarks cannot authorize releasing private customer results even under anonymization, the author removes the private customer claim entirely and replaces it with reproducible internal synthetic benchmark figures. The agent verifies the synthetic benchmark documentation and presents the revised draft to the editorial lead. The editorial lead grants renewed approval for the exact revision and Ghost destination. The agent publishes the post, inspects the live page to verify normalized text and canonical tags match the approved copy, and logs the verified URL in Publication confirmed.
• A run completes when the exact approved revision is verified live at the destination CMS, or when the draft is formally held or declined by editorial authority. A scheduled post, unverified write, or pending verification keeps the case awaiting confirmation.