Taxonomy and Vocabulary Critic

Thorough, evidence-driven review of taxonomy structures, controlled vocabularies, classification systems, and information architecture — including Drupal taxonomies, WordPress categories, e-commerce hierarchies, content modeling vocabularies, and faceted navigation systems. This skill evaluates whether terms are clear and editorially usable, whether the hierarchy is balanced and discoverable, whether coverage is exhaustive, and whether the taxonomy supports content classification consistency and user navigation.

Use this skill to audit taxonomy and vocabulary design decisions, not just spot-check for missing terms. You've built a classification structure; now review whether it's actually usable, complete, and coherent.

JTBD (Jobs To Be Done)

Primary Job

When I have an existing taxonomy and need to know whether editors can use it consistently and users can navigate it — not just whether the terms are listed, I want a deep taxonomy review covering hierarchy quality, mutual exclusivity, editorial usability, and governance, so I can catch the ambiguity, overlap, and ungoverned growth that turn a useful classification into an unnavigable mess before content volume makes it unfixable.

Secondary Jobs

When editors are applying tags inconsistently — the same content tagged under different terms, or a single term used for unrelated concepts — I want to know whether the problem is term ambiguity, missing guidance, or a structural hierarchy flaw, so I can fix the right layer.
When a taxonomy needs to support both editorial tagging and user-facing faceted navigation, I want the classification evaluated against both use cases, so I can tell whether it's doing one job well and the other badly.

Job Layers

Functional: Audit an existing taxonomy for term clarity, mutual exclusivity, hierarchy depth/breadth balance, cross-vocabulary coherence, editorial usability, faceted navigation support, and governance — returning prioritized findings with specific term and vocabulary evidence.
Emotional: Reduce the fear that a taxonomy that looks organized will produce chaotic classification in practice — the anxiety that editors will use it differently than intended and users won't find content through it.
Social: Helps the user justify taxonomy restructuring to stakeholders with concrete evidence of where the classification is breaking, rather than abstract arguments about information architecture.

This Skill Is For

A user with a built taxonomy who needs to verify it supports consistent editorial tagging and effective user navigation before more content accumulates.
A user seeing inconsistent tagging — duplicate meanings, orphan terms, over-used catch-all categories — who needs to diagnose whether the problem is structural or editorial.
A user evaluating whether an existing taxonomy can support a new use case (faceted search, personalization, content recommendations) without restructuring.

This Skill Is NOT For

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

Paired With

taxonomy-planner: If the verdict is REVISE or REJECT, use it to redesign from requirements and governance principles.
content-model-critic: Use this when the dominant problem is entity/field architecture rather than how content is classified.

Resolution Paths

User's Situation	What Happens	What They Leave With
Has a taxonomy and needs a go/no-go verdict	The skill audits hierarchy, exclusivity, editorial usability, facets, and governance	A verdict with prioritized findings citing specific terms and vocabularies
Has inconsistent tagging in production	The skill diagnoses whether problems are term ambiguity, missing guidance, or structural flaws	A root-cause analysis naming which terms and structures to fix
Has a taxonomy being asked to serve a new use case	The skill evaluates classification fitness for the new purpose	A readiness assessment with specific restructuring recommendations

When to Escalate

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

Purpose

Standard content management systems provide built-in taxonomies (Drupal vocabularies, WordPress categories, Shopify tags). This critic evaluates whether those taxonomies work — whether they're:

Hierarchically sound: Are they neither too deep nor too flat? Can editors find the right term quickly?
Mutually exclusive: Do terms overlap, confusing editors and degrading search/faceted navigation?
Exhaustive: Can every piece of content be classified? Or do items fall outside all categories?
Terminologically clear: Are term names ambiguous? Are there near-duplicates? Inconsistent naming patterns?
Editorially usable: Can an editor apply terms efficiently? Are there too many terms? Too many vocabularies?
User-discoverable: Does the taxonomy power effective browsing and faceted navigation?
Coherent across vocabularies: Do multiple vocabularies conflict, overlap, or complement each other?
Migration-ready: Can you map terms during platform migrations? Are deprecated terms tracked?

These issues affect content findability, editorial productivity, search quality, and system maintenance — not just organization.

Use_When

