An editorial calendar became two verified YouTube Community posts

Why a calendar was not enough

A small editorial team had a two-week plan, but YouTube's official Data API reference lists no Community post resource or creation method. In this workflow, publishing therefore used the signed-in web interface. That made identity, UI changes and proof of publication operational concerns, not implementation footnotes.

The goal was therefore precise: take each approved idea all the way to a verified publication, while preserving the review decisions and any failed attempt. A calendar could say what should go out and when. It could not, by itself, coordinate the checks, browser work, retry and final confirmation.

Open the official YouTube Data API reference →

What KittyClaw coordinated

KittyClaw separated preparation from publication without losing the connection between them. The editorial board held the original request and content plan. A second KittyClaw board acted as the publication queue: every ticket there represented one item to review, schedule, publish and verify. Rules controlled when a ticket could advance to the next column.

1. Freeze the content as data

The calendar referenced one JSON file per item. JSON is a simple structured text format used here to store the words, link and poll options. The submit command copied that content file into the publication project, so review and publication operated on the same version.

# Use the project and workspace selected during installation
YT_BOARD_PROJECT=my-publication-project \
YT_POSTS_DIR=/path/to/my-publication-workspace/posts \
node /path/to/yt-community-publisher/.agents/tools/yt-submit.mjs \
  --source my-project --ticket 1309 \
  --payload content/2026-07-16-teaser.json \
  --channel kalceo --at "2026-07-16 18:00" \
  --type teaser

2. Review before scheduling

The editorial review caught a relative-time phrase that no longer matched the scheduled content. “Tomorrow” was replaced with an explicit weekday in both the source file and the frozen copy in the publication project before the item advanced.

3. Apply cadence per channel

Each publication ticket checked for another item inside the configured 48-hour window for that channel. This was an explicit step to pass before scheduling. Both successful items passed it.

4. Verify the observable result

A successful browser action was not enough. The publication workflow recorded verification only after the content appeared as public in YouTube Studio. The teaser was verified on 16 July 2026; the poll was verified on 20 July 2026.

5. Return proof to the source

Each publication sent a confirmation back to the original editorial ticket. That confirmation included the publication ticket, time and public channel Posts URL. The original request could therefore distinguish “planned”, “attempted” and “verified”.

How the real story ended

The teaser passed review after one wording correction, then passed the spacing check and was verified as public. The first attempt to publish the poll stopped after a browser selector problem and a wrong active channel identity. KittyClaw kept the failed attempt visible. The team corrected the operating conditions, submitted the same planned item again and required it to pass the checks before it was verified as public.

This matters because the workflow did not confuse “the automation clicked a button” with “the audience can see the post”. The final state required an observable result and a confirmation in the original ticket.

How to do the same with KittyClaw

You need a KittyClaw project for editorial work, a second project for publication, a reviewed content file for every planned item and a browser runner already signed in to the intended YouTube channel. Keep cookies, session identifiers and browser-profile paths outside tickets and content files.

1. Build the two boards

On the editorial board, create one ticket for the calendar and attach or link every content file. The installer in the kit creates the publication board columns used by the real workflow: A valider for items waiting for checks, Programme for approved items waiting for their time, Publie for verified publications, Rejete for policy conflicts and Echec for publication failures.

2. Define the passage rules

• A valider to Programme: the content has already been reviewed, the channel is known and no publication falls inside the minimum spacing window.
• A valider to Rejete: a suspended category or spacing conflict is recorded with its reason.
• Programme to Publie: the planned time has arrived, links are reachable, the browser uses the expected channel and YouTube Studio shows the expected content as public. The publisher then returns the details to the original ticket.
• Programme to Echec: preserve the content and diagnostic, fix the cause, then submit it again. A temporary identity mismatch retries in Programme before becoming Echec.

3. Add the minimum policy

The reusable contract below tells the publication workflow which channel to use, when it may publish, which checks are mandatory and which proof must return to the editorial ticket. Store credentials separately. The content file should contain only information intended for publication.

{
  "channel": "replace-with-channel-key",
  "publicPostsUrl": "https://www.youtube.com/channel/REPLACE_ME/posts",
  "timezone": "Europe/Paris",
  "minimumSpacingHours": 48,
  "allowedLocalHours": [12, 17, 18],
  "gates": [
    "editorial-review",
    "factual-claims-sourced",
    "cadence-per-channel",
    "browser-identity",
    "studio-verification"
  ],
  "proof": {
    "callbackToSourceTicket": true,
    "fields": ["publisherTicket", "publishedAt", "verified", "publicPostsUrl"]
  }
}

4. Connect the submission step

First run install-workflow.mjs from the kit against a clean KittyClaw publication project. It creates the five columns and installs the validation and publication automations. The installer passes that project slug and its own posts directory to every processor, so the queue cannot silently fall back to another board. Then use the same two values with the supplied submission command to freeze the reviewed content and create its ticket in A valider. If your browser runner differs from the one used here, adapt only that integration while keeping the same states and proof rule.

5. Start from the kit

The bootstrap kit contains the installer, the exact workflow definition, the policy above, a two-week calendar, example post and poll files, the submission interface and a QA checklist. Install it in a clean publication project, replace the example channel values and test the route before authorizing publication.

What the evidence supports

Open the public channel Posts tab →

Limits and recovery

• The web interface is a dependency. A changed button or field can turn a working publication tool into a failed attempt. Capture evidence and make the failure visible.
• Browser identity is global state. Assert the active channel before opening the composer; abort and retry when it does not match.
• A channel page is weaker than a direct link to one post. Keep the Studio verification, a timestamped log and the confirmation returned to the original ticket.
• Publication is not validation of the content's claims. Any factual claim still needs its own primary-source review.
• Never archive authentication material. Exclude cookies, browser profiles, session identifiers and owner-only navigation from public evidence.

The failed first poll attempt shows an important limit: the workflow did not treat an automation click as success. It preserved the item, corrected the operating condition, submitted it again and required the same verification step.

Kit files and detailed evidence

Use these files to create the KittyClaw boards, content format, checks and recovery path described above. The examples intentionally contain no channel ID, cookie or session data.