Cms Changelog Sync

CMS Changelog Sync

Push draft release notes to Strapi (release-notes content type). Docs changelog stays full; CMS uses committed staging with popup-sized copy.

Hard gate: Cloud push / publish (ask every time)

Whenever the user asks to push, sync, or publish to CMS (in any language), agents must:

1. Default to --project comfyui only. Do not run cms:sync / cms:publish / cms:preview for cloud in the same turn as the request.
2. Stop and ask a second confirmation about Cloud, even if the user already mentioned Cloud links, templates, or “push both”. Ask in plain language, for example:

   Should Cloud go to CMS this time as well? Please check Cloud staging (links and copy) yourself, then confirm. Until you confirm, I will only handle comfyui.

3. Run --project cloud for preview/sync/publish only after the user replies with an explicit yes for Cloud in this conversation turn chain (e.g. “yes, push Cloud”, “cloud too”). Linking shortlinks earlier, preparing staging, or saying “push to CMS” alone is not Cloud approval.
4. If unsure, ask again. Never infer Cloud approval from prior releases, PR text, or that Cloud staging already exists.

cms:prepare:en / cms:prepare:locales may still prepare both projects’ staging files. The gate applies to Strapi preview, push, and publish (cms:preview, cms:sync, cms:publish), not to local staging generation.

Write this skill and related CMS agent docs in English. Match the user’s language only when asking the confirmation question in chat.

Architecture

Three separate steps — stop for human review between each:

changelog/index.mdx                    ← docs source of truth (full EN)
        │
        ▼  Step 1: pnpm cms:prepare:en
staging/en/changelog/index.mdx         ← simplified popup EN → **review & approve**
        │
        ▼  Step 2: pnpm cms:prepare:locales
staging/{zh,ja,ko,fr,ru,es}/…          ← translated from staging EN → **review & approve**
        │
        ▼  Step 3: pnpm cms:preview / cms:sync -- --project comfyui  (only after user confirms)
Strapi CMS (draft) → manual Publish → published-versions.json

Never edit docs zh/changelog/ for CMS. Never auto-publish in Strapi. Never use pnpm translate for CMS — that pipeline is for Mintlify docs only.

Three-step workflow (local)

pnpm cms:prepare without --en-only / --translate-only prints help and exits — use the step-specific scripts above.

Translation workflow (CMS staging)

Step 2 only. Input = simplified EN staging, not docs changelog.

staging/en/changelog/index.mdx          ← input (Step 1 output, human-approved)
        │
        ▼  pnpm cms:prepare:locales -- v0.26.0
staging/zh|ja|ko|fr|ru|es/changelog/…   ← output (popup copy per locale, ready to sync)
        │
        ▼  pnpm cms:sync  (Step 3, after user confirms)
Strapi release-notes (draft)

Key points:

• cms:prepare:locales does not re-simplify English — it reads each project's own staging EN (staging/en/ and staging/cloud/en/)
• If staging EN is missing the version, translate fails — run cms:prepare:en first
• Target locales: zh, ja, ko, fr, ru, es (see cms-config.json)
• --force re-translates existing locale blocks (common after manual EN edits)
• Never copy comfyui locale files onto cloud; cloud campaign shortlinks live on cloud EN

Environment (.env.local)

CI: CMS_BASE_URL / TRANSLATE_API_BASE_URL → GitHub Variables; tokens → Secrets.

Simplification rules (EN popup)

Prompt: .github/scripts/cms/cms-simplify-prompt.ts
Config: .github/scripts/cms/cms-config.json → simplify

Style: principle-only prompt in cms-simplify-prompt.ts (no concrete version examples — avoids LLM contamination).

prepare:en copies docs URLs and local-length copy into Cloud. After it runs, rewrite Cloud EN (links and wording) before translating. Never invent URLs.