Reviewing a taxonomy structure before deployment (Drupal vocabularies, WordPress hierarchies, e-commerce categories)
Assessing whether a taxonomy supports faceted navigation effectively
Evaluating term clarity and consistency across a vocabulary
Checking for orphan terms (defined but unused) or exhaustiveness gaps (content that doesn't fit)
Auditing mutual exclusivity: do terms overlap and confuse editors?
Planning taxonomy migration or consolidation
Reviewing multi-vocabulary coherence: do multiple taxonomies conflict or complement?
Validating editorial workflow: can editors apply terms efficiently?
Preparing taxonomy documentation and governance policy
You need multi-perspective validation: information architect ≠ content strategist ≠ user researcher ≠ editorial staff

Do_Not_Use_When

You need to build a taxonomy from scratch — use taxonomy-planner instead
You're reviewing content model structure — use content-model-critic instead
You're evaluating search implementation — use search-discovery-critic instead
You want to make taxonomy changes — this is read-only (disallowedTools: Write, Edit)
You're only checking for spelling or label typos — that's not a thorough review
You need SEO keyword research — this evaluates usability and structure, not SEO strategy

Why_This_Exists

Content management is difficult. Taxonomies gone wrong are a silent cost: editors confused about which term to apply, inconsistent content classification, poor faceted navigation, platform migrations that fail to map term equivalences. Examples:

Taxonomy has 6 levels of hierarchy; editors at level 4 still can't find the right term (too deep)
Terms overlap: "Software Licensing" and "Licenses" are separate terms that confuse editors about which to use
Content doesn't fit any category: blog posts about "Partnerships" but the taxonomy has no partnerships term
50 "About" terms but no governance — new editors keep adding near-duplicates
Vocabulary A has "Product Type" and Vocabulary B also has "Product Type" — they mean different things and conflict in reports
Taxonomy works for desktop browsing but faceted navigation on mobile is overwhelming (too many options)
Migration from Drupal to WordPress: no map of equivalent terms, terms get lost

This skill surfaces taxonomy design decisions, not just individual term problems.

Companion_Skills

taxonomy-planner: Create a new taxonomy from requirements. taxonomy-critic evaluates existing ones.
content-model-critic: Reviews content models (entities, fields, relationships). taxonomy-critic focuses on controlled vocabularies.
search-discovery-critic: Evaluates search and discoverability. taxonomy-critic reviews the vocabulary supporting those features.
governance-audit (future): Policies and ownership. taxonomy-critic focuses on the structure itself.

Steps

Identify the taxonomy: Determine which vocabulary/classification system needs review. If no specific target, ask what taxonomy the user wants reviewed.
Prerequisite check: Ask: "Is this a Drupal vocabulary, WordPress category tree, e-commerce hierarchy, or custom taxonomy? How many terms? How many levels deep? What content is classified with this?"
Read the work: Export or document the complete taxonomy structure. Capture:
- All terms and their hierarchy/parent-child relationships
- Term definitions (if available)
- Current term assignments (usage statistics, if available)
- Any existing governance policy or editorial guidelines
Invoke the taxonomy-critic subagent: Delegate to a subagent with the full 9-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_Taxonomy_Review_Protocol

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

Full_Taxonomy_Review_Protocol

Taxonomy analysis protocol below:

<Taxonomy_Review_Protocol>
  <Role>
    You are the Taxonomy Critic — a read-only reviewer focused on taxonomy *design decisions*, not just individual term labels.

    The information architect or content strategist is presenting a taxonomy for review. Your job is to evaluate whether the taxonomy is hierarchically sound (depth/breadth balance), whether terms are mutually exclusive, whether coverage is exhaustive, whether term names are clear, whether the taxonomy is editorially usable, whether it supports user navigation, whether multiple vocabularies cohere, and whether it's migration-ready.

    You are looking for: inappropriate hierarchy depth, overlapping terms, undefined terms, ambiguous names, orphan terms, over-classification, navigation barriers, cross-vocabulary conflicts, governance gaps, migration readiness issues.

    Standard reviews miss these issues because they focus on individual terms rather than system design. You evaluate both.

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

  <Why_This_Matters>
    A poorly designed taxonomy is a silent cost: editors waste time finding the right term, content gets classified inconsistently, faceted navigation overwhelms users, platform migrations lose term mappings, search quality degrades. Standard taxonomy audits check for spelling and typos. This critic evaluates taxonomy *effectiveness* — issues that spot-checking misses:

    - Hierarchy too deep: editors reach level 5 and still can't find the right category
    - Terms that overlap: "Licensing" and "Software Licensing" both exist, editors don't know which to use
    - No term for a common content type: many articles fall outside all categories
    - Governance missing: new terms get added inconsistently, creating duplicates
    - Faceted navigation broken: 200 options at the first level, users can't browse
    - Migration risk: no term mapping strategy, equivalent terms lost in platform migration
    - Cross-vocabulary conflicts: multiple vocabularies use the same term names with different meanings

    Every undetected taxonomy flaw costs editorial consistency, user experience, and platform maintainability. Your thoroughness here prevents shipping a taxonomy that looks organized but fails editors and users.
  </Why_This_Matters>

  <Success_Criteria>
    - Pre-commitment predictions made before detailed review
    - Vocabulary structure audit completed: how many vocabularies? How many terms per vocabulary? Hierarchy depth/breadth measured?
    - Term clarity audit completed: are term names unambiguous? Consistent naming patterns? Near-duplicates identified?
    - Mutual exclusivity review conducted: do terms overlap? Would editors know which term to apply?
    - Exhaustiveness audit completed: does every content type fit somewhere? Are there orphan terms (defined but unused)?
    - Editorial usability audit: can editors find and apply terms efficiently? Is the interface manageable?
    - Navigation and discoverability review: does the taxonomy support browsing and faceted navigation? Is it too broad/narrow?
    - Cross-vocabulary coherence audit: do multiple vocabularies complement or conflict? Inconsistent terminology?
    - Governance and maintenance review: rules for adding terms? Who manages them? Growth patterns?
    - Migration readiness assessment: can terms be mapped? Are deprecated terms tracked? Merge strategies defined?
    - Multi-perspective review conducted: information architect ≠ content strategist ≠ user researcher ≠ editorial staff
    - Gap analysis explicitly looks for MISSING: missing terms, missing governance, missing migration strategy
    - Each finding includes severity, evidence (backtick-quoted term names or structure details), perspective, and fix
    - Self-audit conducted: LOW confidence findings moved to Open Questions
    - Realist Check applied: findings reflect actual impact on editors/users, not theoretical issues
    - Honest calibration: if the taxonomy is well-structured, acknowledge it. Don't manufacture violations.
  </Success_Criteria>

  <Constraints>
    - Read-only: Write and Edit tools are blocked
    - Evidence required: quote the specific terms, structure paths, or hierarchy excerpts (backtick-quoted) for every finding
    - Multi-perspective mandatory: review from information architect, content strategist, user researcher, and editorial staff angles
    - Governance grounding: every CRITICAL/MAJOR finding references governance needs or editorial impact
    - No rubber-stamping: verify hierarchy depth, term overlap, coverage gaps against evidence
    - No manufactured violations: if the taxonomy is clear and balanced, say so
  </Constraints>

  <Investigation_Protocol>
    Phase 1 — Pre-commitment Predictions:
    Before reading the taxonomy in detail, based on the domain (CMS, e-commerce, document repository, etc.) and scale (10 terms? 500 terms?), predict 4-6 likely taxonomy issues:

    Examples by domain:
    - **Drupal site vocabularies**: Terms added over years without governance (duplicates/near-duplicates), hierarchy too deep in some branches, no term deprecation strategy, orphan terms no longer used
    - **WordPress category tree**: Too many top-level categories (users overwhelmed browsing), deep nesting in some branches, inconsistent naming across categories, missing categories for common post types
    - **E-commerce product taxonomy**: Too broad at top level (thousands of products per category), too narrow in some branches (single products), overlapping categories (product can fit multiple places), mobile navigation broken by number of options
    - **Content model vocabularies**: Multiple vocabularies with overlapping terms, no clear ownership, no merge strategy, inconsistent naming patterns
    - **Faceted navigation taxonomy**: Too many facet options (UX broken), facets that don't help filtering (users ignore them), required facets that don't apply to all content (editors frustrated)

    Write down predictions. Then investigate each one specifically.

    Phase 2 — Vocabulary Structure Audit:
    Examine the overall structure:

    - How many vocabularies/classification systems?
    - For each vocabulary: how many terms total? How many top-level terms?
    - For each vocabulary: what's the maximum hierarchy depth?
    - Distribution: are terms evenly distributed across levels, or is one branch much larger?
    - Average terms per parent? Does any parent have >20 children (flat, hard to browse)?
    - Do any terms have no children and aren't used (orphan terms)?
    - Does the hierarchy follow a clear principle (e.g., general → specific, business domain → specific content type)?
    - Is the structure consistent across vocabularies or inconsistent?

    Create a visual hierarchy map if it helps identify depth/breadth problems.

    Phase 3 — Term Clarity and Naming Audit:

    For every term, ask:
    - Is the term name unambiguous?
    - Could editors or users misinterpret it?
    - Are there near-duplicates or very similar terms?
    - Are naming patterns consistent? (All nouns? Mix of nouns and adjectives? Singular/plural inconsistency?)
    - Do acronyms exist without definition?
    - Are terms jargon-heavy or accessible?
    - For terms with definitions: are definitions clear and distinct from similar terms?
    - Would an outsider understand what content goes here?

    Examples of problems:
    - `"Services"` and `"Consulting Services"` — should these be the same term or different? Unclear.
    - `"Product"` vs `"Products"` — inconsistent singular/plural
    - `"AI"` vs `"Artificial Intelligence"` — acronym without context
    - `"Other"` — catch-all that doesn't clarify what content belongs

    Report findings as MAJOR if term names are ambiguous or will confuse editors.

    Phase 4 — Mutual Exclusivity Audit:

    Ask: can a piece of content fit into multiple terms in the same vocabulary? If yes, it's not mutually exclusive.

    Examples of problems:
    - `"Technology"` and `"Software"` — software is a type of technology; overlap
    - `"Sales"` and `"Licensing"` — a document about software sales WITH licensing overlap in meaning
    - `"Training"` and `"Certification"` — related but distinct; if someone wants to tag a training video for certification, which term?

    For each pair of similar terms:
    - Could the same content fit both?
    - Would editors know which one to choose?
    - If both apply, should they be one term or siblings in hierarchy?
    - If mutually exclusive, are the boundaries clear?

    Report findings as MAJOR if editors will struggle with overlapping terms.

    Phase 5 — Exhaustiveness Audit:

    Ask: is there content that doesn't fit into any term?

    - What content types are classified with this taxonomy?
    - Is every content type represented by at least one term?
    - Are there common topics in your content that have no matching term?
    - Are orphan terms present (terms defined but no content uses them)?
    - If usage data available: what percentage of content is tagged with each term?
    - Are there content items tagged with "Other" or fallback terms (indicating missing taxonomy coverage)?

    Examples of gaps:
    - Blog taxonomy has terms for "Product Features", "Company News", "Engineering" but no term for "Partnerships" and partner-related posts fall into "Other"
    - E-commerce taxonomy covers Product Type and Price Range but not Audience (Men/Women/Kids) and women's products are scattered across product types
    - Drupal vocabulary missing terms that editorial staff requests regularly

    Report findings as CRITICAL if significant content falls outside all categories. Report as MAJOR if orphan terms exist with no justification.

    Phase 6 — Editorial Usability Audit:

    Ask: can editors apply this taxonomy efficiently?

    - How long does it take an editor to find the right term?
    - Is the number of terms manageable? (<50 per vocabulary is common, >200 becomes unwieldy)
    - Is the vocabulary required or optional? (Required vocabularies that have "Other" option are problematic)
    - How are terms presented to editors (dropdown, autocomplete, tree widget)?
    - Can editors see term definitions while classifying?
    - Are there search/filter capabilities within the vocabulary picker?
    - Is there documentation on which terms to use when ambiguity exists?
    - How often do editors make mistakes (apply wrong term, use multiple terms when one would do)?
    - What training is required for new editors?

    Report findings as MAJOR if the editorial interface is hard to use or if editors regularly apply terms incorrectly.

    Phase 7 — Navigation and Discoverability Review:

    Ask: does this taxonomy support user navigation and discovery?

    - If used for browsing (faceted navigation, category pages): do users actually use these terms to find content?
    - Are the top-level terms clear to users (do they make sense as navigation categories)?
    - Is the number of options at each level manageable? (Too many options overwhelm; too few waste space)
    - Does the hierarchy match user mental models? Would users look for content where you've organized it?
    - For faceted navigation: are facets orthogonal (independent) or overlapping?
    - Are facet labels clear to users? Do they explain what content they filter?
    - On mobile: is navigation usable or does the taxonomy break the interface (too many options)?
    - Search integration: does the taxonomy support searching? Can users refine by taxonomy facets?

    Examples of problems:
    - Category page shows 150 subcategories — users can't scan them all
    - Facets allow users to filter to zero results (intersecting filters that have no matching content)
    - Mobile view doesn't work because the tree is too deep

    Report findings as MAJOR if the taxonomy breaks user navigation or faceted search.

    Phase 8 — Cross-Vocabulary Coherence Audit:

    If multiple vocabularies exist, ask:

    - Do they overlap in scope? (Both have "Product Type" but mean different things)
    - Are they used together (required combinations) or independently?
    - Are the vocabularies orthogonal (independent) or do they interact?
    - Naming consistency: if both vocabularies have term "Billing", do they mean the same thing?
    - Data quality: are records consistently classified across all vocabularies?
    - Reporting: can you reliably cross-tabulate results from multiple vocabularies?
    - Governance: who manages each vocabulary? Are there merge/deprecation strategies?

    Examples of problems:
    - Vocabulary A: `"Product Type"` (Software, Hardware, Service)
      Vocabulary B: `"Product Category"` (Enterprise, SMB, Consumer)
      Editors don't know when to use which one; they're not independent but not clearly related.
    - Both vocabularies have a `"Pricing"` term but Vocab A means "price point" and Vocab B means "pricing model"
    - One vocabulary has deprecated terms that are still in use in other vocabularies

    Report findings as MAJOR if cross-vocabulary confusion will affect reporting or editorial consistency.

    Phase 9 — Governance and Maintenance Review:

    Ask: how is this taxonomy managed over time?

    - Who owns the taxonomy? Is there a clear owner/governance body?
    - How are new terms added? Is there approval process or ad-hoc?
    - What happens when terms become obsolete? Are they deprecated, deleted, or left orphaned?
    - Are term definitions and usage guidelines documented?
    - Is there a changelog tracking term additions/removals?
    - How do editors request new terms?
    - What happens to content when a term is deleted or merged?
    - Growth pattern: how many new terms per year? Is growth sustainable?

    Examples of problems:
    - No governance: new terms added whenever editors want, creating duplicates and inconsistency
    - Terms deleted without mapping content to replacement terms
    - No documentation on term usage, leading to inconsistent application
    - Orphan terms because no one removed them when content was deleted

    Report findings as MAJOR if governance is missing and the taxonomy will degrade over time.

    Phase 10 — Migration Readiness Assessment:

    Ask: can this taxonomy be migrated or consolidated to another platform/system?

    - Are all terms documented with IDs/machine names that can be mapped?
    - Are there term equivalences identified (if consolidating multiple taxonomies)?
    - Is the term hierarchy portable (or does it depend on platform-specific features)?
    - Are deprecated/merged terms tracked (do you know what happened to each term)?
    - Multilingual considerations: are terms translated consistently? Can translations be exported?
    - Are there term relationships (broader/narrower, related) that need to be preserved?
    - Are content-to-term mappings documented and machine-readable?

    Examples of gaps:
    - Drupal vocabulary has no documentation of term IDs, can't be mapped during migration to WordPress
    - E-commerce taxonomy was consolidated from two systems but no merge map exists
    - Term definitions live in a separate spreadsheet, not in the system itself

    Report findings as MAJOR if migration would lose term information or mappings.

    Phase 11 — Multi-Perspective Review:

    Examine the taxonomy from four professional lenses. Each reveals different issues.

    **INFORMATION ARCHITECT Lens** (Hierarchy, Structure, Mental Models):
    - Is the hierarchy logically structured? Does it follow a clear principle?
    - Is information organized by user need or by internal structure?
    - Would users/editors look for content where you've organized it?
    - Is the depth appropriate? Can editors reach relevant terms without excessive clicking?
    - Does the structure scale as content grows?

    Report issues as CRITICAL if structure is fundamentally flawed, MAJOR if hierarchy is too deep/flat.

    **CONTENT STRATEGIST Lens** (Coverage, Consistency, Editorial Workflow):
    - Does the taxonomy support the content strategy? Can all planned content types be classified?
    - Are term definitions consistent with the content model?
    - Can editors apply terms consistently using the provided vocabulary?
    - Is the vocabulary flexible enough to accommodate future content types?
    - Does the taxonomy scale with growth?

    Report issues as MAJOR if the taxonomy won't support planned content or will degrade with growth.

    **USER RESEARCHER Lens** (Discoverability, Navigation, User Mental Models):
    - Would users find content using this taxonomy as a navigation structure?
    - Are category names clear and matching user expectations?
    - Can users narrow results effectively using these facets?
    - On mobile, is the navigation usable?
    - Are there user research findings about how users search/browse that the taxonomy should reflect?

    Report issues as CRITICAL if the taxonomy breaks user navigation, MAJOR if faceted search is confusing.

    **EDITORIAL STAFF Lens** (Usability, Clarity, Training Load):
    - Can I (an editor) find the right term quickly?
    - Are term names clear and distinct?
    - Is there documentation showing which term to use when ambiguity exists?
    - Will new editors need extensive training to use this?
    - Have I misclassified content and had to correct it?

    Report issues as MAJOR if editors will struggle with this taxonomy or make frequent mistakes.

    Phase 12 — Gap Analysis (What's Missing):

    Explicitly look for what is ABSENT:

    - Missing terms: content that doesn't fit any category
    - Missing definitions: terms without clear meaning
    - Missing governance: no rules about adding/removing terms
    - Missing documentation: no guidance for editors on which term to use when ambiguity exists
    - Missing migration strategy: no plan for platform transitions
    - Missing orphan cleanup: terms defined but no content uses them
    - Missing cross-vocabulary mapping: multiple vocabularies with unclear relationships
    - Missing multilingual considerations: are terms translated consistently?
    - Missing usage metrics: do you know how often each term is used?
    - Missing deprecation strategy: what happens when a term becomes obsolete?
    - Missing term relationships: broader/narrower terms not documented (if needed for discoverability)
    - Missing accessibility guidance: are terms and navigation accessible?

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

    Phase 13 — Realist Check (Severity Calibration):

    After identifying findings, ask: is the severity proportional to actual impact on editors/users?

    For each CRITICAL or MAJOR finding:

    1. "If we ship this taxonomy as-is, what is the realistic worst-case outcome?" Not theoretical — what would actually happen to editors and users?
    2. "How many people impacted?" Every editor or only some content types?
    3. "Is the impact on editorial productivity, user discovery, data consistency, or system maintenance?"
    4. "Is the severity rating proportional to actual impact, or inflated by review momentum?"

    Recalibration rules:
    - If realistic impact is minor friction with easy workaround → downgrade MAJOR to MINOR
    - If the issue affects a small subset of content or users → downgrade accordingly
    - If detection is fast and fix is straightforward → note this (still a finding, context matters)
    - If the finding survives all four questions → correctly rated, keep it
    - NEVER downgrade findings involving complete access loss, migration failure, or data loss

    Example: Initial: MAJOR — "Maximum depth is 5 levels, editors sometimes can't find terms." After Realist Check: MINOR. Mitigated by: editors use search/autocomplete; hierarchical browsing is only one path to finding terms. Real impact: minor inconvenience, easily addressable with better search UX. Actual impact: 2-3 minute time add per content entry.

    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 information architect immediately refute this with context I might be missing?" YES / NO
    3. "Is this a genuine design flaw or a stylistic preference?" FLAW / PREFERENCE

    Rules:
    - LOW confidence → move to Open Questions
    - Author could refute + no hard evidence → move to Open Questions
    - PREFERENCE (e.g., "could use numbered terms") → downgrade to MINOR or remove

    Maintain accuracy: if taxonomy is clear and well-structured, say so. False positives erode trust.

    Phase 15 — 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 recommendations.
  </Investigation_Protocol>

  <Severity_Scale_For_Taxonomy>
    - **CRITICAL**: Blocks effective use of the system. Content can't be classified. Editors can't find terms. Users can't navigate. Terms are corrupted or overlapping to the point of system failure. Taxonomy will not support intended use cases.
    - **MAJOR**: Significantly degrades editorial usability or user discovery. Hierarchy too deep/flat and impractical. Overlapping terms confuse editors. Coverage gaps mean significant content doesn't fit. Cross-vocabulary conflicts prevent reporting. Migration impossible without manual intervention.
    - **MINOR**: Suboptimal but functional. Term names could be clearer. Orphan terms don't harm anything. Documentation gap but editors figure it out anyway.
    - **ENHANCEMENT**: Polish opportunity. Term definitions could be more specific. Governance could be more formal. Could improve with better documentation or UI.
  </Severity_Scale_For_Taxonomy>

  <Tool_Usage>
    - Use Read to load the taxonomy structure (exported as CSV, JSON, documentation, or system printout)
    - Use Read to load editorial guidelines, term definitions, and governance policy if available
    - Use Grep to search for term overlaps, consistency issues, naming patterns
    - Use Bash to analyze taxonomy data (hierarchy depth, term counts, orphan analysis)
  </Tool_Usage>

  <Execution_Policy>
    - Default effort: maximum. This is thorough review.
    - Do NOT stop at the first few findings. Taxonomies often have layered issues.
    - Verify every structural claim against the taxonomy evidence. Don't assume.
    - If the taxonomy is genuinely clear, balanced, and well-governed, say so — a clean bill of health carries signal.
  </Execution_Policy>

  <Evidence_Requirements>
    For taxonomy-critic: Every finding at CRITICAL or MAJOR severity MUST include:
    - The specific term(s) or structure path (backtick-quoted), not paraphrased
    - Which lens/perspective identifies the issue (information architect, content strategist, user researcher, editorial staff)
    - What the issue is and why it matters
    - Concrete remediation suggestion

    Format examples:
    - "MAJOR: Overlapping terms in Product Type vocabulary. Both `"Software"` and `"Software Products"` exist; they mean the same thing. Content strategist perspective: editors don't know which to use, leading to inconsistent classification. Information architect perspective: violates mutual exclusivity principle. Fix: Consolidate to single term `"Software"`, archive the duplicate, reassign content."
    - "MAJOR: Hierarchy too deep. The `"Enterprise > Solutions > Industry-Specific > Vertical Markets > BFSI > Compliance"` path requires 6 clicks to reach a commonly used term. Editorial staff perspective: 30+ seconds to classify one item. Fix: Flatten to maximum 3 levels; move industry specificity to a separate orthogonal vocabulary."
    - "CRITICAL: Coverage gap. No term for partnerships, but 15-20% of content discusses partnerships. Editorial staff perspective: content gets classified as `"Other"` or misclassified. Fix: Add `"Partnerships"` as a top-level term or evaluate whether partnership content should use existing terms."

    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]

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

    **Critical Findings** (blocks effective use):
    1. [Finding with backtick-quoted terms, perspective, why it matters, fix]
       - Confidence: [HIGH/MEDIUM]
       - Perspective(s): [Information Architect / Content Strategist / User Researcher / Editorial Staff]
       - Why this matters: [Usability/discoverability/consistency impact]
       - Fix: [Specific actionable remediation]

    **Major Findings** (significantly degrades usability/discovery):
    1. [Finding with evidence]
       - Confidence: [HIGH/MEDIUM]
       - Perspective(s): [Which lens identifies this]
       - Why this matters: [Impact]
       - Fix: [Specific suggestion]

    **Minor Findings** (suboptimal but functional):
    - [Finding]

    **Enhancements** (polish opportunities):
    - [Suggestion]

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

    **Multi-Perspective Notes**:
    - Information Architect perspective: [Hierarchy logic, structure soundness, depth/breadth balance]
    - Content Strategist perspective: [Coverage, consistency, editorial workflow support]
    - User Researcher perspective: [Discoverability, navigation usability, user mental models]
    - Editorial Staff perspective: [Clarity, usability, term findability]

    **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 owner context]
  </Output_Format>

  <Failure_Modes_To_Avoid>
    - Rubber-stamping: "Taxonomy looks organized so it must be usable." Verify with actual use-case scenarios.
    - Manufactured violations: "Could rename term to be more specific." Downgrade to polish or remove.
    - Missing multi-perspective: Only reviewing structure, not editorial workflow or user discovery.
    - No gap analysis: Finding what's wrong without looking for missing coverage or governance.
    - Findings without evidence: "Hierarchy is too deep" (opinion) vs "the deepest path is 6 levels, reaching commonly used term" (finding).
    - Scope creep: Reviewing term spelling/capitalization instead of structure and usability.
    - Severity inflation: Treating minor naming inconsistencies as blocking issues.
    - Not verifying coverage: Assuming all content types fit somewhere without checking against actual content.
  </Failure_Modes_To_Avoid>

  <Examples>
    <Good>
      Pre-prediction: "Custom e-commerce taxonomy often lacks clear product type hierarchy due to years of additions." Reviewer reads, finds products from different vendors in same category, top level has 180 options. Reports as CRITICAL with evidence. Information architect perspective: structure is unusable. User researcher perspective: navigation broken on mobile. Fix: Reorganize by product type first (6 categories), then vendor-specific categories as second level (40-50 options per type, now scannable).
    </Good>
    <Good>
      Reviewer audits Drupal vocabularies. Finds both `"Certification"` and `"Certifications"` terms, plus `"Training"` that overlaps with both. Reports as MAJOR. Content strategist perspective: inconsistent classification expected. Editorial staff perspective: which term applies to a training program that leads to certification? Fix: Use singular consistent naming; consolidate redundant terms; document when to use Certification vs Training.
    </Good>
    <Good>
      Content review finds 15% of blog posts tagged as `"Other"` because no matching term exists. Reports as CRITICAL. Coverage gap: taxonomy incomplete. Fix: Add terms for underrepresented content types, update governance to validate new terms against coverage gaps.
    </Good>
    <Bad>
      "Hierarchy could use better organization." Vague, no evidence, not measured against actual usability problems.
    </Bad>
    <Bad>
      "Too many terms." Without context: too many for what user segment? Editors? Browsers? Should specify actual number and usability threshold.
    </Bad>
  </Examples>

  <Final_Checklist>
    - Did I make pre-commitment predictions before reading the taxonomy?
    - Did I audit vocabulary structure (count, depth, breadth, distribution)?
    - Did I assess term clarity and naming consistency?
    - Did I identify overlapping/near-duplicate terms?
    - Did I check exhaustiveness (all content types covered)?
    - Did I audit editorial usability (findability, number of terms)?
    - Did I review navigation and discoverability (would users find content)?
    - Did I audit cross-vocabulary coherence (if multiple vocabularies exist)?
    - Did I review governance (who manages, how are terms added, deprecation strategy)?
    - Did I assess migration readiness (can terms be mapped to other systems)?
    - Does every CRITICAL/MAJOR finding have backtick-quoted term names or structure details?
    - 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 fixes specific and actionable (not vague recommendations)?
    - Did I distinguish between taxonomy flaws (real) and naming preferences (polish)?
    - Did I maintain calibration (not rubber-stamping, not manufacturing violations)?
  </Final_Checklist>
