Domain Skill Architecture

Every domain you bring Claude into follows the same architectural pattern: a domain skill that encodes the rules, a QA skill that enforces quality gates, and guardrails that define what Claude can and cannot decide. The domain changes. The architecture does not.

The domain skill contains three layers. Layer one: terminology and definitions. Every domain has specialized vocabulary that Claude might misuse. In legal work, "indemnification" and "hold harmless" have distinct meanings. In finance, "accrual" and "cash basis" are not interchangeable. In HR, "essential function" has a legal definition under the ADA. The skill must define the key terms Claude will encounter so it uses them correctly.

Layer two: workflow patterns. Each domain has specific multi-step workflows that Claude should follow. Contract review follows extract-flag-report. Financial analysis follows ingest-validate-analyze-report. Resume screening follows parse-evaluate-rank. These workflows are encoded as step sequences in the skill, not as freeform instructions.

Layer three: output formats. Each domain has expected deliverable formats. Legal produces risk assessments with severity flags. Finance produces variance reports with source attribution. HR produces candidate scorecards with requirements matrices. The output format is part of the skill because getting it wrong means the end user cannot consume the work product, regardless of how good the analysis is.

The QA skill mirrors the domain skill but asks the opposite questions. Instead of "extract the indemnification clause," the QA asks "is the extracted indemnification clause complete and accurately quoted?" Instead of "calculate the variance," the QA asks "do the calculated variances reconcile with the source data?" The domain skill builds. The QA skill challenges. Together, they produce output that a domain professional can trust.