| name | tuturuuu-cms-studio |
| description | Tuturuuu CMS and external-project content studio guidance. Use when changing apps/cms, external project adapters, CMS landing-page editing, content collections, media workflows, preview delivery, or branded sibling-site content management. |
Tuturuuu CMS Studio
Core Workflow
Use this skill for apps/cms and external-project content work, especially when
the request is about making content editing easier for non-technical users.
Start with the repo AGENTS.md, git status --short, and active
tmp/agent-coordination/ notes. Keep sibling branded sites as read-only context
unless the task explicitly needs integration changes there.
Discovery
Map the CMS control plane before editing:
apps/cms/src/features/cms-studio/ for editor shells, content model,
capability grouping, media, workflow, preview, and entry detail behavior.apps/cms/src/features/home/ for the operator landing page.apps/cms/src/app/[locale]/(dashboard)/[wsId]/navigation.tsx and
cms-paths.ts for new CMS routes and aliases.apps/cms/src/lib/external-projects/access.ts for CMS workspace gates and
satellite app-session access.- sibling
lib/*-external-project-manifest.ts files only to understand
collection slugs, profile fields, blocks, and assets consumed by each branded
site.
Prefer improving the centralized CMS experience over adding new bespoke admin UI
inside each sibling site.
UX Rules
- Make the default path task-based: landing-page edits, content library,
preview, and member access should be obvious without knowing CMS internals.
- Keep visible CMS product copy on consumer vocabulary: site, site template,
connection, content, section, URL path, custom details, media, publishing,
preview, people, invitations, and team access. Do not expose external project,
canonical, adapter, binding, slug, schema, metadata, profile data, payload, or
JSON in normal editor paths.
- Treat landing-page content as first-class for branded projects. Group hero,
profile, section, featured, navigation, and primary-link collections behind a
simple "Landing page" surface when possible.
- Keep Landing, Library, and Games scopes distinct. Landing is a page-builder
for landing-only sections and readiness checks; Library is content operations
for non-landing/non-game content; Games remains the playable-project surface
behind the CMS Games flag. Add capability tests whenever collection grouping
changes.
- CMS team access must use external-project-aware
apps/web routes and
@tuturuuu/internal-api helpers. Do not call the standard workspace members
or roles settings endpoints directly from apps/cms; those routes can 403
for app-session users who are valid CMS editors.
- Keep raw configuration, implementation IDs, site-type mappings, and workflow
mechanics out of the primary editor path unless the user is doing advanced
configuration. Put exact implementation values behind collapsed Developer
details panels or internal root-console advanced controls.
- Use explicit empty, loading, error, and review states that tell editors what to
do next.
- Add, remove, or replace CMS translation keys with
bun i18n:add --app cms
and --mode add|remove|replace; use --entries or --entries-file for
bulk updates so every detected locale file is updated and sorted together.
Reserve manual message JSON edits for broad prose rewrites or value-only
updates, then run bun i18n:sort.
- Maintain the CMS product-copy hygiene test when adding CMS-owned strings. Add
narrow exceptions only for admin/developer-detail surfaces that genuinely need
exact implementation values.
Implementation Patterns
- Use TanStack Query and
@tuturuuu/internal-api for client-side CMS reads and
mutations. Do not add raw client fetch('/api/...').
- Keep route additions wired through navigation aliases and
cms-paths.ts so
entry detail dialogs preserve the correct base surface.
- If a capability should vary by branded adapter, add data-driven selectors or
blueprints rather than hard-coding branches inside entry/editor components.
- Keep field/schema work compatible with imported manifest schemas; do not
hand-edit generated DB types.
- When changing CMS Games or media handling, preserve asset-type support and
same-origin playable routes.
Verification
Run focused checks before broader repo checks:
bun test src/features/cms-studio/cms-editor-capabilities.test.ts src/features/cms-studio/cms-content-model.test.ts src/features/cms-studio/cms-product-copy.test.ts
bun type-check:cms
bun i18n:sort
bun i18n:check
Run bun check for TypeScript, JavaScript, messages, or repo config changes
unless an unrelated pre-existing blocker prevents it.
