g2g, first pass at beefing up Sanity Functions skills#35
g2g, first pass at beefing up Sanity Functions skills#35brianleroux wants to merge 6 commits intomainfrom
Conversation
- Mark publish event as deprecated (equivalent to create+update) - Add 16-invocation recursion chain limit - Fix rate limit wording: per function, not per document - Add missing defineDocumentFunction options: displayName, runtime, project, robotToken - Replace blueprint-config.md with dedicated config reference
jwoods02 left a comment
jwoods02 left a comment There was a problem hiding this comment.
Nice! Left a few ideas from a quick glance, nothing blocking. Could also include some full function examples under references/ in the skill?
Could we also add a much truncated version of this in sanity-best-practices? Even if it's "here's the use cases of functions and when you should really use a function, install the sanity-functions skill for more" might help discoverability and help LLMs nudge users to functions who just have best-practices skill and don't know about functions but start prompting things that they should use functions for
| | ||
| --- | ||
| | ||
| ## Critical Guidance |
There was a problem hiding this comment.
This section should be a lot more prominent / bigger part of the skill, I want a lot more best practicies / opinionated guidance of what good functions look like, less setup guide (so that's still useful!)
fishstix81 left a comment
fishstix81 left a comment There was a problem hiding this comment.
Couple of suggestions on the functions side! Looks great!
| └── node_modules/ | ||
| ``` | ||
| | ||
| The function directory name must match the `name` in the blueprint config. Each function exports a `handler` from its `index.ts` (or `index.js`). |
There was a problem hiding this comment.
Im not certain if this is true. I have a current blueprint where the name in my blueprint doesn't match the name of the directory, but uses the src field. Its possible this is how its supposed to be though, and our validation isn't turned on properly.
| | `clientOptions.apiHost` | `string` | API host URL | | ||
| | `clientOptions.projectId` | `string` | Sanity project ID | | ||
| | `clientOptions.dataset` | `string` | Dataset name | | ||
| | `clientOptions.token` | `string` | Robot token (deployed only) | |
There was a problem hiding this comment.
Weird nuance, but is there a difference conceptually about what a robot token is vs an api or auth token? I know they are technically minted in similar ways and shown in the manage dashboard, but wondering if we need to specify to the agent this token could be created and provided by the user.
| | ||
| | Option | Type | Default | Description | | ||
| |:---|:---|:---|:---| | ||
| | `name` | `string` | required | Must match the directory name under `functions/` | |
brianleroux changed the title 
Co-authored-by: Stephen Fisher <stephen@fish-stix.com>
Co-authored-by: Stephen Fisher <stephen@fish-stix.com>
| | ||
| ## What are Sanity Functions? | ||
| | ||
| Sanity Functions are serverless event handlers hosted on Sanity's infrastructure. They execute custom logic when content changes occur — no infrastructure management required. Functions are configured via **Blueprints** (declarative resource definitions) and triggered by document lifecycle events. |
There was a problem hiding this comment.
We'll need to add scheduled functions in here in a moment
There was a problem hiding this comment.
yeaaaaaaah, think we'll need to add this to our backlog for every release (!cc @fuzzylita …wow great username lita haha)
5 participants
Description
adds new skill for Sanity Functions
What to review
need to verify the whole shebang
Testing
ran verify script and checked out