Have read the contribution guide before creating a pull request.

Link to Issue or Description of Change

1. Link to an existing issue (if applicable):

• Closes: feature: Modular Domain Taxonomy #5895
• Related: [RFC] Taxonomy-Driven Skill Routing & Dynamic Context Mutation #5891

Problem:
Developers and system administrators need a robust, standardized way to enforce security policies and access controls on skills based on organizational hierarchies and taxonomies (e.g., flat department structures or rich SKOS JSON-LD classifications). Currently, the SDK lacks an extensible, out-of-the-box plugin architecture that intercepts skill listings and execution checks to apply context-aware taxonomy validation. Additionally, taxonomy can be used and/or executed as a more deterministic task handler without taking away LLM's decision-making. This taxonomy can be used to empower existing systems, and, for example, can be applied to AntigravityCLI if needed.

Solution:
The initial design referred to embedding the design/taxonomy directly into the core SDK; instead of that, it pivoted to plugins. As a result, the following is true: Implemented a fully pluggable, opt-in Taxonomy & Policy Security Engine (as a TaxonomyPlugin(BasePlugin)). Key design points include:

• Frontmatter Validation: Hardened validation rules in the Frontmatter model to parse taxonomy-binds natively, reusing the SDK's existing path segment guards under the hood.
• Pre-Compiled Safety Guard: Configured the validation regex _TAXONOMY_BIND_PATTERN as a pre-compiled module-level immutable constant for maximum speed and security.
• Dual-Schema Taxonomy Parsing: The TaxonomyRegistry cleanly parses both standard Flat Key-Value JSON (id/parentId/name/definition) and rich JSON-LD with SKOS (Concept, prefLabel, altLabel, definition, broader) standards to resolve organizational hierarchies.
• Pipeline Orchestration: Introduces TaxonomyPipeline and TaxonomyResolver interfaces to dynamically chain multiple contextual policy resolvers (e.g., checking user roles, entitlements, and classification rules) during runtime execution.
• Clean Event-Driven Integration: Integrates directly with the SDK's list_skills and is_skill_allowed hooks, keeping lists in the expected dictionary-wrapped XML response structure.

Testing Plan

Unit Tests:

• I have added or updated unit tests for my change.
• All unit tests pass locally.

Comprehensive Test Suite Executed:
Added and verified 53 passing test cases under the native pytest framework, including:

1. test_taxonomy_plugin.py (6 cases): Validates full parsing of Flat and SKOS JSON-LD structures, async TaxonomyPipeline chaining, DefaultSkillPolicy set-intersection filtering, and interceptive before_tool_callback listing logic.
2. test_models.py (4 cases): Validates taxonomy-binds aliases, list item validation, rejection of invalid tags (e.g. strings containing spaces), and serialization format.
3. test__utils.py (1 case): End-to-end load tests validating YAML frontmatter mapping within SKILL.md parser loops.

# To execute the full pytest suite:
$env:PYTHONPATH="src"
python -m pytest tests/unittests/plugins/test_taxonomy_plugin.py tests/unittests/skills/test_models.py tests/unittests/skills/test__utils.py

Manual Tests:

To manually verify the taxonomy filter pipeline:

1. Initialize the Registry with a SKOS JSON-LD or Flat JSON configuration:

   from google.adk.plugins.taxonomy import TaxonomyRegistry, TaxonomyPlugin, DefaultSkillPolicy
   
   registry = TaxonomyRegistry.from_flat_json([
       {"id": "engineering", "parentId": None, "name": "Engineering"},
       {"id": "machine-learning", "parentId": "engineering", "name": "Machine Learning"}
   ])

2. Instantiate the Plugin with a custom policy or the DefaultSkillPolicy:

   policy = DefaultSkillPolicy()
   plugin = TaxonomyPlugin(policy=policy, taxonomy_registry=registry)
   # Register plugin to the ADK instance

3. Add taxonomy-binds to your skill's frontmatter configuration:

   taxonomy-binds:
     - "engineering"
     - "machine-learning"

4. Invoke list_skills with a dynamic context (e.g. passing a user identity or role inside tool_context) and observe that skills bound to unauthorized taxonomies are securely filtered out of the response.

Checklist

• I have read the CONTRIBUTING.md document.
• I have performed a self-review of my own code.
• I have commented my code, particularly in hard-to-understand areas.
• I have added tests that prove my fix is effective or that my feature works.
• New and existing unit tests pass locally with my changes.
• I have manually tested my changes end-to-end.
• Any dependent changes have been merged and published in downstream modules.

Additional context

• Built to satisfy strict pluggability constraints: when the plugin is not loaded, the ADK continues operating exactly as normal (100% opt-in).
• Returning filtered skill lists preserves the SDK's exact contract by returning a structured dict expected by __build_response_event.