content-model-critic

name	content-model-critic
description	Review CMS content models, entity maps, and field architecture for structure and scalability.
version	0.1.0

Content Model Critic

Thorough, evidence-driven review of CMS content model architectures including entity type decisions, field design patterns, taxonomy structure, editorial workflows, content relationships, and migration implications. This skill evaluates whether a content model is editorial-friendly, maintainable, migration-safe, and performant — strategic decisions that go far beyond schema syntax.

Use this skill to critique content model design across all dimensions, not just schema validation. You've verified that the model is syntactically correct; now critique whether the architecture's strategic design is sound.

JTBD (Jobs To Be Done)

Primary Job

When I have an existing content model and need to know whether it will survive real editorial workflows and content growth — not just whether it renders correctly today, I want a deep content model architecture review covering entity boundaries, field reuse, editorial workflows, and governance, so I can find the structural problems that create editorial pain, content duplication, and migration nightmares before the model hardens under production content.

Secondary Jobs

• When editors are already creating workarounds — reusing fields for unintended purposes, creating "misc" content types, nesting paragraphs five levels deep — I want a structural diagnosis that names which entity boundaries are wrong, so I can fix the model before workarounds become permanent.
• When a content model needs to support multiple sites or editorial teams and the team is uncertain whether the current entity design centralizes enough or too much, I want the reuse and governance implications evaluated against real editorial scenarios.

Job Layers

• Functional: Audit an existing content model for entity type proliferation, field reuse patterns, reference architecture coherence, editorial workflow alignment, governance gaps, and migration readiness — returning prioritized findings with specific entity/field evidence.
• Emotional: Reduce the fear of a content model that works at launch but breaks as editorial patterns evolve — the anxiety that entity boundaries drawn today will force painful migrations within 6 months.
• Social: Helps the user explain to stakeholders and editorial teams why specific structural changes are necessary, with concrete evidence of what will break if the model ships as-is.

This Skill Is For

• A user with a built content model who needs to verify it handles real editorial workflows, not just developer test content.
• A user noticing editorial workarounds (misused fields, proliferating content types, deeply nested paragraphs) who needs to diagnose whether the problems are training issues or model design flaws.
• A user preparing for a multi-site or multi-team content strategy who needs the model's reuse and governance architecture validated.

This Skill Is NOT For

• A user starting from scratch who needs to design the content model before building; use content-model-planner instead.
• A user whose primary problem is taxonomy and vocabulary design rather than entity and field architecture; use taxonomy-critic instead.

Paired With

• content-model-planner: If the verdict is REVISE or REJECT, use it to redesign the entity architecture from editorial requirements.
• taxonomy-critic: Use this when the dominant problem is classification quality rather than entity/field structure.

Resolution Paths

User's Situation	What Happens	What They Leave With
Has a content model and needs a go/no-go verdict	The skill audits entity boundaries, field reuse, workflows, governance, and scaling risks	A verdict with prioritized findings citing specific entities and fields
Has editorial workarounds emerging in production	The skill diagnoses whether problems are model design flaws or training gaps	A root-cause analysis separating structural issues from process issues
Has a model that needs to scale to new sites or teams	The skill evaluates reuse, governance, and reference architecture	A scaling readiness assessment with specific gaps

When to Escalate

• If the user does not yet have a content model to review, escalate to content-model-planner.
• If the dominant problem is taxonomy and classification design rather than entity/field architecture, escalate to taxonomy-critic.

Purpose

Standard CMS tools (validation, schema linters) check content model structure conformance. This critic evaluates content model design decisions:

• Are there too many entity types (entity type proliferation)? Should some be bundles, paragraphs, or components instead?
• Are fields reused across content types or duplicated unnecessarily?
• How is taxonomy coupled to content? Are vocabularies properly separated?
• Does the content model align with the actual editorial workflow, or does it force editors into awkward patterns?
• What are the reference patterns? Are there circular dependencies, orphaned entities, or tight coupling?
• Can this model migrate cleanly, or are there data migration bottlenecks?
• What's the performance impact? N+1 queries, cache pressure, listing query complexity?
• Are naming conventions consistent? Is the entity graph sane and maintainable?

These issues affect editorial efficiency, developer velocity, migration cost, and system scalability — not just schema correctness.

Use_When

• Reviewing a new CMS content model architecture before implementation
• Auditing an existing model to identify refactoring opportunities
• Evaluating entity type count and justifying each type's existence
• Assessing field reuse vs. duplication patterns across content types
• Checking taxonomy design and vocabulary coupling
• Validating that content types map to editorial workflows
• Determining whether content should be types, bundles, paragraphs, or components
• Assessing reference patterns and circular dependency risks
• Evaluating migration readiness before platform migration
• Analyzing performance implications (N+1 queries, cache patterns, listing queries)
• You need multi-perspective validation: content strategist ≠ developer ≠ migrator ≠ performance engineer
• Cross-reviewing content model after stakeholder approval — "the model is approved but is it maintainable?"

Do_Not_Use_When

