Teach Claude Your Domain: Building Specialized Strategy Files
Part 7 of 11 — A Practical Guide to Claude Setup
Your writing files teach Claude how you communicate. Your context file tells Claude what’s currently in motion. Your prompts library gives Claude reusable workflows.
But none of those files teach Claude how you think or the strategic frameworks and methodologies you apply when you’re doing the work that’s most distinctively yours That’s what specialized domain files are for.
The Concept
A domain file is a specialized context file built around a specific framework, methodology, or body of expertise that you apply repeatedly in your work.
Every practitioner has at least one. The consultant who uses the same strategic analysis approach across every client engagement. The coach who applies a specific developmental model to every leader they work with. The nonprofit director who evaluates every program decision through the same theory of change framework.
Without a domain file, you’re explaining the framework from scratch every time you ask Claude to help you apply it. With a domain file, Claude already knows the framework. You just tell it which one to use.
What Goes in a Domain File
A good domain file follows the RIPEN structure (from Article 05) and contains:
The framework itself
Not a vague description. The actual components, questions, steps, or principles. If the framework has a diagnostic process, document that process in order.
How you apply it
The generic framework and your application of it may differ. Document your specific adaptations, the modifications you’ve made for your context, the way you sequence the steps.
Examples
Two or three worked examples of the framework applied to real situations. These examples are what make the file useful for complex analysis tasks.
Quality checks
The questions you ask yourself before delivering analysis based on this framework. What would make this output wrong? What’s the most common mistake?
Related files
What other files should Claude load alongside this one? For most domain files, that’s CLAUDE_CONTEXT.md (for current project specifics) and sometimes CLAUDE_DESIGN.md (if the framework is used in workshop settings).
A Worked Example: Blue Ocean Strategy
Let me walk through a real example of a domain file so you can see what this looks like in practice. I’ll use Blue Ocean Strategy. This is a business framework developed by W. Chan Kim and Renée Mauborgne that helps organizations find uncontested market space rather than competing in crowded markets.
If you used this framework regularly, here’s how you’d build a domain file for it.
The Framework (condensed):
Blue Ocean Strategy asks four core questions:
What factors does our industry compete on that we should eliminate entirely?
What factors should we reduce well below industry standard?
What factors should we raise well above industry standard?
What factors should we create that our industry has never offered?
The diagnostic process. Map the current value curve. Where does this organization sit relative to competitors on key factors?
→ identify non-customers (who’s not being served at all?)
→ apply the four actions framework
→ design a new value curve.
How I Apply It (fictional practitioner voice):
I always start by naming the red ocean explicitly. This is the competition the organization is already engaged in, whether they know it or not. Most organizations don’t realize they’re competing. You have to name the game before you can change it.
I pay particular attention to third-tier non-customers — the people who’ve never seriously considered this category at all. That’s usually where the biggest opportunity lives.
Worked Example:
A regional food bank was competing with other nonprofits for donor attention, volunteer time, and grant funding. This is a classic red ocean. Their value curve looked identical to every other food bank in the region.
The Blue Ocean analysis surfaced a non-customer tier they’d never considered: corporate employees who wanted hands-on community engagement but found traditional volunteer models too rigid (schedule constraints, minimum commitments, skill mismatch).
The Blue Ocean move:
Eliminate minimum time commitments.
Reduce coordination overhead through a digital matching system.
Raise the quality of the engagement experience.
Create a skills-based matching program that let a graphic designer contribute design skills, a logistics manager contribute supply chain expertise.
Result: a new program that attracted a completely different donor and volunteer base. One that wasn’t being served by any existing model.
Quality Checks for this framework:
Have I named the red ocean clearly before proposing a blue one?
Have I identified all three non-customer tiers?
Is the new value curve specific, not just a vision statement?
Have I named the “trap” (the pseudo-innovation that will be tempting but isn’t)?
The Point of the Example
Notice what the Blue Ocean domain file contains: the framework structure, a practitioner’s specific application approach, a worked example that shows the framework in action, and quality checks that prevent common failures.
You don’t need Blue Ocean Strategy. You need whatever framework you actually use. The structure is the same.
For a leadership coach: your developmental model, how you apply it in coaching conversations, two or three case examples with outcomes.
For a product manager: your prioritization framework, how you adapt it for different team maturity levels, examples of good and bad prioritization decisions.
For a pastor: your preaching structure, your theological method, examples of how you’ve applied it to different texts.
For a consultant: your diagnostic framework, your engagement methodology, two client examples with outcomes.
The framework is yours. The architecture is the same.
How Many Domain Files Do You Need?
Start with one. The framework you apply most often and benefit most from having Claude understand deeply.
Build it well and test it on real work. Refine it when the output misses and after a few months, you’ll know whether you need a second one.
Most people end up with two or three. The key is quality over quantity. A single well written domain file produces dramatically better output than five mediocre ones.
Starter Template
# [Framework Name] — Domain File
> Load this file for: [specific situations where this framework applies]
## The Framework
[The core components, questions, or steps — specific and sequential]
## How I Apply It
[Your adaptations and specific application approach]
## Worked Examples
### Example 1: [Brief description]
[Walk through the framework applied to this situation]
## Quality Checks
Before delivering analysis using this framework:
- [ ] [Check 1]
- [ ] [Check 2]
- [ ] [Check 3]
## Related Files
- Load @CLAUDE_CONTEXT.md for current project specifics
- Load @CLAUDE_[OTHER].md for [situation]
Next: Article 08 — Claude as developer. How to build a coding file even if you’re not a developer.