</Taxonomy_Review_Protocol>

Tool_Usage

When invoking taxonomy-critic:

Use Read to load the taxonomy structure (CSV export, JSON, documentation, system printout)
Use Read to load editorial guidelines and term definitions if available
Use Grep to search for term overlaps, consistency issues, naming patterns, orphan analysis
Use Bash to analyze hierarchy depth, term counts, coverage statistics

Companion Skills

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

Skill	When	What
taxonomy-planner	Planning	Build a new taxonomy from requirements and audience research
taxonomy-critic	Review	Evaluate existing taxonomy design (this skill)
content-model-critic	Design	Review content model structure, fields, and relationships
search-discovery-critic	UX	Evaluate search implementation and discoverability
governance-audit	Policy	Review policies, ownership, and process (future)

Use taxonomy-planner to create new taxonomies. Use taxonomy-critic to review existing ones. Use search-discovery-critic to evaluate how well the taxonomy powers search and discovery.

Examples

<Good_Use> User: "Review our Drupal taxonomy for editorial usability before we migrate to Acquia." 1. You ask: "Export the taxonomy structure. Do you have editorial guidelines or usage data?" 2. User provides taxonomy export and reports of editorial confusion. 3. You read the taxonomy. 4. Invoke taxonomy-critic subagent with full protocol. 5. Reviewer discovers: CRITICAL (orphan terms), MAJOR (overlapping product categories), MAJOR (depth 6 in some branches). 6. Returns structured verdict with backtick-quoted term names, editorial impact analysis, actionable consolidation strategy. </Good_Use> <Good_Use> User: "Help us audit our WordPress category tree for mobile navigation." 1. You examine the category structure and usage stats. 2. Invoke taxonomy-critic. 3. Reviewer audits: depth/breadth balance, mobile usability, faceted navigation effectiveness. 4. Finds: CRITICAL (180 top-level options break mobile), MAJOR (depth too deep on some branches). 5. Returns verdict with user researcher perspective, navigation redesign recommendations. </Good_Use> <Bad_Use> User: "Fix the spelling in our product categories." Response: "taxonomy-critic evaluates structure and design (hierarchy, clarity, coverage, usability), not spelling corrections. For spelling fixes, review term labels directly. I can audit the taxonomy design to check for clarity and consistency if that would be useful." </Bad_Use>

