// Create and wire Sanity core plugins using the monorepo's default plugin conventions. Use when adding, modifying, or reviewing plugins under packages/sanity/src/core, especially plugins added through resolveDefaultPlugins or studio.components middleware.
Add and review Sanity config properties that are reduced across root config and plugins. Use when adding beta flags, feature config, workspace/source options, default plugin gates, or resolved Source fields in packages/sanity/src/core/config.
Explain and create Sanity Studio plugins using the public plugin and tool APIs. Use when creating user-facing plugins, adding tools through plugins, or when an agent needs to understand what a Sanity plugin can configure before applying monorepo-specific default plugin wiring.
Simplifies code for clarity. Use when refactoring code for clarity without changing behavior. Use when code works but is harder to read, maintain, or extend than it should be. Use when reviewing code that has accumulated unnecessary complexity.
Optimizes application performance. Use when performance requirements exist, when you suspect performance regressions, or when Core Web Vitals or load times need improvement. Use when profiling reveals bottlenecks that need fixing.
How to write idiomatic, efficient RxJS code. Use this skill whenever the user is writing, refactoring, reviewing, or debugging code that uses RxJS — including any file that imports from 'rxjs' or 'rxjs/operators'. Trigger on mentions of observables, subscriptions, RxJS operators, or reactive streams. Even if the user doesn't say "RxJS" explicitly, activate when you see patterns like `.pipe()`, `.subscribe()`, `Observable`, `Subject`, `BehaviorSubject`, `switchMap`, `mergeMap`, or similar.
Write PR descriptions and release notes for the Sanity monorepo. Follows the repo's PR template with Description, What to review, Testing, and Notes for release sections. Auto-triggers when creating PRs via `gh pr create`. Use when creating pull requests, writing PR descriptions, drafting release notes, or when user mentions PR, pull request, or release notes.
| name | sanity-default-plugins |
| description | Create and wire Sanity core plugins using the monorepo's default plugin conventions. Use when adding, modifying, or reviewing plugins under packages/sanity/src/core, especially plugins added through resolveDefaultPlugins or studio.components middleware. |
Before adding a core plugin, read the sanity-plugin-authoring skill at ../sanity-plugin-authoring/SKILL.md to understand the general Sanity plugin API and what plugins can provide. Then inspect nearby plugins and these files:
packages/sanity/src/core/config/resolveDefaultPlugins.tspackages/sanity/src/core/config/types.tspackages/sanity/src/core/config/studio/types.tspackages/sanity/src/core/*/plugin/The new plugin should be added inside core so it can be imported into the default plugins.
Prefer local patterns over new abstractions.
Use definePlugin and export a stable internal name constant:
import {definePlugin} from '../../config/definePlugin'
export const FEATURE_NAME = 'sanity/feature'
export const feature = definePlugin({
name: FEATURE_NAME,
studio: {
components: {
layout: FeatureStudioLayout,
},
},
i18n: {
bundles: [featureUsEnglishLocaleBundle],
},
})
Use ../../config/definePlugin when matching existing internal plugin files. ../../config is also available in some folders.
Default core plugins that render UI text should add a locale resource bundle. Follow the pattern from packages/sanity/src/core/singleDocRelease:
packages/sanity/src/core/<feature>/i18n/index.ts: exports the locale namespace, US English bundle, and resource key type.packages/sanity/src/core/<feature>/i18n/resources.ts: exports default locale strings and keyof resource type.packages/sanity/src/core/<feature>/plugin/index.ts: imports the bundle and registers it under i18n.bundles.Example i18n/index.ts:
import {type LocaleResourceBundle} from '../../i18n'
export const featureNamespace: 'feature' = 'feature'
export const featureUsEnglishLocaleBundle: LocaleResourceBundle = {
locale: 'en-US',
namespace: featureNamespace,
resources: () => import('./resources'),
}
export type {FeatureLocaleResourceKeys} from './resources'
Example i18n/resources.ts:
const featureLocaleStrings = {
'action.example': 'Example',
}
export type FeatureLocaleResourceKeys = keyof typeof featureLocaleStrings
export default featureLocaleStrings
Example plugin registration:
import {featureUsEnglishLocaleBundle} from '../i18n'
export const feature = definePlugin({
name: FEATURE_NAME,
i18n: {
bundles: [featureUsEnglishLocaleBundle],
},
})
Default core plugins are listed in resolveDefaultPlugins.ts.
defaultPlugins(options) in the desired composition order.plugin.name === FEATURE_NAME branch in getDefaultPlugins.DefaultPluginsWorkspaceOptions in types.ts.getDefaultPluginsOptions, build default plugin options directly from workspace config defaults and spreads. Do not call config property reducers here; reducers belong to resolved source/workspace config, while default plugin options are a lightweight workspace-level input for plugin insertion.packages/sanity/src/core/config/__tests__/resolveConfig.test.ts with focused default plugin tests:
Example default option shape:
variants: {
enabled: false,
...workspace.beta?.variants,
}
Remember: user plugins are appended before default plugins in prepareConfig.tsx, then the component middleware chain reverses flattened config order. Check the existing chain before relying on wrapper order.
For default plugin changes, run:
pnpm vitest run --project=sanity packages/sanity/src/core/config/__tests__/resolveConfig.test.ts
Also run lint/read diagnostics for edited files. Add component-level tests only when the plugin changes runtime rendering beyond insertion.