Sanity Cms

Publish content to any Sanity CMS instance. Use when asked to create a Sanity draft, push a document to Sanity, upload an image asset to Sanity, or convert c...

Security Scan

The skill appears to implement exactly what it claims (publishing to Sanity), but its declared registry metadata is inconsistent with the runtime instructions and bundled script (missing required env vars and required binaries), so you should verify tokens, available tooling, and trust of the publisher before using it.

Purpose & Capability

Name, description, SKILL.md, references, and the shell script are coherent: the skill uploads images and pushes documents to a Sanity Content API using a project ID and write token — behavior matches stated purpose.

Instruction Scope

SKILL.md instructs the agent to read schema files from the workspace, accept pasted schema, fetch remote URLs via web_fetch, or introspect the dataset via Sanity API. These actions are reasonable for generating compatible documents but do allow the skill to read workspace files and fetch remote content — verify you want those accesses.

Install Mechanism

No install spec (instruction-only plus a bundled script). This is low-install risk. Note: the bundled script will be executed by bash and invokes curl and python3 at runtime; the registry did not declare these as required binaries.

Credentials

SKILL.md and the script require SANITY_PROJECT_ID and a write-enabled SANITY_API_TOKEN (sensitive). However the registry metadata lists no required env vars. Also the script relies on curl and python3 though required binaries are not declared. Asking for a write token is proportional to the task, but the metadata omission is an incoherence and increases the chance a user will accidentally provide more persistent credentials than intended.

Persistence & Privilege

The skill is not marked always:true and does not request persistent agent privileges. It does not modify other skills or system config. Autonomous invocation is enabled (default) but not combined here with other broad privileges.

What to consider before installing

What to check before installing/using this skill: - Metadata mismatch: the registry entry lists no required env vars or binaries, but SKILL.md and scripts require SANITY_PROJECT_ID and a write-enabled SANITY_API_TOKEN and expect curl, bash, and python3. Treat the registry metadata as incomplete and verify requirements before running. - Token scope: only provide a SANITY_API_TOKEN with the minimum necessary privileges (prefer a token limited to a staging dataset or Editor role scoped to specific datasets). Avoid supplying a global/owner token. - Supply env vars transiently: prefer giving the API token only for a single invocation rather than storing it long-term in the agent environment or persistent config. - Inspect the script yourself: the included scripts/publish_draft.sh is short and readable; verify it meets your expectations (it posts to https://<project>.api.sanity.io and uses your token only for those calls). - Workspace/file access: the skill can read schema files from your workspace or fetch remote schema URLs; do not let it read sensitive files you don't intend to expose. - Test safely: try on a staging dataset (SANITY_DATASET=staging) or with a token that cannot delete or manage production data first. - Trust and provenance: the skill has no homepage and an unknown source; if you do not trust the publisher, avoid giving write credentials. If you need autonomous agent invocation combined with write access, be especially cautious. If you want, I can (1) list the exact lines where the script requires env vars and external tools, (2) produce a minimal checklist to run the script safely, or (3) suggest a hardened invocation example that uses least privilege and staging.

Sanity CMS Skill

Publishes documents to Sanity CMS via the Content API. Works with any schema.

References

• API patterns (upload, mutate, query): references/api.md
• Portable Text body format: references/portable-text.md

Workflow

1. Understand the target schema

Four ways to get schema info — try in this order:

A — File in workspace: User drops schema at a known path (e.g. sanity-schemas/blogPost.ts). Read it directly.

B — Pasted in chat: User pastes the schema TypeScript/JS. Read it from the conversation.

C — Remote URL: User shares a GitHub raw URL or similar. Fetch with web_fetch.

D — API introspection (no file needed): Query the dataset directly — see references/api.md (Schema Introspection section). Use array::unique(*[]._type) to discover document types, then fetch one sample document to infer field names and shapes. Works without any schema file at all.

Once you have the schema (by any method):

• For array fields with type: 'block', use Portable Text format — see references/portable-text.md
• For reference fields (categories, authors, tags), query existing documents via GROQ — see references/api.md

2. Format the document JSON

Build a JSON object matching the schema:

• Omit _id — the script generates a drafts. prefixed UUID automatically
• Omit the cover image field — the script injects it after uploading
• All required fields must be present and within any validation constraints
• Save to a logical path (e.g. brain/projects/<slug>-sanity.json or similar)

3. Run the publish script

The script is at scripts/publish_draft.sh within this skill directory. Resolve the path relative to where the skill is installed (e.g. ~/.openclaw/skills/sanity-cms/scripts/publish_draft.sh or <workspace>/skills/sanity-cms/scripts/publish_draft.sh).

bash <skill-dir>/scripts/publish_draft.sh \
  path/to/document.json \
  path/to/cover-image.png   # optional

Optional env overrides:

Var	Default	Purpose
SANITY_DATASET	production	Target dataset
COVER_IMAGE_FIELD	coverImage	Field name for cover image
DRAFT_PREFIX	true	Set to false to publish immediately

Example with overrides:

SANITY_DATASET=staging COVER_IMAGE_FIELD=mainImage \
  bash <skill-dir>/scripts/publish_draft.sh doc.json cover.jpg

4. Confirm and report

After the script prints a draft ID, report to the user:

• The draft document ID
• A link to Sanity Studio (ask if unsure of the Studio URL)
• Which fields, if any, still need manual attention in Studio (e.g. unpopulated references)

Env Vars

Var	Description
SANITY_PROJECT_ID	Sanity project ID
SANITY_API_TOKEN	Write-enabled token (Editor or higher)
SANITY_DATASET	Dataset (optional, default: production)

Tips

• Always create drafts first (DRAFT_PREFIX=true) unless the user explicitly wants to publish live
• If a schema has reference fields, query for the referenced document IDs via GROQ before building the JSON — see references/api.md
• The script works with any document type: blog posts, pages, products, authors, etc.
• Cover image upload is optional — omit the second argument if the schema has no image field