[Feature]: Implement Deterministic Validation Guardrails for AI Agent Skills (RCA & Operations)

[farazmirzax]

What would you like to be added:
I propose implementing a Multi-Agent Validation Guardrail (or a strict deterministic schema validator) within the AI agent workflow for the newly added .claude and .gemini skills directories.

Instead of relying on a single-pass LLM generation, the architecture would follow a deterministic validation loop:

1. Generator Agent: Executes the skill (e.g., e2e-root-cause-analysis) and drafts the initial findings based on cluster logs/events.
2. Validator / Guardrail: A secondary, highly constrained prompt (or deterministic Go/Python script) that cross-references the Generator's output against the actual Karmada API state, verifying that the mentioned clusters, resources, and namespaces actually exist.
3. Correction Loop: If discrepancies are found, the context is bounced back to the Generator for correction before being rendered to the user.

I have extensive experience building autonomous AI workflows and multi-agent validation loops. If the maintainers agree this is a valuable architectural addition, I would love to submit a Draft PR with a Python or Go-based proof-of-concept demonstrating this validation loop against a mock Karmada cluster state.

Why is this needed:
When dealing with multi-cluster orchestration, AI agents face a high risk of context-window overload. If an agent performs Root Cause Analysis (RCA) across several clusters, the probability of it hallucinating a cluster name, misinterpreting a ClusterOverridePolicy, or generating an invalid API query increases significantly.

Currently, if the LLM generates an inaccurate RCA conclusion or action, there lacks a strict deterministic layer to catch it before it reaches the user. This feature is necessary for two primary reasons:

• Safety: It actively prevents agents from suggesting or executing commands for non-existent or misnamed clusters.
• Local LLM Viability: Smaller, locally hosted models (which are highly desirable for secure, air-gapped Kubernetes environments) are much more prone to hallucination. A validation loop allows these smaller, open-weight models to perform with enterprise-grade reliability.