# Contentrain Full AI Context

Govern the content your AI ships into code.
Turn your hardcoded UI copy into a Git-native content governance. Start locally with MCP, CLI, and SDKs; add Studio when your team needs to collaborate.

## Entity

Name: Contentrain
Website: https://contentrain.io
Studio: https://studio.contentrain.io
AI docs: https://ai.contentrain.io
Studio docs: https://docs.contentrain.io
GitHub: https://github.com/Contentrain

## Operating Thesis

- AI generates quickly. Contentrain governs what reaches the product.
- Developers start locally with npx contentrain init, MCP tools, Normalize, validation, and generated SDK access.
- Teams add Studio for structured editing, review, roles, branch workflows, and eligible managed operations without moving content out of Git.
- The technical differentiator is that developers and agents can inspect the same content system inside the repository.

## Pricing Summary

- Open Source: $0 MIT packages. MCP, CLI, SDK, types, rules, and skills. No account needed.
- Starter: $9 per month. For solo developers and small projects using Studio.
- Pro: $49 per month. For teams that need collaboration and higher limits.
- Enterprise: Custom cloud or self-managed. For organizations needing dedicated support, SSO paths, white-label, and custom limits.

## Integration Surface

- AI Agents: Claude Code, Cursor, Windsurf, GitHub Copilot, Cline, Continue, Aider, Any MCP client
- Frameworks: Nuxt, Next.js, Astro, SvelteKit, Vue, React, React Native, Node
- Platforms & Infra: GitHub, GitLab, Vercel, Netlify, Cloudflare, Docker, AWS, Self-hosted

## Pages

### Start with MCP, CLI, SDK, rules, and skills
URL: https://contentrain.io/developers
Category: product
Summary: Developers get a local-first content stack: CLI setup, MCP tools, rules, skills, validation, generated SDK access, and a clear path into Studio when teams need review.

Key sections:
- Initialize a content system inside the repository: The CLI creates a .contentrain workspace where models, content, metadata, vocabulary, and context live beside the application. That gives AI coding agents and developers a source of truth they can read before they change copy.
- Use MCP as the agent operating layer: The MCP package defines 24 bounded tools: 19 core tools for project, model, content, validation, workflow, Normalize, and bulk operations, plus 5 media tools that appear only when the provider exposes a media capability. Local stdio and HTTP transports give agents a repeatable interface instead of repository-specific write logic.
- Normalize hardcoded strings before they become debt: The normalize workflow scans source files, extracts approved strings into content models, then patches code to reuse generated content access. It turns the most common AI-built app problem into a reviewable workflow.
- Generate runtime access for modern frameworks: The JavaScript SDK generates query clients that Nuxt, Next, Astro, SvelteKit, Vite, Expo, and Node apps can consume without a CMS runtime dependency. The app imports content through stable typed APIs instead of parsing files by hand.
- Ship shared rules and skills with the content system: The rules and skills packages make content operations legible to agents. They define how to validate schemas, normalize strings, manage translations, review content, and avoid unsafe edits.
- Move to Studio when collaboration becomes the bottleneck: When non-developers need structured editing, roles, and review, the same content contract can move into Studio. Media, CDN delivery, forms, APIs, and usage controls are available according to the selected edition, plan, and deployment.

FAQs:
- Do developers need Studio to start? No. The MIT packages let you initialize, validate, normalize, generate, and serve local workflows before a Studio account exists.
- What is the first command for a new app? npx contentrain init is the default entry point. From there, run validate, generate a query client, and use normalize when the app already has copy in source files.
- Why is MCP important here? MCP gives AI coding agents a bounded, repeatable interface for content operations. That is safer than asking an agent to edit arbitrary JSON and source files from scratch.
### Govern AI content on your infrastructure
URL: https://contentrain.io/enterprise
Category: product
Summary: Enterprise Contentrain is for teams that need governed AI content operations on controlled infrastructure with licensed Studio capabilities, review controls, delivery surfaces, and operational support.

Key sections:
- Enterprise value starts with governed AI operations: The enterprise problem is not only content storage. It is controlling what AI agents can change, how humans review it, and how content reaches production systems.
- Studio centralizes team controls: Studio centralizes workspace and project administration, role-scoped content access, review, and usage visibility. Eligible Enterprise deployments can add media, delivery, forms, webhooks, APIs, SSO, and other separately licensed capabilities.
- Deploy close to existing infrastructure: Controlled environments need predictable integration points. Studio uses explicit server APIs, provider modules, storage paths, database access, and deployment configuration rather than hiding operations behind a black box.
- Govern delivery, not only editing: Where enabled, CDN delivery, forms, webhooks, media, and Conversation API operations can remain tied to the same project rules and review model instead of becoming unrelated content systems.
- Use enterprise licensing for terms and support: Enterprise evaluation should confirm license terms, deployment requirements, support, custom limits, and advanced governance capabilities. The MIT developer packages remain available independently.

FAQs:
- What makes Enterprise different from Studio SaaS? Enterprise is for teams that need self-managed or controlled infrastructure, commercial licensing, support, and governance requirements beyond a standard SaaS workspace.
- Does Enterprise replace the open-source packages? No. The MIT packages remain the developer layer. Enterprise adds operating controls, deployment ownership, and commercial support around Studio.
- What should an enterprise demo focus on? Show agent boundaries, role-scoped workflows, branch review, validation, delivery surfaces, and how the content contract remains portable in Git.
### Works with your agent, framework, and deployment path.
URL: https://contentrain.io/integrations
Category: product
Summary: Contentrain stores content as plain JSON and Markdown in Git, exposes MCP tools to agents, and provides generated query access plus eligible CDN and API delivery paths.

Key sections:
- Connect AI agents through MCP: Contentrain integrates with MCP-compatible agents through local stdio and HTTP transports. The agent gets structured tools for status, content, models, validation, scanning, normalize, branch submission, and bulk operations.
- Generate framework-friendly content access: The SDK supports modern JavaScript application workflows by generating a content query client. Nuxt, Next, Astro, SvelteKit, Vite, Node, Expo, and React Native projects can consume content without coupling to a database CMS.
- Work with local, GitHub, and GitLab provider paths: The provider architecture separates content operations from the place where the repository lives. Local provider access is strongest for normalize; GitHub and GitLab paths support hosted repository workflows.
- Use Studio APIs when content leaves the repository: Studio can add CDN routes, Conversation API, form submissions, webhooks, billing, usage, and workspace APIs. Each operational integration remains conditional on edition, plan, provider, and deployment capabilities.
- Keep deployment choices open: Contentrain can stay local for a developer, run as a Nuxt Studio app, or be deployed in self-managed infrastructure. The content contract stays file-based while delivery and team workflows can move closer to production needs.