Copy length (local vs Cloud): Cloud popup users skim. After merge, shorten Cloud bullets so they do not list every node, mode, or task type. One short clause is enough: added the model, or one capability. Local CMS (staging/en/) and docs changelog/index.mdx can keep the fuller scope (which nodes, which modes). Do not shorten local to match Cloud.

Example: docs/local may say H3 Max landed on text-to-video, first-last-frame, and reference nodes. Cloud: Added H3 Max model support.

OSS bullets name the model, not the plumbing. After prepare:en, rewrite open-source bullets to match names users already see in tutorials/ (checkpoint family, fl2va / ref2va, ControlNet Union, and similar). If a tutorial page already documents the model, the popup should say we added support for that model. Do not describe loader internals: optional VAE, keyframe wiring, skipped LoRA keys, unless that is the only user-facing change.

LoRA / trainer format: say we support LoRAs trained in that format (or by that trainer). Do not mention the previous load bug.

Removals, deprecations, EOL: keep them on the popup (do not drop as housekeeping). On Cloud, still list the retired node or model names so users know which graphs break. The "one short clause" Cloud rule does not apply to removal bullets.

Bullet links (docs, local CMS, Cloud CMS)

Resolve each feature bullet before cms:prepare:locales. Search these sources every time a new version lands:

Match a template by name, title, or models to the changelog item. Search the whole index: partner api_* and OSS video_*, image_*, 3d_* (and any other prefix). Do not grep api_ only. Match a blog post only if it covers this product or version (MiniMax H3 day-0 is not MiniMax H3 Max).

Video templates: when several templates exist, pick one by suffix on name, in this order: r2v → i2v → t2v. Example: api_minimax_h3_max_r2v over _i2v / _t2v. If none of those suffixes exist, use the remaining matching template (flf2v, edit, fun_controlnet_union, and similar). Cloud URL shape: https://cloud.comfy.org/?template=<name> (no UTM unless the user supplied one).

Do not put Cloud ?template= URLs on docs or local popup. Do not copy local blog/PR links onto Cloud when a template (or user UTM) exists. After prepare:en merges comfyui → cloud, replace Cloud bullets that still point at PRs if the index has a template.

ComfyUI-WIKI commits (omit from changelog)

When curating changelog/index.mdx from ComfyUI git history, do not add bullets for commits routinely opened by ComfyUI-WIKI — they are dependency/content syncs, not core release features:

Also omit standalone frontend package semver bumps unless tied to a user-visible fix worth its own bullet. CMS simplify must never promote WIKI-only items into popup copy even if they appear in the full docs block.

Example staging shape (placeholders only). New Node Updates is optional and usually omitted:

**New Open-Source Model Support**
* [**Model Name**](source_url): Short description with 1–2 traits from the release data

**Partner Node Updates**
* [**Partner Node**](source_url): Partner scope and capability from the release data

Only when a human asks to include nodes:

**New Node Updates**
* [**Node Name**](source_url): What the node does and why it matters

Sync adds header: # ComfyUI vX.Y.Z via format-cms-content.ts.

Projects (comfyui + cloud)

cms:prepare may generate both projects so staging stays mirrored. For cms:sync and cms:publish, agents must treat comfyui as the default project and pass --project comfyui.

Cloud is never implied. Follow Hard gate: Cloud push / publish above: ask every time the user requests a CMS push or publish; run --project cloud only after they explicitly confirm Cloud in that request chain.

Same changelog content; Strapi project field and CMS header differ (# ComfyUI vs # Cloud).

When prepare:en targets both projects, it runs the LLM once on comfyui, then merges those version blocks into cloud while keeping any tracking shortlinks already on cloud EN for that version. prepare:locales translates each project from its own staging EN. It does not copy comfyui locale files onto cloud. With --project cloud alone, cloud is prepared directly. Sync/publish must be project-scoped by agents: --project comfyui first, then ask for Cloud confirmation, then --project cloud only after that yes.

Single project: --project comfyui, --project cloud, or CMS_PROJECT=<project>.

Mark a version high attention:

pnpm cms:set-attention -- cloud v0.24.0 high --save