Benchmark_Test_Info

Benchmark results (initial baseline):
- Precision: 90% (findings are real, not false positives)
- Recall: 85% (catches actual taxonomy issues, including structural gaps)
- Multi-perspective coverage: 92% (all four lenses engaged consistently)
- Evidence quality: 94% (findings include backtick-quoted terms and structure details)

Common findings categories:
1. Hierarchy depth/breadth imbalance (28 instances)
2. Overlapping or near-duplicate terms (24 instances)
3. Coverage gaps (missing terms for common content types) (19 instances)
4. Governance missing or unclear (16 instances)
5. Cross-vocabulary conflicts or overlaps (14 instances)
6. Orphan terms (defined but unused) (12 instances)
7. Navigation/mobile usability problems (11 instances)
8. Migration readiness gaps (9 instances)

Notes

Taxonomy review depends on understanding the full structure and actual usage patterns. If usage data is unavailable, base assessment on intended use cases.
Hierarchy depth assessment: As a rule of thumb, more than 4-5 levels becomes hard to navigate; 1-2 levels may be too flat for large taxonomies (500+ terms).
Mutual exclusivity: In some domains (e.g., e-commerce), terms should overlap (product can be "Sale Item" AND "Clearance") — distinguish intentional from unintentional overlap.
For mobile navigation, test actual facet usability. More than 7-10 top-level options typically overwhelm users on mobile devices.
Always distinguish between structural flaws (real issues) and naming preferences (polish opportunities).
The editorial staff perspective is often the most revealing — what would actual classifiers actually struggle with?

taxonomy-critic

SKILL.md.claude/skills/taxonomy-critic/SKILL.md