메뉴
Validate agent output against declared domain rules and ground truth before trusting it downstream. Trigger after any agent produces output that will be used in a decision, stored persistently, or passed to another agent.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | domain-validator |
| description | Validate agent output against declared domain rules and ground truth before trusting it downstream. Trigger after any agent produces output that will be used in a decision, stored persistently, or passed to another agent. |
Agent output is a hypothesis. Domain validation is the test.
An agent that produces output without validation is a system that produces hallucinations at scale. The domain validator is the check that separates "the agent said so" from "it is true."
Declare the domain rules — before running any validation, the domain rules must be explicit:
Extract the claims — identify the specific assertions in the agent output that are subject to validation. Not every word in the output is a claim; focus on structured data, named values, and factual assertions.
Validate each claim against the domain rules:
Classify findings:
Produce a validation report — for each claim: status (PASS/WARN/FAIL), the rule checked, and the evidence.
Gate downstream use — FAIL findings block downstream use of the output. WARN findings require explicit human acknowledgement before proceeding. PASS findings may proceed automatically.
| Excuse | Counter |
|---|---|
| "The model is reliable enough" | Reliability is a statistical claim. Domain validation is a deterministic check. Run it. |
| "We'll catch errors in review" | Human review misses structured errors that automated validation catches. Both are needed. |
| "The domain rules aren't defined yet" | Then the output cannot be trusted yet. Define the rules before relying on the output. |
Bootstrap or harden a project's operating model for mixed human and AI delivery teams. Use when starting a repository, adopting an agent harness, defining authority and risk tiers, coordinating parallel agents safely, binding evidence and review to an exact candidate, or correcting fragmented rules that prevent coherent, consistent, complete delivery.
Architecture decisions, trade-off analysis, and ADR authoring. Trigger when a significant technical decision needs to be made, documented, and owned — not when an implementation detail needs a choice.
Decompose an epic into atomic parallelizable tasks and route each task to the right skill. Use this as a meta-router when you have more than one skill available and need to decide which applies. Trigger at the start of any multi-track epic or when the skill count in your harness exceeds ~12.
Check proposed stack, data flows, cloud choices, and delivery controls against declared enterprise policies, compliance frameworks, and security controls. Trigger at R2/R3 risk classification, before locking architecture decisions, or when the operating profile names a governance pointer.
Govern the SemVer release process — versioning discipline, tag-based GitHub releases, changelog hygiene, and the ADR that confirms the release strategy is agreed. Trigger when setting up a release process, before a first public release, or when release practice has become inconsistent. Owned by delivery-orchestrator.
Session-start orientation for this team harness. Load first, before any work. Explains the operating contract, when each skill triggers, and how installed companion plugins supply agent-craft capabilities while this harness supplies the team contract. Trigger at the start of every session and whenever unsure which skill applies.
