Experience Cms Content Generate

Creating CMS Content

Universal skill for creating Salesforce CMS content records — orchestrates type discovery, workspace resolution, and create_cms_content dispatch against an existing ContentTypeBundle.

Content generation is server-side, always. create_cms_content / update_cms_content_variant take the goal / edit instruction as prompt; the server generates + validates the body against the schema and returns the persisted record. Agent never walks the schema, assembles contentBody, pre-validates, or regenerates rejected fields (Principle 3).

Scope

Creates managed content records in Salesforce CMS — instances authored against an existing ContentTypeBundle.

Use when the user wants to: create a content record of any kind (single or bulk) from a free-text prompt against an existing CMS type; edit/refine session items; update/edit OR publish a record identified directly by managedContentVariantId / managedContentId — even if NOT created this session (Step 0 → UPDATE / PUBLISH entry); publish all or a subset; delete/remove a record — this skill OWNS the delete request and routes to a hard stop (Step 0-D); never surface the internal reason.

DO NOT use when the user wants to: define a new content type / schema (use experience-cms-content-type-generate); unpublish, clone, or version a record; manage workspaces / folders / channels; attach images / media; apply branding.

"Create image/media content" is NOT a pre-flight scope-out (only literal binary file attach/upload is the excluded "attach media" above). Creating an image/video content record (e.g. from a URL) enters the normal flow — resolve type + workspace, dispatch create_cms_content, never refuse up front or propose a REST / UI workaround. sfdc_cms__media is server-decided: let the tool return the error, then hard-stop per Principle 15 (references/error-recovery.md).

Before You Start

Follow steps in order — do not skip or reorder.

Every successful run MUST end by dispatching create_cms_content (≥1×), each carrying the goal via prompt.

Interaction-minimal — the only pre-dispatch question is Step 3 (workspace). Never ask for goal refinement, mode, or body details. Step 1 is silent. FQN in prompt → Step 2 fast-path; else Step 2a delegates with no intervening ask_user_tool. Bulk exception: Step 4 presents topic prompts for approval.

VERBATIM QUESTION CONTRACT — EVERY ask_user_tool, no exceptions. Full rule → references/ux-rules.md. Every question goes through ask_user_tool (never plain text); before ANY call, open assets/questions.md and copy BOTH the question string AND the answers array character-for-character, filling only <placeholders> — never reword/shorten the question, never add/drop/reorder answers, never put list content into an answer. No template covers it? STOP and re-read assets/questions.md — never compose one ad hoc.

Workflow Overview

- [ ] Step 1: Understand intent (silent — domain, count, FQN if present)
- [ ] Step 2: Resolve content type — fast-path (Buckets 1/2/3) or delegate → contentTypeFqn
- [ ] Step 3: Resolve workspace — UIBundle options or manual ID
- [ ] Step 4: Build payload — single or bulk (topic approval if bulk)
- [ ] Step 5: Dispatch create_cms_content (parallel for bulk)
- [ ] Step 6: Display content body + summary
- [ ] Step 7: Post-action loop — Edit / Publish / End
- [ ] Step 8: Edit — update_cms_content_variant
- [ ] Step 9: Publish — publish_content
- [ ] Step 10: Post-publish — Create more / Render (if UIBundle) / End

Step 0: Route the Intent (run FIRST, always)

Before Step 1, classify into exactly one intent and route. update/publish/delete are first-class entry points — NOT only tails of the create flow. Opening with one of those verbs → do NOT freelance (pick tools by intuition, run SOQL, guess a variant ID). Read the opening verb and route:

No-drift STOP rule (every route). If the route's required content-write tool (create_cms_content/update_cms_content_variant/publish_content) is unavailable on this bridge, STOP, print the actionable user-facing message, end the turn. Never substitute SOQL, sf data, CLI, a sibling tool, or the contentBody channel — tool-unavailable and unsupported-operation are terminal, never a fallback trigger. Exact message + per-route slots + may/may-not-say → references/intent-routing.md § No-drift STOP rule.

Step 0-U (UPDATE) and Step 0-P (PUBLISH) — direct-entry paths

Full procedural detail → references/intent-routing.md. Direct-entry counterparts to in-session Step 8 (edit) / Step 9 (publish) — a record identified directly, possibly from a prior session or another user (editing/publishing is NOT session-only). Load-bearing invariants:

• Hard identifier gate — BEFORE any tool call. Target managedContentVariantId comes ONLY from (a) the session registry or (b) a user-typed identifier (MC…/20Y…/9Ps). Name-only, no ID, not in registry → STOP and ask via ask_user_tool ("Which record should I work with?" question, copied EXACTLY, answers ["Cancel"]). You may NOT locate the record yourself — no search_content, discovery/listing tool, SOQL, or guessed ID.
• Resolve by prefix + validate before acting → references/identifier-resolution.md (9Ps→get_content_variant; MC…/20Y…→get_content). Read fails → STOP; never edit/publish blindly.
• 0-U → Step 8c (after MANDATORY full-body display + edit-instructions prompt), closes via Step 7 dialog. 0-P → Step 9b, closes with publish confirmation and ends the turn (no Step 10 — no session context). Neither runs Steps 1–5.

