Purpose
Produce a structured, implementation-ready metadata schema for a single content type — with the exact fields, field types, controlled vocabularies, and governance rules an intranet developer can configure directly in SharePoint, AEM, Contentful, or a similar CMS. Solves the recurring problem of inconsistent, unsearchable content caused by ad-hoc or missing metadata models.
When to Use
Invoke this skill when the user asks to:
- Define a metadata schema or content model for a new content type
- Standardize metadata across an inconsistent or sprawling intranet/CMS
- Improve findability, filtering, or faceted search for a set of documents
- Design taxonomy and tagging structures before a CMS platform migration
- Build governance rules for how content is tagged and maintained
- Map content attributes to search facets and refiners
Inputs Required
Before starting, collect:
- Content type: The specific type being modeled (e.g., policy document, product page, meeting note, training module)
- Primary audience: Who consumes and searches for this content (roles, departments, or personas)
- Searchability goals: How users need to find and filter this content — key filters, sort orders, and search scenarios
- CMS platform: SharePoint, AEM, Contentful, Drupal, or other (affects field type options and taxonomy handling)
- Existing taxonomies: Any org-wide term sets, department lists, or controlled vocabularies already in use
- Lifecycle needs: Whether content expires, requires review dates, or has ownership/approval requirements
- Compliance/security context: Any classification, retention, or access-control metadata required
If CMS platform or existing taxonomies are unknown, default to platform-neutral field types and propose new controlled vocabularies, noting the assumption.
Instructions
Step 1: Establish the Content Type Profile
Frame the model before designing fields:
- Purpose statement: One sentence on what this content type exists to do
- Author profile: Who creates it and how metadata-literate they are (drives how many required fields are reasonable)
- Consumption pattern: Browsed, searched, subscribed to, or system-referenced — each implies different metadata
- Cardinality expectation: Roughly how many items will exist (tens vs. thousands changes taxonomy vs. free-text decisions)
State 2–3 design principles that will guide the schema (e.g., "minimize required fields at authoring; maximize automated inheritance").
Step 2: Design the Field Set Across Five Metadata Layers
Layer 1 — Descriptive Fields (identity and content) Fields that describe what the item is: Title, Summary/Abstract, Author/Owner, Language, Keywords.
- Distinguish system-generated from human-entered
- Specify max length and whether free-text or controlled
Layer 2 — Categorization Fields (taxonomy and classification) Fields that place the item in the org's structure: Topic/Subject, Department, Content Category, Product/Service line.
- These are the primary controlled-vocabulary fields — each should map to a term set
- Mark single-value vs. multi-value
Layer 3 — Audience & Access Fields Fields governing who sees and finds it: Target Audience, Access Level/Classification, Region/Geography.
- Connect these to security trimming where the platform supports it
Layer 4 — Lifecycle & Governance Fields Fields controlling freshness and accountability: Publish Date, Review Date, Expiration Date, Content Owner, Approval Status, Version.
- Specify which are auto-populated vs. manually maintained
Layer 5 — Search & Retrieval Fields Fields that exist specifically to power search and filtering: Faceted attributes, Priority/Weight, Related Content links.
- Tie each directly back to a searchability goal from the inputs
For every field, define:
- Field name (both display label and internal/system name)
- Field type (Single line text, Choice, Managed Metadata/Taxonomy term, Date, Person, Boolean, Lookup, Multi-value)
- Required / Optional / System-generated
- Single-value or multi-value
- Controlled vocabulary (list the terms, or reference the term set)
- Default/inheritance rule if any
- Purpose — one phrase on why it earns its place
Step 3: Define Controlled Vocabularies
For each categorization or audience field that uses a fixed list:
- Provide the actual term list (5–15 sample terms, flagged as starter values to be validated)
- Specify hierarchy where relevant (parent → child terms)
- Note whether the vocabulary is open (authors can request new terms) or closed
- Flag any terms that should map to existing org taxonomies
Step 4: Map Fields to Faceted Search
Translate the schema into a search experience:
- List which fields become search refiners/facets in the results UI
- Recommend facet display order based on the audience's search priorities
- Identify fields that should be full-text indexed vs. filter-only
- Specify default sort order and any managed properties/boosting rules
Step 5: Write Governance Rules
Rules that keep the model healthy over time:
- Required-field enforcement: Which fields block publishing if empty
- Vocabulary stewardship: Who owns each term set and how new terms get approved
- Review cadence: How Review/Expiration dates trigger workflows or notifications
- Tagging guidance: 3–5 plain-language rules for authors (e.g., "Select at most 3 Topics")
Step 6: Produce the Implementation Field Table
Consolidate the full schema into one migration-ready table so a developer can configure it directly.
Output Format
- Structure: Content type profile → five-layer field design → controlled vocabularies → faceted search map → governance rules → consolidated field table
- Length: 1,000–1,400 words plus the field table
- Format: Structured document with a final markdown table listing every field
- Sections: Content Type Profile → Field Set (5 layers) → Controlled Vocabularies → Faceted Search Mapping → Governance Rules → Implementation Field Table
- Tone: Information architect — precise, standards-aware, platform-pragmatic; no filler
Quality Checklist
Before delivering output, verify:
- [ ] Every field specifies field type, required/optional status, and single/multi-value
- [ ] All five metadata layers are represented with at least one field each
- [ ] Every categorization and audience field either references an existing taxonomy or includes a starter term list
- [ ] Each search/retrieval field traces back to a stated searchability goal
- [ ] The implementation table includes both display name and internal/system field name for every field
- [ ] Governance rules name an owner or trigger for review dates and vocabulary changes
Notes
- Resist over-modeling — every required field is a tax on authors and a source of empty or garbage values; prefer inheritance and auto-population wherever the platform allows
- Managed Metadata (taxonomy) fields outperform Choice fields for anything that will be reused across content types or that needs central governance
- If the CMS is SharePoint, recommend site-column reuse and content type publishing so the model propagates rather than being rebuilt per site
- The single highest-impact decision is usually which 2–3 fields become search facets — design those against real user search scenarios, not against how content is authored
How to use this skill
This file is a Claude Code skill in Anthropic's standard format — markdown with YAML frontmatter at the top.
Installing in Claude Code:
~/.claude/skills/<folder-name>/SKILL.md— auto-loads in every session anywhere on your machine (recommended for skills you'll use across multiple projects)<your-project>/.claude/skills/<folder-name>/SKILL.md— auto-loads only when working in that project (recommended for project-specific skills)
Restart Claude Code or open a new session to register.
Using in Claude.ai, ChatGPT, Gemini, or other AI tools:
- Drag this file into a new chat, or copy and paste its contents
- Send your task or request as your next message — the AI will apply the skill where it fits
For Claude Code skill details: https://docs.anthropic.com/en/docs/claude-code/skills