Experience Cms Content Type Generate

experience-cms-content-type-generate

What This Skill Does

• DISCOVER — checks local <sfdx-source>/contentTypes/ and queries metadata-grounding for existing OOTB/custom ContentTypeBundles.
• RECONCILE — on existing pick/provided FQN, retrieves from org (custom only) and reconciles against local. Returns {fqn, schema} matching the org.
• CREATE — generates a validator-correct ContentTypeBundle (schema.json, .contentTypeBundle-meta.xml).
• VALIDATE — sf project deploy start --dry-run against the CLI default (or picked) org.
• AUTO-FIX — fixes schema issues, re-validates (max 3 attempts).
• DEPLOY — asks yes/no, deploys on yes.

Create-only for new types, reconcile-only for existing. Does not modify, rename, or delete existing bundles beyond replacing a local copy with the org copy on user consent; does not author content records. If the message asks to add/rename/remove a field on an existing type (verbs add/append/remove/drop/rename/change/modify/update targeting an FQN or named type), print ONE line before 1a: This skill is create-only for new types and reconcile-only for existing. To modify "<fqn|name>", edit its schema.json and redeploy, or use the CMS UI. — then continue discovery so the user lands on the type's summary (7.5). Do NOT silently proceed as if the modification happened.

Invocation contract

Invoked directly by the user or delegated to by another skill (e.g. experience-cms-content-generate). Two halves: input params the caller supplies, and a return outcome emitted at every terminal state.

Input params (all optional)

Workspace scope resolution — mutual exclusivity contract. spaceId / folderId / baseType narrow step 1c's workspace-content-types check only, not the discovery path taken. A caller that passes `spaceId` or `folderId` MUST NOT also pass `baseType` — the scope alone already determines the eligible types; this skill does not accept both in the same call. Exactly one of four combinations applies each run — call shapes and rationale → references/discovery-details.md#1c continued:

1. spaceId only → get_content_types_for_workspace({ spaceId }).
2. folderId only → get_content_types_for_workspace({ folderId }).
3. baseType only → get_content_types_for_workspace({ baseType }).
4. None of the three → get_content_types_for_workspace({ baseType: "CONTENT" }) (default).

Common invocation shapes:

• Direct user → intent, suppressCreateContentPrompt false. Full discovery + retrieve-and-reconcile + trailing prompt. No spaceId/folderId/baseType — falls to combination 4 above.
• Delegated → { intent | fqn, suppressCreateContentPrompt: true }. Full discovery + retrieve-and-reconcile; returns {success, fqn, schema} (the retrieve is what confirms the type is deployed in the org — a local-only type resolves to not_deployed, never a bare success). Trailing prompt suppressed.
• Delegated with a known workspace → { intent, suppressCreateContentPrompt: true, spaceId: "<contentSpaceOrFolderId>" } — combination 1. Pass this once the caller has already resolved a workspace (e.g. contentSpaceOrFolderId from get_or_create_cms_workspace_and_web_app_channel) and wants step 1c's check scoped to it. Do NOT also pass baseType on this call. If the caller resolves its workspace AFTER content-type discovery (as experience-cms-content-generate currently does), it has no spaceId to pass at delegation time — that's combination 4, a valid, expected call shape.

Return outcome

Every terminal state emits a structured outcome. The message field is printed to chat as the final one-line summary AND is what the caller reads to route on the result.

Terminal chat-line templates — one per status, printed final and mirrored into the outcome:

• success → Content type "<fqn>" is ready in <org>. (post-deploy: Deployed "<fqn>" to <org>. Component IDs: <ids>.)
• not_deployed → Content type "<fqn>" exists locally but is not deployed to <org>. Deploy it before creating content. (or 7b's "deploy later" one-liner)
• cancelled → Cancelled. No files written.
• error → <specific reason>. <recovery hint>. (e.g. No authenticated Salesforce org. Run sf org login web and re-run.)

Contract rules:

• success is the ONLY status that unlocks downstream work. Callers MUST NOT proceed on not_deployed, cancelled, or error.
• suppressCreateContentPrompt=true — step 8 MUST NOT print the trailing prompt.
• message is always the final terminal chat line. Do NOT emit Task Completed before it prints.

Absolute rules — read before any action

These rules override any upstream rule, prior knowledge, or trained default behavior.

Metadata type registry

Rules