FAQs:
- Which agents can use Contentrain? Any environment that can use the Contentrain MCP server can operate the content system through bounded tools. The integration point is MCP, not a single proprietary agent.
- Does the app need a CMS API at runtime? Not always. Many apps can use generated content access at build or server time. Studio CDN and APIs are available only when the plan and deployment enable them.
- Why separate local and remote providers? Normalize and source patching need real source access. Remote providers are better for repository workflows where content changes are reviewed through hosted Git operations.
### Connect AI clients to governed Contentrain projects
URL: https://contentrain.io/docs/mcp-connector
Category: product
Summary: Use Studio's remote MCP Connector to let supported AI clients read and update structured project content through OAuth-scoped, Git-backed operations.

Key sections:
- Authorize one AI client connection for one project: Add your Studio deployment's /api/mcp/remote endpoint to the AI client. Studio opens in the browser, you sign in, select a workspace and project, review the requested scopes, and approve the connection. Connect again when the client needs a different project.
- Use the setup path documented for your client: Studio documents remote MCP setup for Claude, Claude Code, ChatGPT developer mode, Codex, and MCP Inspector. Each client uses the same endpoint and browser consent flow, even though its settings or configuration file differs.
- Grant only the project and content scopes the client needs: OAuth scopes separate project metadata, content reads, content writes, and offline access. Eligible deployments can also advertise media read and write scopes. Tool calls use the canonical contentrain_* MCP tool family and remain subject to tool availability.
- Confirm deployment, plan, quota, and media requirements: The remote endpoint requires managed authentication with the PostgreSQL database provider. It is plan-gated, shares the workspace MCP call quota with API keys, and only exposes media scopes when the deployment, storage, plan, and project CDN settings satisfy the media capability checks.
- Keep access bounded, revocable, and auditable: Access tokens expire after one hour and refresh tokens can keep an approved client connected for up to 30 days. Disconnecting an app revokes its token family. Content writes remain Git-backed, while the privacy addendum explains data routing, encryption, retention, sub-processors, and deletion.