Step 0-D: DELETE (hard stop)

Delete is not available (no delete capability — internal detail, do NOT surface). Print exactly and only this message, nothing else:

Deleting content isn't supported here. To delete this content, open it in Salesforce CMS and use the Delete option there.

Say NOTHING before or after — no preamble, reasoning, rule-restatement, tool/server names, or meta-narration; the user sees only the plain message. End the turn. Do NOT offer unpublish_content, SOQL, or CLI as a substitute — the CMS UI is the only path to surface.

Step 1: Understand Intent

Silent step — NEVER ask anything here. Extract agent-internally, then go straight to Step 2. No "Let me clarify…" turn, no ask_user_tool, no content-type menu — even a vague prompt (generate new content for Q4 launch) has everything Step 2 needs. About to dispatch a question in Step 1 (clarify, content-type menu, "type in mind?", "how many?")? That IS the bug — move to Step 2. Parse the message for:

• Content domain (article, blog, news, FAQ, …) — inferred as-is; no domain named is fine.
• Quantity — explicit count → that number; "multiple"/"several"/"a few"/"some" → agent chooses 4–5; no indicator → single.
• Content-type reference — capture any token that looks like a content type name (exact FQN, single-underscore near-miss, bare developer name, natural-language name) verbatim. Do NOT classify here — Step 2 assigns the bucket.

Do not strip or rewrite the message — the original is the creative direction for Step 4 topic prompts and what Step 2a passes to the sibling verbatim as intent.

Multi-type gate — the ONE question Step 1 may raise. If the prompt spans ≥2 distinct content TYPES (each its own ContentTypeBundle, e.g. grooming packages AND service area coverage), you MUST ask the user to pick ONE before Step 2 (one type per run; two corrupts the delegation contract). Dispatch the Step 1 multi-type prompt VERBATIM (answers = distinct domains in the user's words + Cancel), carry ONLY the chosen domain forward as intent. SOLE exception to "never ask" — fires only on ≥2-distinct-types, never goal/mode/quantity. Multiple topics of ONE type (5 blog posts) do NOT trigger it (bulk). Rule + examples → references/content-type-classification.md § Multi-type gate.

Step 2: Resolve the Content Type

Classify Step 1's captured content-type reference into one of four buckets — full detection rules, examples, routing → references/content-type-classification.md. Summary:

• Bucket 1 — Exact FQN. Matches ^[a-zA-Z_][a-zA-Z0-9_]*__[A-Za-z][A-Za-z0-9_]*$ (c__BlogPost). Capture contentTypeFqn, Step 3. Silent.
• Bucket 2 — Auto-correctable near-miss. Single-underscore between known namespace and name (c_news→c__news). Auto-correct, announce in chat (no ask_user_tool), Step 3.
• Bucket 3 — Low-confidence FQN-ish. Bare name (BlogPost→propose c__BlogPost) or unknown-namespace single-underscore. Dispatch the Step 2 FQN-correction prompt, route on the answer.
• Invalid-FQN gate. Token meant as FQN (has __) but malformed, not a Bucket 2 near-miss (c__, __Foo, c__Blog Post, c__123) → do NOT delegate as free text; dispatch the FQN-correction prompt (Let me provide a different FQN/Cancel), restart Step 2 on the new string.
• Bucket 4 — Natural language or no token (blog post). Delegate — Step 2a.

Fast-path invariants (Buckets 1/2/3): once the FQN is captured, do NOT verify it in the org, delegate, scan contentTypes/, dispatch metadata-grounding, retrieve, or read schema.json. A bad FQN fails deterministically as INVALID_TYPE at Step 5. On the delegated path the sibling owns scan, grounding, pick question, create-new + deploy, FQN construction, retrieve-and-reconcile.

2a–2d. Delegate to the sibling (Bucket 4 only)

Full protocol → references/delegation-protocol.md. In short: 2a resolve workspace FIRST (Step 3 → contentSpaceOrFolderId), print banner Resolving the content type for your request…, invoke via mcp__skill_bridge__load_skill("experience-cms-content-type-generate") (NOT built-in Skill — returns Unknown skill), pass { intent: "<user message verbatim>", suppressCreateContentPrompt: true, <scope> } (<scope> = spaceId 0Zu OR folderId 9Pu, exactly one, never baseType); no pre-delegation question. 2b — while the sibling runs this skill is PAUSED (no Step 4+ call until a terminal outcome; interleaving corrupts its state machine). Consume { status, fqn, message } (ignore any schema), route strictly on status:

2c (only on success) — verify fqn matches the FQN regex; missing/malformed → surface re-run message + ask_user_tool (Retry with an explicit FQN/Cancel); then capture contentTypeFqn, Step 3. 2d — never call metadata-grounding, sf project retrieve, re-present/re-pick, or build FQNs from folder names (sibling owns all of that); five drift signals → hard-stop to the load failed row; never downgrade not_deployed to success. On a manual space the 2a call is the Layer-2 confirmation — invalid/not-found → HARD STOP, re-ask via the invalid-ID template.