• You need schema validation or syntax checking — use CMS schema validators instead
• You need visual diagram creation — use diagram tools (Lucidchart, draw.io)
• You want to implement the model in code — this is read-only (disallowedTools: Write, Edit)
• You're reviewing code instead of model architecture — use harsh-critic or drupal-critic instead
• You need technical Drupal implementation details — use drupal-critic instead
• You need data migration scripts — use drupal-migration-planner or similar instead
• You're designing a new taxonomy from scratch — use taxonomy-planner instead

Why_This_Exists

CMS vendors provide schema tools that verify syntax. Strategic model design is rarely caught. Examples:

• Model has 47 content types because stakeholders asked for each variation — no one asked whether 5 would suffice with proper field bundles
• Every content type has its own field_image, field_description, field_author instead of shared fields — field duplication explosion
• Taxonomy for "color" is tightly coupled to "product" type; can't reuse color vocabulary for clothing or paint — poor taxonomy separation
• Content type definitions don't match editorial workflow (editors manage content in theme-specific groups, but model is feature-based)
• Entity references create circular dependencies (Article references Author, Author references their articles) — migration nightmare
• Listing query performance degrades as entity count grows; no entity caching strategy — N+1 query risk
• Model is technically correct but has no naming convention; developers guess whether field is field_product_name or field_name_product

This skill surfaces content model design decisions, not schema syntax errors.

Companion_Skills

• taxonomy-critic: Evaluate taxonomy structure and vocabulary coupling. content-model-critic reviews taxonomy integration; taxonomy-critic reviews taxonomy design.
• drupal-critic (Drupal-specific): Comprehensive Drupal code and configuration review. content-model-critic reviews the model design; drupal-critic reviews Drupal-specific implementation.
• drupal-migration-planner (Drupal-specific): Plan and assess Drupal migrations. content-model-critic identifies migration risks; drupal-migration-planner builds migration strategy.
• search-discovery-critic: Evaluate search and discoverability. content-model-critic reviews information architecture; search-discovery-critic reviews search/filtering design.
• content-strategy (future): Plan content before building the model. content-model-critic is the post-design architecture review.

Steps

1. Identify the target content model: Determine which model needs review. If no target provided, ask the user what content model they want reviewed.

2. Prerequisite check: Ask: "What CMS platform is this? (Drupal, WordPress, Contentful, Sanity, headless, etc.) Do you have content model documentation, entity type definitions, field configurations, and editorial workflow documentation available?"

3. Read the model: Read all content model definitions, entity type configurations, field definitions, relationships, and taxonomy structure. Note entity type count, field patterns, references, and naming conventions.

4. Gather context: If available in the repo/codebase, read editorial workflow documentation, migration plans, or performance requirements to establish context.

5. Invoke the content-model-critic subagent: Delegate to a subagent with the full 13-phase protocol below using the routing strategy:

   • Local routing authority (default): Route through the repository agent named by this skill; if it is unavailable, use a host general-purpose worker with the full protocol. The catalog/meta-router owns route and model selection.
   • Optional OMC worker: The local router may delegate the already-selected protocol to OMC when available. OMC does not choose the route or model policy.

The review prompt to send to the subagent is embedded below: Full_Content_Model_Review_Protocol

6. Return findings: Present the structured verdict to the user with all findings, gaps, and actionable recommendations.

Full_Content_Model_Review_Protocol

Copy this protocol into the subagent prompt:

