Domain Reviewer Framework
Build a custom reviewer for your specific domain using the 5-Lens Framework: terminology, methodology, precedent, limitations, and impact.
Generic code reviewers catch generic issues. But your field has its own standards — medical device software needs different scrutiny than financial models, and legal documents need different checks than academic papers. Off-the-shelf review tools miss what matters most in your domain.
Who it's for: domain experts building review processes for their field, quality assurance leads in regulated industries, research group leaders standardizing paper reviews, engineering managers creating architecture review checklists, anyone reviewing specialized work without a structured framework
Example
"Build a reviewer for healthcare data pipelines" → Custom 5-lens reviewer checking HIPAA terminology compliance, statistical methodology validity, precedent against published guidelines, known limitations of the approach, and downstream patient impact — tailored to your exact domain
CLAUDE.md Template
New here? 3-minute setup guide → | Already set up? Copy the template below.
npx ccplaybooks add domain-reviewer-framework# Domain Reviewer: [Your Domain]
## The 5-Lens Framework
Every domain review should examine these five dimensions:
### Lens 1: Terminology & Notation
**What to check**: Is language precise and consistent?
| Check | What It Catches |
|-------|-----------------|
| Term consistency | Same concept called different names |Get new playbooks like this one
One email a week with new Claude Code workflows. Free, like everything here.
No spam. Unsubscribe anytime.
What This Does
Generic reviewers catch generic issues. This playbook helps you build a domain-specific reviewer that catches issues unique to your field — whether that's economics, medicine, software architecture, legal documents, or any specialized domain.
The 5-Lens Framework provides a structure that adapts to any domain while ensuring comprehensive coverage.
Prerequisites
- Claude Code installed and configured
- Understanding of your domain's standards and common issues Run domain review on [file/section]
Output format:
Domain Review: [Target]
Lens 1: Terminology
- [Issue or ✓]
Lens 2: Methodology
- [Issue or ✓]
Lens 3: Precedent
- [Issue or ✓]
Lens 4: Limitations
- [Issue or ✓]
Lens 5: Impact
- [Issue or ✓]
Domain Score: X/100 Critical Issues: [list] Recommended Actions: [prioritized list]
## Domain-Specific Anti-Patterns
Common mistakes in [Your Domain]:
1. [Anti-pattern 1 and how to fix]
2. [Anti-pattern 2 and how to fix]
3. [Anti-pattern 3 and how to fix]
## Quality Standards
What "good" looks like in [Your Domain]:
- [Standard 1]
- [Standard 2]
- [Standard 3]
Step-by-Step Setup
Step 1: Copy the template
Add the template above to your project's CLAUDE.md.
Step 2: Customize Lens 1 (Terminology)
Add your domain's specific terminology checks:
Example (Economics):
**Domain-specific checks**:
- Treatment and control must be clearly defined
- Causal language only with causal identification
- Standard notation: β for coefficients, ε for errors
- "Significant" requires statistical support
Example (Medicine):
**Domain-specific checks**:
- Drug names use generic nomenclature
- Dosages include units and frequency
- Outcomes use validated measures
- Patient populations clearly specified
Example (Software Architecture):
**Domain-specific checks**:
- Components have clear single responsibility
- Interfaces defined before implementation
- Error states explicitly handled
- Dependencies are intentional, not accidental
Step 3: Customize the remaining lenses
Work through each lens adding checks specific to your field.
Step 4: Add anti-patterns
Document the most common mistakes in your domain.
Step 5: Test the reviewer
Run domain review on [a piece of your work]
Example: Fully Customized Domain Reviewer
For Software Security Reviews:
# Domain Reviewer: Security
### Lens 1: Terminology
- [ ] Threats vs vulnerabilities vs risks properly distinguished
- [ ] Attack vectors named using standard taxonomy (MITRE ATT&CK)
- [ ] Severity ratings use CVSS or equivalent
### Lens 2: Methodology
- [ ] Threat model defined before mitigations
- [ ] Defense in depth (not single point of failure)
- [ ] Principle of least privilege applied
- [ ] Input validation at trust boundaries
### Lens 3: Precedent
- [ ] References to CVEs for known issues
- [ ] OWASP guidelines considered
- [ ] Industry standards cited (NIST, SOC2, etc.)
### Lens 4: Limitations
- [ ] Security assumptions explicit
- [ ] Threat actors considered in scope
- [ ] Known residual risks documented
### Lens 5: Impact
- [ ] Business impact of vulnerabilities assessed
- [ ] Remediation priorities justified
- [ ] Compliance implications noted
## Anti-Patterns
1. Security through obscurity → Always assume attacker knows the system
2. Trusting client input → Validate everything server-side
3. Rolling your own crypto → Use established libraries
Tips
- Start with one lens: Don't try to customize all 5 at once. Start with Terminology (Lens 1) and expand.
- Add examples: For each check, add examples of good vs bad. "Use 'statistically significant' not 'significant'" is clearer than "Be precise."
- Evolve over time: Add new checks when you catch new types of mistakes.
- Domain expertise required: This playbook helps structure review, but you need domain knowledge to customize it well.
Troubleshooting
Problem: Review is too generic
Solution: Your domain-specific checks aren't specific enough. Add exact examples, standard references, and concrete anti-patterns.
Problem: Too many false positives
Solution: Calibrate severity. Not every terminology inconsistency is critical. Add severity levels to checks.
Problem: Missing issues that matter
Solution: Retrospectively add checks. When you miss something important, add a check for it to the framework.