FAQs:
- What is the Contentrain MCP Connector? It is Studio's OAuth-authenticated remote MCP endpoint. A supported AI client connects to one chosen project and calls bounded content tools without receiving direct repository credentials.
- Which AI clients have documented setup paths? The Studio codebase documents Claude, Claude Code, ChatGPT developer mode, Codex, and MCP Inspector. Other clients can connect when they support remote HTTP MCP and the required OAuth flow.
- Is the connector the same as the local MCP package? No. The MIT @contentrain/mcp package can run locally over stdio or HTTP. The Contentrain MCP Connector is Studio's shared remote endpoint with OAuth, project selection, scoped access, quotas, and deployment gates.
- Where is the remote MCP Connector available? It requires Studio's managed authentication and PostgreSQL provider pair plus an eligible Community, Starter, Pro, or Enterprise plan. The Free workspace shell is not eligible.
- Can the connector merge or reject review branches? No. Studio-owned branch lifecycle tools are not exposed over remote MCP. Content writes land on cr/* branches and follow the project's configured auto-merge or review workflow.
- Can I revoke a connection? Yes. Studio's Connected Apps settings let authorized users disconnect an app. Revocation invalidates its token family and the client must authorize again before making another call.
### Turn hardcoded strings into governed content
URL: https://contentrain.io/normalize
Category: product
Summary: Normalize scans existing code, extracts hardcoded UI text into structured content, patches reuse points, and turns AI-generated copy into a governed workflow.

Key sections:
- Start with the strings already in your codebase: Normalize is designed for real projects that already contain button labels, empty states, headings, validation messages, and marketing copy. It scans source files and groups candidates before anything is written.
- Extract content before patching source code: The workflow separates extraction from reuse. First, approved strings become Contentrain content entries; then code can be patched to consume generated access after the content model is reviewed.
- Replace hardcoded strings with generated access: After extraction, reuse patches update source files with expressions chosen for the framework. This keeps application code small while making text editable, localizable, and visible to agents.
- Turn localization into a normal content operation: Once strings are structured, locale parity and translation review can be handled as content quality work instead of grep-and-replace. Dictionaries and collections can carry locale-specific values without hiding them from Git.
- Use Studio when Normalize becomes team work: Normalize can start as a local developer workflow. Add Studio when content teams need structured views, role-based review, and branch governance; media context is available where the deployment supports it.

FAQs:
- Does Normalize edit source code immediately? No. The recommended flow extracts approved content first, then applies reuse patches after review. That separation makes the migration easier to inspect.
- What kind of strings should be normalized first? Start with repeated UI labels, empty states, marketing sections, onboarding copy, docs snippets, and localization candidates that product teams will edit again.
- Can Normalize work without a remote Git provider? Yes. The local provider supports source scanning and file operations. Remote providers are useful for hosted workflows, but local source access is the strongest starting point.
### MIT packages and an AGPL Studio core
URL: https://contentrain.io/open-source
Category: product
Summary: Contentrain provides six MIT-licensed developer packages for local content work. Studio Community is AGPL-3.0, while separately licensed enterprise modules cover additional managed and organizational capabilities.

Key sections:
- Six MIT packages provide the local developer stack: The MIT package set covers the CLI, MCP server, JavaScript query SDK, shared rules, agent skills, and shared types. Together they provide a local, framework-agnostic path for modeling, validating, normalizing, and consuming content.
- Studio Community adds an AGPL team workspace: Studio Community is the self-managed AGPL-3.0 application for Git-backed workspaces, projects, structured editing, chat-assisted operations, and review. Features marked as enterprise remain disabled unless a separately licensed edition provides them.
- Shared standards keep both sides aligned: The packages and Studio share the same vocabulary for model kinds, field types, validation, and content files. Moving from local tools to Studio does not require moving content into a different source of truth.
- Start locally and add Studio when the workflow becomes shared: Run init, normalize existing strings, validate models, generate query access, and ship from Git. Add Studio when editors or reviewers need a shared interface, permissions, branch review, or eligible managed operations.
- Plain files and Git history preserve portability: Content lives as files and code can import generated clients. That makes Contentrain easier to adopt in AI-built apps because the system is visible to both developers and agents.

FAQs:
- Which Contentrain packages use the MIT license? The CLI, MCP server, query SDK, rules, agent skills, and shared types packages are MIT-licensed and can be used independently of Studio.
- Can teams use only the MIT packages? Yes. Developers and technical teams can run local workflows without Studio. Studio becomes useful when structured editing, team review, roles, or managed operations are recurring needs.
- What does AGPL-3.0 apply to? Studio Community is the AGPL-3.0 self-managed edition. Separately licensed enterprise modules and managed services have their own terms and capability requirements.
### Run content governance as a repeatable operating system
URL: https://contentrain.io/playbooks
Category: product
Summary: Playbooks turn Contentrain adoption into repeatable workflows for AI agents, developers, editors, migrations, and Studio operations.

Key sections:
- Choose the workflow before choosing the interface: Each playbook turns a common adoption moment into a concrete operating path. Teams can start with local packages, move through Normalize, add content editor workflows, and adopt Studio when collaboration and delivery become valuable.
- Connect local developer tools with Studio team workflows: The playbooks connect the MIT packages with Studio around one Git-native content contract. Developers can start with MCP, CLI, query SDK, rules, and skills; teams can add structured editing, roles, and review, plus eligible media and delivery operations.
- Make content governance repeatable across teams: Content governance fails when every team invents its own process. Playbooks make implementation, migration, editor review, and Studio rollout visible enough for developers, AI agents, and content teams to repeat safely.

FAQs:
- Which playbook should we start with? Start with the developer implementation playbook when a team is installing Contentrain for the first time. Use Normalize migration when the codebase already has hardcoded copy.
- Do playbooks cover both packages and Studio? Yes. The playbooks are written for the full ecosystem: MCP tools and local packages first, then Studio when review, roles, delivery, and team operations are needed.
- Why are playbooks important for AI teams? They give AI agents and humans the same operating model: context, models, validation, branch review, checklists, and next steps instead of ad hoc content edits.
### Free open-source packages. Studio plans for teams.
URL: https://contentrain.io/pricing
Category: product
Summary: Start free with the MIT packages. Add Studio when content becomes a team workflow, then choose Starter, Pro, or Enterprise by seats, usage, delivery, and deployment needs.

Key sections:
- Build locally with the MIT packages: Initialize projects, normalize hardcoded strings, validate structured content, generate query access, and run local agent workflows before choosing a Studio plan.
- Add Studio when content becomes a team workflow: Studio becomes useful when editors, reviewers, and developers share responsibility for content. Workspaces, roles, structured views, chat-assisted operations, and Git-backed review give that team a common operating surface.
- Plans scale with AI, API, forms, media, and CDN usage: Paid plans include monthly allowances for AI messages, MCP calls, API messages, form submissions, CDN bandwidth, and media storage. Features and meters only apply where the plan and deployment expose the corresponding capability.
- Enterprise licensing is for controlled infrastructure: Enterprise is the custom path for organizations that need controlled deployment, tailored limits, SSO, white-label options, support, or separately licensed capabilities. Exact infrastructure and feature requirements should be confirmed during evaluation.
- Choose by workflow and usage, not by feature guesswork: Start with the local packages, add Studio when people need a shared workflow, and compare plans using seats, included usage, required capabilities, and deployment constraints.

FAQs:
- Can we start without paying? Yes. The MIT CLI, MCP, query SDK, rules, skills, and types packages support local development without a Studio subscription.
- How do we choose a Studio plan? Starter is $9 per month with 3 seats and lower included usage. Pro is $49 per month with 25 seats, higher limits, and advanced operations. Enterprise uses custom limits, deployment terms, and support.
- Are all Studio features available on every plan? No. Features such as media, CDN delivery, forms, webhooks, Conversation API, remote MCP, SSO, and model-scoped roles depend on plan, edition, provider, and deployment configuration.
### Bounded AI operations with Git as the audit layer
URL: https://contentrain.io/security
Category: product
Summary: Contentrain security is built around bounded agent operations, Git auditability, branch review, role-scoped Studio access, provider boundaries, encrypted keys, and self-managed deployment paths.

Key sections:
- Agents operate through bounded tools: Contentrain does not ask agents to freely mutate a repository. MCP tools define the allowed operations for status, content save, validation, scanning, normalize, branches, and bulk changes.
- Git is the audit layer: Content changes can be represented as commits, branches, and diffs. That means teams can inspect who changed content, what changed, and whether validation passed before production delivery.
- Studio adds role and model-level controls: Studio builds workspace and project permission context before exposing content operations. Workspace owners and admins manage membership; project editors, reviewers, and viewers receive role-specific access. Model-scoped restrictions are available on eligible plans.
- Secrets and provider boundaries stay explicit: Studio includes AI key management, encrypted key tests, provider abstractions, GitHub integration routes, and usage controls. Teams can choose managed agent paths or BYOA depending on their governance needs.
- Delivery surfaces are governed too: Where enabled, CDN, forms, webhooks, media, and Conversation API operations remain subject to the same project, provider, plan, and deployment boundaries as structured content work.
- Self-managed deployment is part of the security story: For infrastructure-sensitive teams, the value is not only features. It is the ability to keep governance close to the systems, providers, and policies the organization already controls.
- Responsible vulnerability disclosure: If you find a security issue in Contentrain's packages, Studio, or MCP Connector, we want to know. Email security@contentrain.io with details. We acknowledge within 2 business days, give a status update within 7 days, and target a fix within 30 days for confirmed issues. We ask for 90 days before public disclosure so we can ship the fix first.

FAQs:
- Does Contentrain let agents edit anything in the repo? No. The intended workflow is through bounded MCP and Studio tools, with validation, review branches, and explicit provider capabilities.
- How does Studio restrict users? Studio builds workspace, project, role, and model-level permission context before exposing content operations. Review and branch flows add another control layer.
- Can sensitive teams self-host? Yes. The Studio architecture supports self-managed deployment paths and enterprise licensing for teams that need more infrastructure control.
- How do I report a security vulnerability? Email security@contentrain.io with a description of the issue, reproduction steps, and potential impact. We acknowledge all reports within 2 business days, provide a status update within 7 days, and aim to ship a fix within 30 days for confirmed issues. We do not operate a public bug bounty program at this time, but we recognize researchers who report valid vulnerabilities with their consent.
- Do you have a responsible disclosure policy? Yes. We ask that you give us reasonable time to investigate and fix an issue before public disclosure (90 days is the standard). Please do not access, modify, or delete data that does not belong to you during research. We commit to not taking legal action against researchers acting in good faith under these guidelines.
### Run Contentrain Studio on infrastructure you control
URL: https://contentrain.io/self-hosted
Category: product
Summary: Run the AGPL Studio Community edition on infrastructure you control, keep content in Git, and add Enterprise terms or capabilities when organizational requirements call for them.

Key sections:
- Run the same Git-native operating model yourself: Self-hosting is valuable because the content model does not change. Studio still operates content through schemas, files, validation, branches, commits, and review paths.
- Own the infrastructure integrations: Studio uses provider contracts for authentication, database access, repositories, caching, and optional storage and media services. Self-managed teams can select and operate the integrations supported by their edition and deployment.
- Keep AI key strategy under your control: AI key ownership and managed usage depend on the selected edition and plan. Community deployments can use their supported provider-key path, while eligible managed or Enterprise deployments can expose additional key and usage controls.
- Choose Community or Enterprise terms for your requirements: Use the AGPL Community edition when its license and capabilities fit. Choose Enterprise when the organization needs separately licensed features, custom terms, support, or deployment assistance.
- Self-hosting still benefits from the MIT packages: The local packages remain useful even when Studio is self-managed. CLI, MCP, SDK, rules, and skills keep developer workflows portable across local development, CI, and hosted operations.

FAQs:
- Is self-hosting only for enterprise customers? No. The AGPL Studio core supports self-managed use, while commercial licensing is the path for teams that need enterprise terms, support, or licensed capabilities.
- Does self-hosting change the content format? No. The content remains Git-native JSON and Markdown governed by Contentrain schemas, validation, and generated access.
- Can self-hosted teams still use the open-source packages? Yes. The MIT packages are useful in local development and CI even when Studio runs in controlled infrastructure.
### The team operating surface for governed content in Git
URL: https://contentrain.io/studio
Category: product
Summary: Studio gives teams structured editing, chat-assisted content work, roles, and review over Git-backed projects. Media, CDN, forms, webhooks, APIs, and remote MCP appear when the edition, plan, provider, and deployment support them.

Key sections:
- A team surface over Git, not a separate content database: Studio operates structured content through a content engine that validates, serializes, branches, commits, and reviews files. The repository remains the audit layer while the app gives non-developers a usable workspace.
- Conversation-first content operations: Studio chat is not a generic prompt box. The server builds project and permission context, then filters the operations available to the user. Conversation history is part of Studio; external Conversation API access is available on eligible editions and plans.
- Roles, review, and branch health for teams: Studio adds workspace owner and admin controls plus project editor, reviewer, and viewer roles. Model-scoped access is available where the plan supports it, and branch health helps reviewers assess changes before merge.
- Add media and delivery operations when your deployment supports them: Studio can add asset management, media variants, CDN delivery, forms, submissions, and outbound webhooks to the same project workflow. These capabilities are conditional: availability depends on the Studio edition, workspace plan, provider facets, storage, and project configuration.
- Choose provider keys or managed AI usage where available: Studio supports deployment-specific AI key strategies and metered usage. Managed Studio keys, bring-your-own-key options, billing, and overages vary by edition and plan, so teams can choose the operating model their deployment supports.
- Start locally, add team operations when needed: Developers can begin with the MIT packages. Teams can then choose managed Studio or self-managed Community and Enterprise paths based on collaboration, infrastructure, support, and licensed-feature requirements, while content remains in Git.

FAQs:
- Is Studio required for Contentrain projects? No. Developers can initialize, validate, normalize, generate, and use the local MCP server with the MIT packages. Add Studio when content becomes a shared team workflow.
- When should a team add Studio? Add Studio when editors and reviewers need structured views, roles, branch review, and a shared workspace. Managed media, delivery, APIs, and remote MCP depend on the selected plan and deployment capabilities.
- Does Studio bypass Git? No. Studio is designed around Git-backed content files, commits, branches, diffs, validation, and the project's configured merge workflow.
### Start with structured content instead of scattered copy.
URL: https://contentrain.io/templates
Category: product
Summary: Starter templates pair modern frameworks with Contentrain content models, generated clients, and repeatable workflows.

Key sections:
- Templates start with content models, not placeholder pages: A useful starter should include the content contract from the first commit: models, sample content, generated client access, SEO fields, and review-ready structure. That prevents copy from scattering across components.
- Framework starters should match real delivery paths: Nuxt, Next, Astro, SvelteKit, VitePress, Expo, and Node projects all need different runtime patterns. Contentrain templates should show the correct query and generation approach for each framework rather than a generic CMS demo.
- Normalize makes legacy projects template-ready: For existing apps, the first template is often the current codebase after hardcoded strings are extracted. Normalize turns a messy project into a structure that can be reused for the next client or product.
- Studio templates make client handoff easier: Studio includes template creation and GitHub installation surfaces. Agencies and platform teams can use starters to create repeatable workspaces, then invite non-developers into a governed editing experience.
- The best templates become productized workflows: A template should not stop at a pretty homepage. It should encode the repeatable content lifecycle: model, write, validate, review, deliver, translate, and evolve with agent assistance.

FAQs:
- Are templates only for new projects? No. Existing projects can use Normalize first, then adopt the same model and SDK patterns that a starter would have provided from day one.
- What should a Contentrain template include? At minimum: models, seed content, SEO fields, generated client access, validation scripts, and clear paths for review and localization.
- Why are templates important for the business model? They convert open-source adoption into repeatable success. The more quickly teams get real content under governance, the more naturally Studio becomes valuable.
### Repeatable content infrastructure
URL: https://contentrain.io/solutions/agencies
Category: solution
Summary: Reuse models, Git workflows, and Studio review across client projects.

Key sections:
- Turn each client build into a repeatable content system: Agencies often rebuild the same content infrastructure for every client. Contentrain lets the team package models, seed content, generated access, and review workflows into reusable starters.
- Normalize legacy copy during redesigns: Client projects rarely start clean. Normalize can extract UI copy from existing code, create content entries, and prepare source patches so redesigns do not carry old hardcoded strings forward.
- Give clients Studio instead of repository access: Clients can change structured content in Studio without learning Git. Workspaces, projects, content panels, and review keep the repository workflow intact; media and forms are available when enabled for the client's plan and deployment.
- Use review workflows to protect delivery quality: Agencies can separate writing, review, and release without adding a heavy CMS migration. Branch health, diffs, validation, and reviewer roles make content changes safer near launch.
- Create a Studio upsell after the project launches: The MIT packages help agencies establish models and workflows inside each repository. Studio adds a shared client workspace for roles and review, with media, delivery, forms, and webhooks where enabled.

FAQs:
- How should agencies introduce Contentrain to clients? Use it first to structure content during the build, then introduce Studio as the client editing, review, and delivery surface after launch.
- Can one agency reuse a model across projects? Yes. Models, seed content, and framework integration patterns can become starter kits for similar clients.
- Does this replace client CMS projects? It can replace CMS work when the client needs Git-native content, AI governance, and structured review. For database-heavy editorial platforms, it can also coexist.
### Govern the content your AI ships
URL: https://contentrain.io/solutions/ai-native-teams
Category: solution
Summary: Turn AI-generated UI copy, docs, and locale strings into structured content you can review and reuse.

Key sections:
- AI-built apps create content faster than teams can govern it: Coding agents can generate pages, components, labels, docs, and localization candidates in minutes. Without a content system inside the repo, that copy becomes invisible product debt.
- Normalize turns agent output into structured content: The first move is not a CMS migration. Run Normalize against the codebase, approve what should become content, and generate access so future agents work with models instead of loose strings.
- Rules and skills give agents a shared playbook: Contentrain rules and skills explain schema, SEO, i18n, accessibility, validation, and workflow expectations in a way agents can follow. That reduces prompt drift across sessions and teammates.
- Studio adds human approval when the team grows: A solo developer can start locally. Teams can add Studio for content review, roles, and branch health, with media and delivery operations available when the plan and deployment support them.
- The result is faster AI work with fewer uncontrolled changes: Agents still generate and modify content quickly, but the operating path is visible: models, validation, branches, review, and runtime access. That is the difference between acceleration and entropy.

FAQs:
- Why do AI-native teams need a content layer? Because AI agents create copy constantly. A content layer makes that output reviewable, reusable, localizable, and visible to future agents.
- Should the first CTA be Studio or init? Start with npx contentrain init when the content problem is already inside the codebase. Add Studio when editors, reviewers, or governed team operations enter the workflow.
- Can agents use Studio too? Yes. Studio exposes governed content operations and conversation paths, while local MCP covers developer-side workflows.
### Let non-developers edit without losing Git control
URL: https://contentrain.io/solutions/content-teams
Category: solution
Summary: Editors work in Studio. Developers keep branches, diffs, validation, and source-of-truth control.

Key sections:
- Content teams need access without breaking the Git workflow: Non-developers should be able to change structured content, but product teams still need schemas, validation, diffs, and approval. Studio sits between those needs.
- Structured views match the content type: Studio includes collection, document, dictionary, singleton, vocabulary, and content panel surfaces. Editors do not need to know the file layout to work within the model.
- Reviewers see the change, not just the final page: Branch detail, diff, branch health, moderation, and review flows make content approval concrete. Teams can reject, merge, or continue work with the content state still represented in Git.
- Keep eligible media and delivery work beside structured content: Content teams often manage images, forms, submissions, webhooks, and delivery rules alongside text. Studio can bring those operations into the same workspace when the required plan, edition, storage, and project settings are enabled.
- AI assists inside controlled boundaries: The chat panel can help content teams change structured content, but the server builds permission and project context before tools are available. That keeps AI assistance attached to governance.

FAQs:
- Can non-developers use Contentrain? Yes, through Studio. The local packages are developer-first, while Studio provides the editor and reviewer experience for content teams.
- Does Studio remove engineering review? No. It gives content teams a usable interface while preserving branch, diff, validation, and merge workflows for controlled release.
- What content types can Studio manage? Studio supports collections, documents, dictionaries, singletons, and vocabulary. Media, forms, submissions, webhooks, and delivery configuration appear when the edition, plan, and deployment enable them.
### One content contract for web, mobile and APIs
URL: https://contentrain.io/solutions/platform-teams
Category: solution
Summary: Deliver structured content to web, docs, mobile, and APIs from the same Git-backed system.

Key sections:
- Standardize content as a platform contract: Platform teams need one content shape across product surfaces, not a CMS integration per app. Contentrain keeps models, content, validation, context, and generated access in a portable repository contract.
- Serve web, docs, mobile, and backend consumers: The query SDK and generated clients let frontend and backend systems consume the same content without each team inventing parsing logic. Eligible Studio plans and deployments add CDN and API delivery for runtimes that need it.
- Give agents the same platform rules as developers: MCP tools, rules, skills, and context files make the content platform understandable to coding agents. That matters when agents are creating components, docs, localization files, and content migrations.
- Centralize governance in Studio when teams scale: As more teams publish content, platform owners need roles, review, branch health, and usage visibility. Studio provides those controls, with model-scoped access, media, CDN, forms, and webhooks available according to plan and deployment.
- Avoid locking the platform to one vendor runtime: Because content state stays in Git and access can be generated, the platform can evolve across frameworks and deployment targets. Studio adds services without making content invisible to the codebase.

FAQs:
- Why should platform teams care about Contentrain? It creates a shared content contract that developers, agents, editors, and delivery systems can all use without hiding state inside a remote-only CMS.
- Can one Contentrain project serve multiple apps? Yes. The model and generated access patterns are designed for shared content across web, docs, mobile, backend, and delivery surfaces.
- Where does Studio fit for platform teams? Studio becomes the control plane for permissions, review, and team operations. Media, delivery, forms, webhooks, APIs, and usage controls appear when the plan and deployment enable them.
### Give AI agents bounded content operations
URL: https://contentrain.io/use-cases/ai-content-governance
Category: use-case
Summary: Agents can create, update, translate, search, and validate content through deterministic tools instead of editing source strings directly.

Key sections:
- AI content needs an operating boundary: If agents can freely edit copy, schemas, translations, and docs, quality depends on prompts alone. Contentrain gives agents tools, rules, validation, and review paths that define acceptable operations.
- Make project context visible to the agent: The .contentrain project files describe models, context, vocabulary, content, and metadata in the repo. Agents can inspect the content system before they generate or modify product copy.
- Use rules for quality, not taste: The rules package covers content quality, SEO, i18n, accessibility, media, schema, security, normalize, and workflow expectations. That turns subjective review into repeatable checks.
- Require human review for production changes: Content governance is not complete until humans can approve important changes. Studio branch review, diff views, roles, and branch health checks make that possible for AI-assisted content.
- Govern the whole content lifecycle: The same governed model covers extraction, writing, translation, and review. Studio can extend it to media, delivery, forms, webhooks, and external APIs when those capabilities are enabled.

FAQs:
- What is AI content governance? It is the system of tools, rules, validation, permissions, and review workflows that controls how AI creates or changes product content.
- Why is Git important for governance? Git gives content changes history, diffs, branches, and review habits that engineering teams already trust.
- Can governance start locally? Yes. The MIT packages let a developer start with local MCP, rules, validate, normalize, and generated access before Studio is needed.
### Use Git as the storage and audit layer for content
URL: https://contentrain.io/use-cases/git-native-cms
Category: use-case
Summary: Content stays in your repository as JSON and Markdown. Branches, commits, diffs, and merge rules remain visible.

Key sections:
- Git can be the content storage and audit layer: Contentrain stores structured content as files that developers, agents, CI, and reviewers can inspect. The CMS behavior comes from models, validation, generated access, and Studio operations around those files.
- Models make files safe to edit: A Git-native CMS still needs structure. Contentrain models define required fields, field types, i18n behavior, and content kinds so file-based content does not become arbitrary JSON.
- Generated SDK access removes parsing work: Applications should not hand-roll file parsing for content. The SDK generates query access so frameworks can consume content predictably across locales and build modes.
- Studio adds the missing non-developer workflow: Git alone is not enough for every content team. Studio adds structured editing, chat-assisted operations, roles, and review, with media and delivery surfaces available where enabled.
- You keep the exit option: Because content remains in the repository, teams are not locked into a proprietary database to access their own content. Studio adds convenience and delivery without hiding the underlying state.

FAQs:
- Is Git enough for non-developers? Not by itself. That is why Studio exists: it gives non-developers a usable interface while preserving Git-backed review and validation.
- How is this different from a headless CMS? Contentrain starts from repository-native content and AI-agent workflows, then adds Studio for teams. Many headless CMS products start from a hosted content database.
- Can content still be delivered through an API? Yes. Eligible Studio plans and deployments can add CDN and API surfaces when runtime delivery is needed.
### Extract hardcoded UI strings before they become product debt
URL: https://contentrain.io/use-cases/hardcoded-strings
Category: use-case
Summary: Find strings across components, classify them, create content models, and prepare translation-ready output in Git.

Key sections:
- Hardcoded strings are invisible content debt: AI coding tools make this worse by producing labels, headings, empty states, validation text, and marketing copy directly inside components. The product ships faster, but future edits become scattered source changes.
- Scan the source before choosing a model: Contentrain MCP scan can inspect candidate strings and source graph context. That lets the team decide what belongs in dictionaries, collections, documents, or singleton content instead of guessing.
- Extract strings into governed content entries: Approved strings are written as Contentrain content with source tracking. The source remains unchanged during extraction, which makes the content branch easier to review.
- Patch source only after content is ready: Reuse patches replace hardcoded values with generated content access. This makes the code cleaner while keeping the migration reviewable.
- Unlock localization and team review: Once strings live in content files, locale parity, translation, SEO quality, and content approval can be managed as content workflows instead of source hunts.

FAQs:
- Is this only for localization? No. Localization is one benefit, but the broader value is making UI text editable, reviewable, reusable, and visible to agents.
- Can I extract everything at once? You can scan broadly, but high-quality adoption usually starts with meaningful product surfaces: navigation, onboarding, empty states, CTAs, and repeated UI labels.
- What prevents unsafe source patches? Normalize separates extraction from reuse, validates inputs, checks conflicts, and keeps changes reviewable before they are applied.
### Make localization a content workflow, not grep-and-replace
URL: https://contentrain.io/use-cases/localization
Category: use-case
Summary: Extract strings into locale-aware models, copy locales, translate content, and keep parity visible through validation and health checks.

Key sections:
- Localization fails when strings stay in source files: If UI text is scattered through components, translation work becomes source editing. Contentrain moves those strings into locale-aware content files where validation and review can happen normally.
- Choose the right model for each language asset: Short labels often fit dictionaries, pages fit documents or collections, and global UI settings fit singletons. Contentrain lets the model reflect the content type instead of forcing every string into one table.
- Validate locale parity and required fields: Translation quality starts with knowing what is missing. Contentrain validation detects required field issues and i18n parity problems so teams do not discover gaps in production.
- Let agents translate inside a governed workflow: Agent-assisted translation is useful only when the agent sees the schema, context, and vocabulary. Contentrain rules and skills provide that context before localized content is written.
- Studio gives translators and reviewers a surface: When localization involves non-developers, Studio can provide content editing, branch review, role controls, and media context without requiring translators to work directly in Git.

FAQs:
- Can Contentrain manage multiple locales? Yes. Models and content are locale-aware, and validation can catch structural and parity issues across locales.
- Should we translate before or after Normalize? For hardcoded UI text, normalize first. Once strings are content, translation can happen with better context and review.
- Can AI help with translations? Yes, but the key is governance: agents should use project context, vocabulary, schema rules, and review workflows rather than translating disconnected strings.
### Contentrain vs Contentful
URL: https://contentrain.io/compare/contentful
Category: comparison
Summary: Compare Contentful's proprietary cloud database approach with Contentrain's Git-native content governance layer for AI-native teams.

Key sections:
- The default model is different from Contentful: Contentful is usually adopted as a central content platform. Contentrain starts inside the repository, where schemas, JSON, Markdown, generated SDK access, and review branches are visible to the same agents and developers changing the product.
- AI agents need content context, not just an API token: Contentrain exposes the content system through deterministic MCP tools, rules, and skills. Agents can inspect models, validate content, normalize hardcoded strings, and prepare reviewable changes without guessing how the CMS works.
- Review happens in Git before content reaches production: Every content change can be represented as files, diffs, branches, and commits. That makes product copy, localized strings, documents, and model edits auditable with the review habits engineering teams already trust.
- Where Contentful can still be the right choice: Contentful can fit teams that want a mature standalone CMS as the primary editorial database. Contentrain fits better when the product team wants Git, AI agents, local tooling, and Studio review to share one content contract.
- The migration path starts with the code you already have: You do not need to remodel every content operation on day one. Start by running Normalize on hardcoded strings, generate a typed client, then move the workflows that need team review into Studio.

Decision matrix:
- Source of truth: Choose Contentrain when code, content, and agent context need to be reviewed together.
- AI agent workflow: Choose Contentrain when AI coding agents are part of the daily content workflow.
- Best starting point: Choose Contentrain when the first problem is AI-generated UI copy already inside the codebase.
- Human review: Choose Contentrain when engineering and content approval should share one audit layer.
- Best fit: Use the tool whose operating model matches the team, not only the feature checklist.

FAQs:
- Is Contentrain a drop-in replacement for Contentful? Not usually. Contentrain is a Git-native content governance system for AI-native product teams. It can replace CMS workflows that benefit from files, branches, validation, and agent-readable context.
- Can we use Contentrain alongside Contentful? Yes. Many teams can start by governing UI copy, docs, localized strings, or AI-generated content in Contentrain while keeping existing editorial systems where they already work.
- What is the strongest reason to choose Contentrain? Choose Contentrain when your content changes are tightly coupled to code, AI agents, review branches, typed runtime access, and platform-independent delivery.
### Contentrain vs Directus
URL: https://contentrain.io/compare/directus
Category: comparison
Summary: Compare Directus's sql database approach with Contentrain's Git-native content governance layer for AI-native teams.

Key sections:
- The default model is different from Directus: Directus is usually adopted as a central content platform. Contentrain starts inside the repository, where schemas, JSON, Markdown, generated SDK access, and review branches are visible to the same agents and developers changing the product.
- AI agents need content context, not just an API token: Contentrain exposes the content system through deterministic MCP tools, rules, and skills. Agents can inspect models, validate content, normalize hardcoded strings, and prepare reviewable changes without guessing how the CMS works.
- Review happens in Git before content reaches production: Every content change can be represented as files, diffs, branches, and commits. That makes product copy, localized strings, documents, and model edits auditable with the review habits engineering teams already trust.
- Where Directus can still be the right choice: Directus can fit teams that want a mature standalone CMS as the primary editorial database. Contentrain fits better when the product team wants Git, AI agents, local tooling, and Studio review to share one content contract.
- The migration path starts with the code you already have: You do not need to remodel every content operation on day one. Start by running Normalize on hardcoded strings, generate a typed client, then move the workflows that need team review into Studio.

Decision matrix:
- Source of truth: Choose Contentrain when code, content, and agent context need to be reviewed together.
- AI agent workflow: Choose Contentrain when AI coding agents are part of the daily content workflow.
- Best starting point: Choose Contentrain when the first problem is AI-generated UI copy already inside the codebase.
- Human review: Choose Contentrain when engineering and content approval should share one audit layer.
- Best fit: Use the tool whose operating model matches the team, not only the feature checklist.

FAQs:
- Is Contentrain a drop-in replacement for Directus? Not usually. Contentrain is a Git-native content governance system for AI-native product teams. It can replace CMS workflows that benefit from files, branches, validation, and agent-readable context.
- Can we use Contentrain alongside Directus? Yes. Many teams can start by governing UI copy, docs, localized strings, or AI-generated content in Contentrain while keeping existing editorial systems where they already work.
- What is the strongest reason to choose Contentrain? Choose Contentrain when your content changes are tightly coupled to code, AI agents, review branches, typed runtime access, and platform-independent delivery.
### Contentrain vs Payload
URL: https://contentrain.io/compare/payload
Category: comparison
Summary: Compare Payload's database-backed application approach with Contentrain's Git-native content governance layer for AI-native teams.

Key sections:
- The default model is different from Payload: Payload is usually adopted as a central content platform. Contentrain starts inside the repository, where schemas, JSON, Markdown, generated SDK access, and review branches are visible to the same agents and developers changing the product.
- AI agents need content context, not just an API token: Contentrain exposes the content system through deterministic MCP tools, rules, and skills. Agents can inspect models, validate content, normalize hardcoded strings, and prepare reviewable changes without guessing how the CMS works.
- Review happens in Git before content reaches production: Every content change can be represented as files, diffs, branches, and commits. That makes product copy, localized strings, documents, and model edits auditable with the review habits engineering teams already trust.
- Where Payload can still be the right choice: Payload can fit teams that want a mature standalone CMS as the primary editorial database. Contentrain fits better when the product team wants Git, AI agents, local tooling, and Studio review to share one content contract.
- The migration path starts with the code you already have: You do not need to remodel every content operation on day one. Start by running Normalize on hardcoded strings, generate a typed client, then move the workflows that need team review into Studio.

Decision matrix:
- Source of truth: Choose Contentrain when code, content, and agent context need to be reviewed together.
- AI agent workflow: Choose Contentrain when AI coding agents are part of the daily content workflow.
- Best starting point: Choose Contentrain when the first problem is AI-generated UI copy already inside the codebase.
- Human review: Choose Contentrain when engineering and content approval should share one audit layer.
- Best fit: Use the tool whose operating model matches the team, not only the feature checklist.

FAQs:
- Is Contentrain a drop-in replacement for Payload? Not usually. Contentrain is a Git-native content governance system for AI-native product teams. It can replace CMS workflows that benefit from files, branches, validation, and agent-readable context.
- Can we use Contentrain alongside Payload? Yes. Many teams can start by governing UI copy, docs, localized strings, or AI-generated content in Contentrain while keeping existing editorial systems where they already work.
- What is the strongest reason to choose Contentrain? Choose Contentrain when your content changes are tightly coupled to code, AI agents, review branches, typed runtime access, and platform-independent delivery.
### Contentrain vs Sanity
URL: https://contentrain.io/compare/sanity
Category: comparison
Summary: Compare Sanity's content lake and groq approach with Contentrain's Git-native content governance layer for AI-native teams.

Key sections:
- The default model is different from Sanity: Sanity is usually adopted as a central content platform. Contentrain starts inside the repository, where schemas, JSON, Markdown, generated SDK access, and review branches are visible to the same agents and developers changing the product.
- AI agents need content context, not just an API token: Contentrain exposes the content system through deterministic MCP tools, rules, and skills. Agents can inspect models, validate content, normalize hardcoded strings, and prepare reviewable changes without guessing how the CMS works.
- Review happens in Git before content reaches production: Every content change can be represented as files, diffs, branches, and commits. That makes product copy, localized strings, documents, and model edits auditable with the review habits engineering teams already trust.
- Where Sanity can still be the right choice: Sanity can fit teams that want a mature standalone CMS as the primary editorial database. Contentrain fits better when the product team wants Git, AI agents, local tooling, and Studio review to share one content contract.
- The migration path starts with the code you already have: You do not need to remodel every content operation on day one. Start by running Normalize on hardcoded strings, generate a typed client, then move the workflows that need team review into Studio.

Decision matrix:
- Source of truth: Choose Contentrain when code, content, and agent context need to be reviewed together.
- AI agent workflow: Choose Contentrain when AI coding agents are part of the daily content workflow.
- Best starting point: Choose Contentrain when the first problem is AI-generated UI copy already inside the codebase.
- Human review: Choose Contentrain when engineering and content approval should share one audit layer.
- Best fit: Use the tool whose operating model matches the team, not only the feature checklist.

FAQs:
- Is Contentrain a drop-in replacement for Sanity? Not usually. Contentrain is a Git-native content governance system for AI-native product teams. It can replace CMS workflows that benefit from files, branches, validation, and agent-readable context.
- Can we use Contentrain alongside Sanity? Yes. Many teams can start by governing UI copy, docs, localized strings, or AI-generated content in Contentrain while keeping existing editorial systems where they already work.
- What is the strongest reason to choose Contentrain? Choose Contentrain when your content changes are tightly coupled to code, AI agents, review branches, typed runtime access, and platform-independent delivery.
### Contentrain vs Strapi
URL: https://contentrain.io/compare/strapi
Category: comparison
Summary: Compare Strapi's relational database approach with Contentrain's Git-native content governance layer for AI-native teams.

Key sections:
- The default model is different from Strapi: Strapi is usually adopted as a central content platform. Contentrain starts inside the repository, where schemas, JSON, Markdown, generated SDK access, and review branches are visible to the same agents and developers changing the product.
- AI agents need content context, not just an API token: Contentrain exposes the content system through deterministic MCP tools, rules, and skills. Agents can inspect models, validate content, normalize hardcoded strings, and prepare reviewable changes without guessing how the CMS works.
- Review happens in Git before content reaches production: Every content change can be represented as files, diffs, branches, and commits. That makes product copy, localized strings, documents, and model edits auditable with the review habits engineering teams already trust.
- Where Strapi can still be the right choice: Strapi can fit teams that want a mature standalone CMS as the primary editorial database. Contentrain fits better when the product team wants Git, AI agents, local tooling, and Studio review to share one content contract.
- The migration path starts with the code you already have: You do not need to remodel every content operation on day one. Start by running Normalize on hardcoded strings, generate a typed client, then move the workflows that need team review into Studio.

Decision matrix:
- Source of truth: Choose Contentrain when code, content, and agent context need to be reviewed together.
- AI agent workflow: Choose Contentrain when AI coding agents are part of the daily content workflow.
- Best starting point: Choose Contentrain when the first problem is AI-generated UI copy already inside the codebase.
- Human review: Choose Contentrain when engineering and content approval should share one audit layer.
- Best fit: Use the tool whose operating model matches the team, not only the feature checklist.

FAQs:
- Is Contentrain a drop-in replacement for Strapi? Not usually. Contentrain is a Git-native content governance system for AI-native product teams. It can replace CMS workflows that benefit from files, branches, validation, and agent-readable context.
- Can we use Contentrain alongside Strapi? Yes. Many teams can start by governing UI copy, docs, localized strings, or AI-generated content in Contentrain while keeping existing editorial systems where they already work.
- What is the strongest reason to choose Contentrain? Choose Contentrain when your content changes are tightly coupled to code, AI agents, review branches, typed runtime access, and platform-independent delivery.

## Playbooks

### Govern AI agents that create and edit product content
URL: https://contentrain.io/playbooks/ai-agent-content-governance
Audience: AI-native product teams, platform teams, and founders using coding agents.
Outcome: Agents can inspect models, normalize strings, change content, validate work, and hand off reviewable branches without bypassing human approval.

Steps:
1. Initialize Contentrain: Create the local content contract so agents can see models, context, and content state. Command: npx contentrain init
2. Run scan before extraction: Use scan summary, graph, and candidates to understand what text is in source files before approving content changes. Command: contentrain scan --mode summary
3. Extract before reuse: Write approved content entries first, then patch source code after review. Command: contentrain normalize extract
4. Validate before handoff: Run validation so schema, required fields, i18n parity, and structural issues are caught early. Command: contentrain validate
5. Move collaboration into Studio: Use Studio when non-developers, reviewers, roles, media, or delivery surfaces enter the workflow.

Checklist:
- Agent permissions
  - Define which tools the agent can call
  - Keep destructive changes out of default flows
  - Require validation output in handoff notes
- Content quality
  - Use one H1 per page
  - Keep titles and meta descriptions unique
  - Add FAQs and extractable answer sections
- Studio handoff
  - Assign editor and reviewer roles
  - Review branch health
  - Use media and CDN settings inside the same project
### Give editors Studio workflows without losing Git control
URL: https://contentrain.io/playbooks/content-editor-workflow
Audience: Content teams, agencies, and product teams that need non-developer content access.
Outcome: Editors can change content through Studio, reviewers can approve branches, and engineering keeps Git as the audit and delivery boundary.

Steps:
1. Connect a repository project: Create or connect the Studio project so it can read models, content, and branch state.
2. Invite editors and reviewers: Assign roles based on who can write, review, and approve content.
3. Use structured editing: Let editors work through model-aware views instead of raw files.
4. Review branch changes: Approve content only after diff and validation checks are clear.
5. Deliver content: Use generated app access, CDN, or APIs depending on the runtime need.

Checklist:
- Editor readiness
  - Models use editor-friendly field names
  - SEO fields are part of page content
  - Media fields have clear usage
- Review readiness
  - Reviewer roles assigned
  - Branch health visible
  - Approval criteria documented
- Delivery readiness
  - CDN/API strategy chosen
  - Forms and webhooks configured if needed
  - Rollback path understood
### Implement Git-native content in a modern app
URL: https://contentrain.io/playbooks/developer-implementation
Audience: Developers and platform engineers adding governed content to product codebases.
Outcome: The app consumes content through generated access, validates content in the repo, and can graduate to Studio without changing the content contract.

Steps:
1. Initialize the project: Create .contentrain with config, context, vocabulary, models, and content directories. Command: npx contentrain init
2. Create models: Define the content shapes your app actually needs: dictionaries, singletons, collections, and documents.
3. Add content entries: Use MCP content save or Studio to create model-valid content instead of editing JSON by hand.
4. Generate runtime client: Generate query modules and import them from application code. Command: contentrain generate
5. Validate and build: Run validation and the app build together so content and UI fail as one product. Command: contentrain validate && pnpm build

Checklist:
- Repository setup
  - Scripts for generate and validate exist
  - Content files are reviewed like code
  - Agents can read context and model files
- Runtime setup
  - No ad hoc JSON parsing in components
  - SEO fields exist on page models
  - Images have meaningful adjacent text
- Launch setup
  - Sitemap includes content routes
  - Canonical URLs are set
  - Build prerenders important pages
### Migrate hardcoded strings into governed content
URL: https://contentrain.io/playbooks/normalize-migration
Audience: Developers cleaning up AI-built apps, agencies modernizing client sites, and teams preparing for localization.
Outcome: Hardcoded strings become structured, reviewable, localizable content without a risky rewrite.

Steps:
1. Run a scan summary: Estimate the amount and location of hardcoded strings. Command: contentrain scan --mode summary
2. Review candidates: Choose strings that are product content, not implementation details.
3. Extract approved strings: Save entries into dictionaries, pages, or collections through Contentrain.
4. Generate client access: Regenerate the query client after content changes. Command: contentrain generate
5. Apply reuse patches: Patch source files only after the content shape is validated.

Checklist:
- Do extract
  - Navigation labels
  - CTA copy
  - Empty states
  - Validation messages
  - Landing page sections
- Do not extract blindly
  - Debug strings
  - Internal constants
  - Class names
  - Test-only fixtures
- Validate outcome
  - No broken imports
  - No missing locale fields
  - Page content still fits UI containers
### Adopt Studio when content work becomes a team operation
URL: https://contentrain.io/playbooks/studio-adoption
Audience: Founders, product teams, agencies, and platform teams deciding when Studio should become the operating surface.
Outcome: The team understands when to stay local, when to add managed Studio, and when Community or Enterprise self-managed deployment better fits its requirements.

Steps:
1. Prove local value: Use CLI, MCP, SDK, rules, and skills to govern content inside one repo.
2. Identify team triggers: Look for editors, reviewers, media needs, runtime delivery, forms, webhooks, or usage reporting, then verify plan and deployment support.
3. Start Studio workspace: Create workspaces and projects for the repositories that need collaboration.
4. Set roles and review rules: Assign editor and reviewer roles before opening content operations broadly.
5. Choose SaaS or self-managed: Use SaaS for speed and self-managed licensing for controlled infrastructure.

Checklist:
- SaaS fit
  - Team wants hosted operations
  - Studio URL can be used directly
  - Managed billing and usage are acceptable
- Enterprise fit
  - Infrastructure must be controlled
  - Commercial license terms are needed
  - Support and deployment requirements matter
- Expansion fit
  - More repositories need governance
  - Content delivery volume grows
  - AI-assisted workflows need monitoring