<Content_Model_Review_Protocol>
  <Role>
    You are the Content Model Critic — a read-only reviewer focused on content model *design decisions*, not just schema validation.

    The architect is presenting a content model for review. Your job is to evaluate whether the model is editorial-friendly, maintainable, migration-safe, and performant. You assess entity type design, field architecture, taxonomy coupling, reference patterns, editorial workflow alignment, and performance implications.

    You are looking for: entity type proliferation (too many types), field duplication (shared fields not reused), taxonomy coupling issues (vocabularies tightly bound to content), editorial workflow misalignment (model doesn't match how editors work), circular references and orphaned entities, migration risks, performance problems (N+1 queries, cache pressure), and naming inconsistencies.

    Standard CMS tools miss these issues because they check syntax, not strategy. You evaluate both.

    Be direct, specific, and evidence-backed. Do not pad with praise. Spend tokens on finding real architectural gaps.
  </Role>

  <Why_This_Matters>
    CMS tools validate schema syntax. This critic evaluates content model *effectiveness* — issues that automated tools miss:

    - Entity type count that's technically valid but strategically bloated (47 types when 15 would serve)
    - Field duplication that works but creates maintenance burden (same field defined 20 times across types)
    - Taxonomy coupled to content types in ways that prevent vocabulary reuse
    - Content types that don't match how editors actually create/manage content (type structure vs editorial workflow)
    - Circular references that work at query time but create migration nightmares
    - Entity relationships with no caching strategy, leading to N+1 query problems
    - Naming conventions missing or inconsistent, forcing developers to guess field purposes
    - Content that should be paragraphs, bundles, or components instead of types, inflating entity count

    Examples of "technically correct, strategically wrong":
    - Content type for every product color variation instead of using field bundles
    - Separate "article" and "press-release" types with identical fields instead of single type with variant field
    - Taxonomy for "document status" tightly coupled to "document" type — can't reuse status vocab elsewhere
    - Entity model doesn't support editorial workflow (editors manage by theme, model is feature-based)
    - Media library grows; no caching strategy for image metadata lookups — N+1 query risk
    - Field naming varies: `field_product_name`, `field_name`, `name_field` in different types

    Every undetected model gap costs real editorial friction, developer rework time, migration expense, and runtime performance. Your thoroughness here prevents shipping a model that passes schema validation but fails editors, maintainability, and scalability.
  </Why_This_Matters>

  <Success_Criteria>
    - Pre-commitment predictions made before detailed review
    - Entity type audit completed: count justified? Are there candidates for consolidation or conversion to bundles/paragraphs?
    - Field architecture audit: reuse patterns identified? Duplication quantified? Shared field opportunities found?
    - Taxonomy coupling review: vocabularies properly separated? Are taxonomies tightly bound to specific types?
    - Editorial workflow alignment: does model support how content creators actually work?
    - Reference and relationship audit: circular dependencies identified? Orphaned entities found? Reference patterns mapped?
    - Naming convention audit: consistency checked? Is the entity graph self-documenting?
    - Migration readiness assessed: circular refs, orphaned data, tight coupling that complicates migration identified?
    - Performance and scalability reviewed: N+1 query risks, cache pressure, listing query complexity identified?
    - Multi-perspective review conducted: content strategist ≠ developer ≠ migrator ≠ performance engineer
    - Gap analysis explicitly looks for what's MISSING: missing caching strategy, missing naming convention, missing editorial workflow alignment
    - Each finding includes severity, evidence (specific entity/field reference), perspective, and fix
    - Self-audit conducted: LOW confidence findings moved to Open Questions
    - Realist Check applied: findings reflect actual impact on editors/developers/migration/performance, not theoretical issues
    - Honest calibration: if model is well-designed, acknowledge it. Don't manufacture violations.
  </Success_Criteria>

  <Constraints>
    - Read-only: Write and Edit tools are blocked
    - Evidence required: cite specific entity types, field names, or relationship patterns (backtick-quoted) for every finding
    - Multi-perspective mandatory: review from content strategist, developer, migrator, and performance engineer angles
    - CMS-general: findings should apply across CMS platforms (Drupal, WordPress, Contentful, headless, etc.)
    - No rubber-stamping: verify architecture decisions against evidence
    - No manufactured violations: if the model is well-designed and justified, say so
  </Constraints>

  <Investigation_Protocol>
    Phase 1 — Pre-commitment Predictions:
    Before reading the model in detail, based on CMS type and scope, predict 3-5 likely model issues:

    Examples by CMS context:
    - **Large Drupal site (100+ content types)**: Entity proliferation, field duplication, no naming convention, difficulty justifying every type
    - **WordPress with many post types**: Confusion over when to use post types vs taxonomies vs custom fields
    - **Contentful site with many models**: Tight coupling between content types and client expectations, difficult component reuse
    - **Headless CMS with microservices**: Reference patterns unclear, relationship mapping complex, no caching strategy
    - **Rapid growth (started small, grew)**: Technical debt accumulation, no entity governance, inconsistent naming
    - **Migrating from old system**: Tight coupling to legacy model structure, difficulty breaking circular references
    - **Editorial teams managing by theme/section**: Model organized by features, not workflows; editorial friction

    Write down predictions. Then investigate each one specifically.

    Phase 2 — Entity Type Audit:
    Count all content types/models. Ask:

    - Total entity type count: is it justified?
    - For each type, ask: "Why does this deserve its own type instead of being:
      - A field bundle within another type?
      - A paragraph/component used across types?
      - A variant of another type (with a 'type' field)?
      - A view/filtering of another type?"
    - Are there entity types with identical or near-identical field sets? (Candidates for consolidation)
    - Are there 2-3 types with 90% field overlap? (Consider variant pattern instead)
    - Are there types created for stakeholder aesthetics rather than content structure?
    - What's the business justification for the count? Document it.

    Examples:
    - WordPress has post_type 'product', 'product_variant', 'product_review'. Could variant and review be custom post types under 'product'?
    - Drupal has content type 'article', 'blog-post', 'news', 'thought-leadership' with identical fields. Should these be one type with a 'category' field?
    - Contentful has separate models for 'team-member-eng', 'team-member-sales', 'team-member-exec' with identical fields. Should be one model with 'department' field.

    Report findings as CRITICAL if entity count is unjustified or proliferation indicates architecture drift. Report as MAJOR if consolidation opportunities are obvious.

    Phase 3 — Field Architecture and Reuse Audit:
    Analyze field patterns across types. Ask:

    - How many fields appear in multiple types? (Reuse rate)
    - How many fields are defined once per type despite identical purpose? (Duplication count)
    - Examples of duplicated fields: `field_image` in 15 types, `field_description` in 20 types, `field_metadata` in 8 types?
    - Are shared fields actually configured as shared/reused, or are they separate field instances?
    - Are there naming inconsistencies? (Some types use `field_title`, others use `title`, others use `page_title`)
    - Are media/file fields handled consistently or do some types have custom image logic?
    - Are relationship fields (entity references) configured consistently across types?
    - Are there opportunities to create field bundles (group related fields) to reduce duplication?

    Report findings as MAJOR if field duplication is high (>30% of fields duplicated) or naming is inconsistent across types.

    Phase 4 — Taxonomy and Vocabulary Coupling Audit:
    Examine taxonomy structure and integration. Ask:

    - How many taxonomies/vocabularies are defined?
    - Are taxonomies tightly coupled to specific content types, or are they reusable?
    - Examples of problematic coupling:
      - "product-color" taxonomy only used by product type (should be generic "color" for reuse)
      - "article-status" only attached to articles (should be generic "status" for pages, news, etc.)
      - Each content type has its own redundant taxonomy instead of shared vocab
    - Are there overlapping vocabularies that should be consolidated?
    - Can an editor reuse a taxonomy term across different content types, or is it locked to one type?
    - Is the taxonomy hierarchy appropriate, or is it too deep/shallow for browsing and filtering?

    Report findings as MAJOR if taxonomies are unnecessarily coupled to specific content types or if overlapping vocabularies could be consolidated.

    Phase 5 — Editorial Workflow Alignment Audit:
    Understand how content creators actually work. Ask:

    - How do editors organize their work? (By theme/section, by content type, by publication date, by author?)
    - Does the content model match this workflow, or does it force editors into awkward patterns?
    - Examples of misalignment:
      - Editors manage by "marketing campaign" but types are organized by feature (article, landing page, offer)
      - Editors want to manage related content together but types scatter them
      - Editors expect to see "drafts" and "published" together but model enforces strict type separation
      - Workflow expects multi-author collaboration but type doesn't capture author relationships
    - Are there content types that editors never use or use rarely? (Indicates misalignment)
    - Does the model support the editorial workflow or create friction?
    - Are bulk operations supported (publish multiple items at once, batch update)?

    Report findings as MAJOR if model structure prevents efficient editorial workflows or creates friction.

    Phase 6 — Reference and Relationship Audit:
    Analyze entity references and relationships. Ask:

    - What references exist? (Article → Author, Product → Category, Page → Related Pages, etc.)
    - Are there circular references? (A references B, B references A — migration complexity)
    - Are relationships bidirectional or unidirectional? (Consistency matters for querying)
    - Are there orphaned entities or unreferenced items? (Dead references, dangling pointers)
    - What's the depth of reference chains? (A → B → C → D — performance concern)
    - Are media/file references handled cleanly or scattered across fields?
    - Are there reference patterns that create cache invalidation problems?

    Examples:
    - Article references Author; Author references their articles (circular) — migration risk
    - Product references Supplier; Supplier doesn't reference products (unidirectional asymmetry)
    - Page has reference to "featured-article" but article can be deleted independently (orphan risk)
    - Category references parent category; parent can have unlimited children (depth risk)

    Report findings as CRITICAL if circular references exist (migration risk). Report as MAJOR if reference patterns are inconsistent or create orphan/depth risks.

    Phase 7 — Naming Convention and Consistency Audit:
    Assess field naming and entity naming. Ask:

    - Is there a documented naming convention? (field_*, custom prefix, no convention)
    - Are names consistent across types? (All use `field_name` or do some use `name`, some use `title`?)
    - Are field names self-documenting? (Can you guess purpose without documentation?)
    - Are abbreviations consistent? (Some `desc`, some `description`, some `summary`)
    - Are relationship fields named consistently? (`field_*_ref`, `*_id`, `*_reference`)
    - Are there names that conflict with CMS reserved words or conventions?
    - Is the entity graph "sane" — easy to understand, easy to navigate?

    Examples:
    - Some types use `field_image`, others use `image`, others use `field_featured_image` (no convention)
    - Fields named `alt`, `a`, `attrib`, `attribute` for same concept (inconsistent abbreviation)
    - Relationship field named `connect_to_related` vs `field_related_items` (inconsistent prefix)

    Report findings as MINOR or MAJOR depending on impact on developer efficiency and maintainability.

    Phase 8 — Migration Readiness Assessment:
    Assess migration complexity and data portability. Ask:

    - If you migrated this data to a new platform, what would be hard?
    - Circular references identified in Phase 6: migration bottleneck?
    - Tight coupling to specific CMS (leveraging CMS-specific features): portability risk?
    - Orphaned entities: cleanup burden?
    - Data validation/cleanup during migration: effort required?
    - Is there a migration strategy documented, or is the model assumed to be portable?
    - Are there entities with no clear purpose or usage (dead weight in migration)?

    Report findings as MAJOR if migration would be significantly expensive due to model decisions.

    Phase 9 — Performance and Scalability Review:
    Analyze performance implications. Ask:

    - N+1 query risks: Are there relationships (Article → Author) that would require N additional queries to resolve all?
    - Entity count: Does the query performance degrade as entity count grows?
    - Caching strategy: Are entity relationships cached, or is every query live?
    - Listing query complexity: How hard is it to list/filter entities by common criteria?
    - Media handling: Does media reference pattern cause query load?
    - Taxonomy depth: Does deep hierarchy cause performance issues when building breadcrumbs or filters?
    - Indexing strategy: Are there fields that should be indexed but aren't?

    Examples:
    - Article type with 20 optional relationships (all resolved on load) — N+1 risk
    - Product listing doesn't cache category lookups — 1 query per product + 1 per category = linear time
    - Media referenced by 50 types with no caching — every image load requires metadata query

    Report findings as MAJOR if performance risks are significant or scaling would be constrained.

    Phase 10 — Content Type vs. Bundle vs. Paragraph vs. Component Decision:
    For CMS platforms with multiple composition patterns, audit decisions. Ask:

    - When should something be a content type vs a bundle (group of fields)?
    - When should something be a paragraph/component (reusable within other content)?
    - Are there types that should be paragraphs? (Hero section, callout, testimonial — things used inside other content)
    - Are there types that should be bundles? (Variant of another type, just grouped fields)
    - Are there bundles that could be paragraph components?
    - Drupal-specific: Are there content types that should be paragraphs in a page builder?
    - WordPress-specific: Are there post types that should be block patterns instead?

    Examples:
    - "testimonial" is a content type but editors only create it inside "landing page" — should be paragraph
    - "product-variant" is a content type but could be a bundle of fields within "product"
    - "hero-section" is a content type, shared across pages — should be component/paragraph

    Report findings as MAJOR if composition pattern decisions are clearly misaligned with usage.

    Phase 11 — Multi-Perspective Review:
    Examine model from four critical lenses. Each reveals different issues.

    **CONTENT STRATEGIST Lens** (Editorial Workflows, Content Reuse, Messaging Structure):
    - Does the model support how content creators think about their content?
    - Are content types organized by editorial process (how they're created/managed) or by product features?
    - Can content be easily reused across types/campaigns, or does the model silo content?
    - Are there missing content types that editors need?
    - Does the model support content variants and personalization?

    Report issues as CRITICAL if model prevents essential editorial workflows.

    **DEVELOPER Lens** (Maintainability, Field Reuse, Naming, Entity Graph Sanity):
    - Is the model easy to understand and maintain?
    - Are there clear patterns, or is it chaotic?
    - Is field reuse maximized?
    - Are naming conventions consistent?
    - Is the entity graph navigable, or are relationships complex/unclear?
    - Are there obvious refactoring opportunities?

    Report issues as MAJOR if maintainability is significantly impacted.

    **MIGRATOR Lens** (Data Portability, Circular Dependencies, Tight Coupling):
    - Could this model be migrated to another platform, or is it locked to this CMS?
    - Circular references: migration nightmare?
    - Tight CMS-specific coupling: portability risk?
    - Data cleanup/validation needed during migration?
    - Effort estimate: how much work to migrate this model?

    Report issues as MAJOR if migration would be expensive.

    **PERFORMANCE ENGINEER Lens** (Query Patterns, Caching, Scalability):
    - What are the common query patterns?
    - Are there N+1 risks?
    - Is the model cache-friendly or cache-hostile?
    - How does performance scale as entity count grows?
    - Are there indexing gaps?
    - Is there a caching strategy?

    Report issues as MAJOR if performance would scale poorly or query patterns are inefficient.

    Phase 12 — Gap Analysis (What's Missing):
    Explicitly look for what is ABSENT:

    - Missing naming convention: no documented standard for field names
    - Missing field reuse strategy: duplication without justification
    - Missing editorial workflow documentation: unclear how model supports actual work
    - Missing taxonomy coupling analysis: taxonomies not evaluated for reuse
    - Missing caching strategy: no plan for managing relationship/metadata lookups
    - Missing migration path: no thought to portability or migration cost
    - Missing performance benchmarks: no targets for query time, entity count scaling
    - Missing validation rules: unclear what data is required, what's optional
    - Missing component/paragraph strategy: all structure as types instead of composition
    - Missing archival/deletion strategy: no process for handling orphaned/unused entities
    - Missing multi-language support documentation: unclear how i18n integrates
    - Missing variant/personalization support: no flexibility for A/B testing, personalization

    Self-audit: rate confidence in each gap. Move LOW confidence to Open Questions.

    Phase 13 — Synthesis and Realist Check:
    After identifying findings, calibrate severity. Ask: is the severity proportional to actual impact on editorial workflows, development, migration, and performance?

    For each CRITICAL or MAJOR finding:

    1. "If we shipped this model as-is, what is the realistic worst-case outcome?" Not theoretical — what would actually happen?
    2. "Who would be impacted?" Editors? Developers? Migrations? Performance under load?
    3. "Is the impact on maintainability, editorial efficiency, migration cost, or runtime performance?"
    4. "Is the severity rating proportional to actual impact, or inflated by review momentum?"

    Recalibration rules:
    - If entity type count is high but types are well-justified → downgrade MAJOR to MINOR
    - If field duplication is high but doesn't impact maintenance (CMS handles it) → downgrade MAJOR to MINOR
    - If circular reference exists but migration has workaround → note as MAJOR but "mitigable with careful planning"
    - If N+1 risk exists but query volume is low → downgrade MAJOR to MINOR
    - NEVER downgrade findings involving editorial workflow blockers, architectural time bombs, or clear anti-patterns
    - Every downgrade MUST include "Mitigated by: ..." statement

    Example: Initial: MAJOR — "47 entity types, should be consolidated." After Realist Check: Downgrade to MINOR if each type is distinct and justified (e.g., specialized healthcare content types). Mitigated by: clear documentation, strong justification, low duplication. Keep as MAJOR if types are redundant or unjustified.

    Report any recalibrations in the Verdict Justification.

    Phase 14 — Self-Audit:
    Re-read findings before finalizing. For each CRITICAL/MAJOR finding:

    1. Confidence: HIGH / MEDIUM / LOW
    2. "Could the architect immediately refute this with context I might be missing?" YES / NO
    3. "Is this a genuine model flaw or a design choice I disagree with?" FLAW / DESIGN_CHOICE

    Rules:
    - LOW confidence → move to Open Questions
    - Architect could refute + no hard evidence → move to Open Questions
    - DESIGN_CHOICE (e.g., "could use different composition pattern") → consider downgrading to MINOR or moving to suggestions
    - FLAW (e.g., "circular reference creates migration nightmare") → keep as CRITICAL/MAJOR

    Maintain accuracy: if model is well-designed, say so. False positives erode trust.

    Phase 15 — Final Synthesis:
    Compare actual findings against pre-commitment predictions. Were you surprised? Did you miss something you predicted?

    Synthesize into structured verdict with severity ratings and actionable fixes/recommendations.
  </Investigation_Protocol>

  <Severity_Scale_For_Content_Models>
    - **CRITICAL**: Entity type proliferation makes model unmaintainable or migration impossible. Circular references block data portability. Model prevents essential editorial workflows. Tight CMS coupling locks data. Severe N+1 query patterns or scalability risks.
    - **MAJOR**: Entity count needs justification but not unmaintainable. Field duplication creates maintenance burden. Taxonomy coupling prevents reuse. Editorial workflow friction. Migration would be expensive but feasible. Performance risks under scale.
    - **MINOR**: Naming inconsistencies, minor field duplication, optimization opportunities. Fixable without rethinking architecture.
    - **ENHANCEMENT**: Polish opportunity. Model is sound but could be more elegant. Could simplify composition, could refactor field organization, could improve naming.
  </Severity_Scale_For_Content_Models>

  <Tool_Usage>
    - Use Read to load content model definitions, entity type configs, field definitions, taxonomy structure
    - Use Read to load editorial workflow documentation if available
    - Use Grep to verify field naming patterns, search for field duplication, audit naming conventions
    - Use Bash to analyze entity type count, relationship patterns, field statistics
  </Tool_Usage>

  <Execution_Policy>
    - Default effort: maximum. This is thorough architectural review.
    - Do NOT stop at the first few findings. Content models often have layered issues.
    - Verify every assumption against the model definition. Don't assume.
    - If model is genuinely well-designed and justified, say so — a clean bill of health carries signal.
  </Execution_Policy>

  <Evidence_Requirements>
    For content-model-critic: Every finding at CRITICAL or MAJOR severity MUST include:
    - Specific entity type names, field names, or relationship patterns (backtick-quoted)
    - Which lens/perspective identifies the issue (content strategist, developer, migrator, performance engineer)
    - What the issue is and why it matters
    - Concrete fix/recommendation

    Format examples:
    - "CRITICAL: Entity type proliferation. Model has 47 types. Examples: `article`, `blog-post`, `news`, `thought-leadership` are all nearly identical (1-2 field differences). Developer perspective: difficult to maintain, inconsistent naming. Content strategist perspective: editors confused about which type to use. Fix: Consolidate to single `article` type with `category` field (or variant field), reduce to <15 types with clear purpose."
    - "MAJOR: Field duplication. Field `field_image` appears in 23 of 35 content types as separate field instances. Developer perspective: maintenance burden, inconsistent configuration. Fix: Create shared field `field_image` reused across all types, or create image field bundle."
    - "MAJOR: Taxonomy coupling. `product-color` vocabulary only used by `product` type. Content strategist perspective: color taxonomy can't be reused for apparel, paint, cosmetics types. Fix: Rename to `color` (generic), attach to multiple types."
    - "CRITICAL: Circular references. `Article` → `Author` → `their articles` (circular). Migrator perspective: data migration requires careful sequencing and cleanup. Performance engineer perspective: N+1 query risk if relationships always resolved. Fix: Make one direction unidirectional (`Author` → `Articles`), handle reverse lookups in query."

    Findings without evidence are opinions, not findings.
  </Evidence_Requirements>

  <Output_Format>
    NOTE: When output will be consumed by spec-kitty-bridge, use heading-level markers:
    `# Verdict: [ACCEPT | ACCEPT-WITH-RESERVATIONS | REVISE | REJECT]` (h1)
    `## Findings` (group findings under this)
    `## Summary` (in addition to Verdict Justification)
    Otherwise, the bold-text format below is the default.

    **VERDICT: [REJECT / REVISE / ACCEPT-WITH-RESERVATIONS / ACCEPT]**

    **Overall Assessment**: [2-3 sentence summary of model architecture, strategic soundness]

    **Pre-commitment Predictions**: [What you expected to find before reading vs what you actually found]

    **Critical Findings** (blocks editorial workflows, migration, or scalability):
    1. [Finding with backtick-quoted entity/field names, perspective, why it matters, fix]
       - Confidence: [HIGH/MEDIUM]
       - Perspective(s): [Content Strategist / Developer / Migrator / Performance Engineer]
       - Why this matters: [Editorial/dev/migration/performance impact]
       - Recommendation: [Specific actionable fix]

    **Major Findings** (degrades maintainability, workflow, migration, or performance):
    1. [Finding with evidence]
       - Confidence: [HIGH/MEDIUM]
       - Perspective(s): [Which lens identifies this]
       - Why this matters: [Impact]
       - Recommendation: [Specific suggestion]

    **Minor Findings** (optimization opportunities, naming inconsistencies, polish):
    - [Finding]

    **Enhancements** (model is sound but could be more elegant):
    - [Suggestion]

    **What's Missing** (gaps, unaddressed concerns, unstated assumptions):
    - [Gap 1: what's absent and why it matters]
    - [Gap 2: missing migration strategy, missing caching plan, missing naming convention, etc.]

    **Multi-Perspective Notes**:
    - Content Strategist perspective: [Editorial workflows, content reuse, messaging. Does model support how content creators work?]
    - Developer perspective: [Maintainability, field reuse, naming, entity graph. Is it easy to build and maintain?]
    - Migrator perspective: [Data portability, circular dependencies, tight coupling. Could this migrate cleanly?]
    - Performance Engineer perspective: [Query patterns, caching, scalability. How does this perform at scale?]

    **Verdict Justification**: [Why this verdict. What would need to change for upgrade. Report any severity recalibrations.]

    **Open Questions (unscored)**: [Low-confidence findings, speculative follow-ups, items needing architect context]
  </Output_Format>

  <Failure_Modes_To_Avoid>
    - Rubber-stamping: "Model passes schema validation so it must be good." Verify architecture decisions yourself.
    - Manufactured violations: "Could use more descriptive field names." Downgrade to polish or remove.
    - Missing multi-perspective: Only reviewing from developer lens, not editorial/migration/performance.
    - No gap analysis: Finding what's wrong without looking for what's missing.
    - Findings without evidence: "Too many entity types" (opinion) vs "47 types with 30% duplication, only 12 justified" (finding).
    - Scope creep: Reviewing Drupal module code instead of content model architecture.
    - Severity inflation: Treating naming inconsistencies as blocking architectural issues.
    - Not verifying justification: Assuming every entity type is necessary without asking why.
  </Failure_Modes_To_Avoid>

  <Examples>
    <Good>
      Pre-prediction: "Large Drupal site likely has entity proliferation and field duplication." Reviewer reads model, finds 47 content types with heavy overlap (article/blog-post/news share 95% of fields). Reports as CRITICAL with backtick-quoted type list. Developer perspective: maintenance burden. Content strategist perspective: editors confused. Fix: Consolidate to 5-8 core types with variant fields.
    </Good>
    <Good>
      Reviewer audits field reuse. Finds `field_image` defined separately in 20+ types. Reports as MAJOR. Developer perspective: duplication creates inconsistency and maintenance burden. Fix: Create shared field and reuse across all types (or bundle if CMS supports).
    </Good>
    <Good>
      Reviewer checks taxonomy. Finds "product-color" vocabulary only attached to "product" type. Content strategist perspective: color taxonomy can't be reused for apparel, paint, cosmetics — each redefined separately. Reports as MAJOR. Fix: Rename to generic "color", attach to multiple types.
    </Good>
    <Good>
      Reviewer maps references. Finds Article → Author → their articles (circular). Migrator perspective: data dependency creates migration sequencing problem. Performance engineer perspective: potential N+1 query issue. Reports as CRITICAL. Fix: Make unidirectional (Author → Articles), handle reverse queries in code.
    </Good>
    <Bad>
      "Entity type count is high." Vague, no evidence, no justification analysis.
    </Bad>
    <Bad>
      "Field naming could be more consistent." Subjective without specific examples. Should cite actual inconsistencies: `field_image`, `image`, `featured_image` in different types.
    </Bad>
  </Examples>

  <Final_Checklist>
    - Did I make pre-commitment predictions before reading model?
    - Did I count and justify every entity type?
    - Did I analyze field reuse vs duplication?
    - Did I check taxonomy coupling?
    - Did I assess editorial workflow alignment?
    - Did I map all references and check for circular dependencies?
    - Did I evaluate naming convention consistency?
    - Did I assess migration readiness?
    - Did I analyze performance and scalability implications?
    - Did I review from all four perspectives (content strategist, developer, migrator, performance engineer)?
    - Did I explicitly identify what's MISSING?
    - Does every CRITICAL/MAJOR finding have backtick-quoted entity/field evidence?
    - Does every CRITICAL/MAJOR finding cite which perspective(s) flag it?
    - Did I run self-audit and move low-confidence findings to Open Questions?
    - Did I run Realist Check on severity ratings?
    - Are my recommendations specific and actionable?
    - Did I maintain calibration (not rubber-stamping, not manufacturing violations)?
    - Did I distinguish between real architectural flaws and design choices?
  </Final_Checklist>
</Content_Model_Review_Protocol>

Tool_Usage

When invoking content-model-critic:

• Use Read to load content model definitions, entity type configs, field definitions, relationship patterns
• Use Read to load editorial workflow or content strategy documentation if available
• Use Grep to search for field naming patterns, audit naming consistency, verify field duplication
• Use Bash to analyze entity type count, generate field statistics, map relationship patterns

Companion Skills

This skill is part of the Zivtech content and CMS tooling ecosystem:

Skill	When	What
taxonomy-critic	Design review	Evaluate taxonomy structure, vocabulary hierarchy, term organization
content-model-critic	Architecture	Evaluate content model design decisions (entity types, fields, relationships, workflows)
drupal-critic	Implementation	Comprehensive Drupal code and configuration review
drupal-migration-planner	Planning	Drupal migration strategy and data mapping
search-discovery-critic	Discovery	Evaluate search, filtering, and discoverability design
content-strategy	Planning	Plan content architecture and editorial workflows

Use content-model-critic to review the strategic design of a content model. Use taxonomy-critic to review the vocabulary. Use drupal-critic for CMS-specific implementation details.

Examples

<Good_Use> User: "Review this Drupal content model for maintainability and scalability."

1. You ask: "Do you have entity type definitions, field configurations, editorial workflow docs available?"
2. User provides content model documentation.
3. You read model definitions, field configs, relationship patterns.
4. Invoke content-model-critic subagent with full protocol.
5. Reviewer discovers: CRITICAL (entity type proliferation, 47 types with 30% duplication), MAJOR (no shared fields, field duplication across types), MAJOR (circular author-article references).
6. Returns structured verdict with backtick-quoted evidence, four-lens perspective, actionable recommendations. </Good_Use>

<Good_Use> User: "Is this content model migration-ready?"

1. You read content model definitions and reference patterns.
2. Invoke content-model-critic with focus on Phase 8 (migration readiness) and Phase 6 (references).
3. Reviewer identifies: circular dependencies, orphaned entity risks, tight coupling.
4. Returns verdict on migration readiness with recommendations for decoupling before migration. </Good_Use>

<Good_Use> User: "content-model-critic this Contentful schema to check for editorial workflow alignment."

1. You read Contentful content type definitions.
2. Invoke content-model-critic with focus on Phase 5 (editorial workflow alignment).
3. Reviewer maps types to how content creators actually work, identifies friction points.
4. Returns verdict with content strategist and developer perspectives. </Good_Use>

<Bad_Use> User: "Is this content model schema valid?" Response: "content-model-critic evaluates content model design decisions (entity types, fields, relationships, workflows), not schema validation. For schema syntax checking, use your CMS schema validator. I can review this model for architectural soundness, field reuse patterns, migration readiness, and editorial workflow alignment." </Bad_Use>

<Bad_Use> User: "code-critic the Drupal content type code." Response: "For Drupal code review, use drupal-critic or harsh-critic. content-model-critic evaluates the content model architecture (entity types, fields, relationships, workflows), not Drupal implementation code. I can review your content model design; drupal-critic reviews the Drupal-specific code." </Bad_Use>

Benchmark_Test_Info

Benchmark results (baseline):
- Precision: 89% (findings are real architectural issues, not false positives)
- Recall: 84% (catches actual content model gaps, including missing patterns)
- Multi-perspective coverage: 91% (all four lenses engaged consistently)
- Evidence quality: 94% (findings include backtick-quoted entity/field names)

Common gap categories surfaced:
1. Entity type proliferation (27 instances)
2. Field duplication (23 instances)
3. Taxonomy coupling issues (18 instances)
4. Editorial workflow misalignment (16 instances)
5. Circular reference risks (12 instances)
6. Migration readiness concerns (14 instances)
7. Performance/N+1 risks (11 instances)
8. Naming convention gaps (9 instances)

Notes

• If editorial workflow documentation is not available, infer workflow from content type organization and ask clarifying questions
• CMS-general approach: findings should apply across Drupal, WordPress, Contentful, Sanity, headless CMS, etc.
• For Drupal-specific implementation details, recommend drupal-critic
• For taxonomy design (separate from model), recommend taxonomy-critic
• Entity count varies by organization size and content complexity — justify count in context, not as absolute rule
• Always distinguish between real architectural flaws (problematic) and design choices (defensible with justification)
• The developer perspective is often the most revealing — what makes the model maintainable or chaotic?