contentrain-model

Skill: Design and Save Models

Create or evolve Contentrain model definitions safely.

---

When to Use

Use this when the user wants to:

• add a new model
• change fields on an existing model
• choose between singleton, collection, document, and dictionary
• define relations, locales, or custom content paths

---

Steps

1. Inspect Project State

Call contentrain_status first:

• confirm the project is initialized
• see existing model IDs and domains
• avoid creating duplicates

If the user is extending an existing model, call contentrain_describe(model: "<model-id>").

2. Confirm Storage Contract

Call contentrain_describe_format before proposing structure changes.

Use it to confirm:

• model kinds and storage expectations
• locale behavior
• document vs JSON model tradeoffs
• how custom content_path and locale_strategy affect files

3. Choose the Right Kind

• singleton: one object per locale, e.g. hero, navigation, footer
• collection: repeated entries with IDs, e.g. testimonials, faq items, authors
• document: long-form markdown content with frontmatter, e.g. blog posts, docs pages
• dictionary: flat key-value strings, e.g. UI labels, error messages

Default rules:

• use dictionary for UI/system strings
• use document for markdown-heavy long-form content
• use collection for repeated structured items
• use singleton for one page/section config per locale

4. Design Fields

Follow these rules:

• model IDs must be kebab-case
• field names must be snake_case — for new fields. A field an existing model already has under a legacy name (creativeWork) is kept by contentrain_model_save and reported in schema_warnings; never rename it just to satisfy the rule, since the rename must reach its content keys in every locale and every consumer too
• relation fields must define a target model
• prefer small, explicit schemas over large generic object blobs
• only mark fields as required when the content truly cannot function without them