How I Clone My Knowledge Base Into Claude — The Skill File System
This is part two of a series on how I use Claude as a working professional. Part one covered the overall setup.
-----
Claude doesn’t retain knowledge between sessions. That’s the constraint everything else is designed around. Skill files are my solution to the specific problem of domain expertise — the accumulated technical knowledge, standards, preferences, and decision frameworks that make any expert’s work different from a generic answer.
Here’s how I build them and why the structure matters.
-----
What a Skill File Actually Is
A skill file is a Markdown document you upload at the start of a Claude session. When Claude reads it, it loads that knowledge into the active context window — treating it the same way it would treat any document you hand it.
The content can be anything: design standards, methodology frameworks, reference hierarchies, project parameters, named entities, decision rules. The structure is yours to define.
I started simple. My first skill file was an operator profile — a document that answered “who are you and how do you want to work?” before I started asking Claude to do anything. Once that was working, I started asking a harder question: “what domain knowledge do I have that Claude is currently guessing at?”
-----
The Session That Changed My Approach
I was working on lift station design — one of the more technically specific tasks in water infrastructure management. I noticed Claude was producing technically correct but generically framed work. It knew the textbooks. It didn’t know my adopted standards, my regulatory hierarchy, my active project parameters, or the specific decisions I’d already made.
I asked Claude directly: lWhat would you need to know to stop guessing and start working from my actual knowledge base?”
The answer was specific:
- The governing regulatory document (Oklahoma OAC Title 252, Chapter 656) and how it sits relative to federal NPDES requirements
- My adopted design standards (I’d built a package benchmarked against Edmond and Norman, two neighboring cities)
- Active project parameters for the lift stations I was actually working on
- The engineering references I was using — Perry’s 8th, Metcalf & Eddy 4th, the specific vendor sizing tools
- My design philosophy on disputed or ambiguous questions (pump selection criteria, wet well sizing methodology, bypass pumping requirements)
I drafted that as a Markdown file. When I uploaded it in the next session, the lift station work immediately became a different conversation. I wasn’t re-explaining context. Claude was working from my baseline.
-----
The Structure I Use
Every skill file I’ve built follows roughly the same structure:
Header block — File name, version, date, what domain this covers, what types of tasks it should be loaded for.
Regulatory and standards hierarchy — For engineering work, this is the most important section. What’s the authoritative source? What governs when sources conflict? In my water work: ODEQ regulations over EPA guidance over AWWA standards over local practice. Claude needs to know this hierarchy or it will confidently apply the wrong standard.
Technical reference inventory — What textbooks, editions, and references I’m working from. This matters because Claude knows multiple editions of most references and they’re not equivalent. Perry’s 7th and 8th have meaningful differences. McCabe & Smith 7th and the earlier editions diverged on several unit operations topics. Specifying the edition pins Claude to the version I’m actually using.
Active project parameters — Named projects, key numbers, current status, open questions. This is the operational context that changes most frequently and requires the most maintenance.
Design standards and default assumptions — The decisions I’ve already made. Minimum wet well detention time, force main velocity targets, SCADA alarm hierarchy, bypass pumping specification requirements. These are the judgment calls that distinguish my practice from a generic recommendation.
Known gaps and explicit exclusions — What I’m intentionally not including, and where Claude should flag uncertainty rather than fill in from general knowledge.
-----
The Six Files I’ve Built
I now have six structured skill files covering the main domains of my work:
1. Lift station design reference — Engineering standards, OAC regulatory hierarchy, Yukon adopted design package (benchmarked against Edmond/Norman), active project parameters, vendor reference approach for pump sizing.
2. Chemical engineering reference — Dual-context file. Municipal water/wastewater side covers process engineering, fluid dynamics, mass transfer for treatment applications. Oil and gas side covers separator design, compression, production chemistry from my 20 years in that industry. Textbook inventory includes specific editions: Perry’s 8th, McCabe & Smith 7th, Geankoplis 4th, Welty 4th.
3. GIS, TMDL, and collection systems — The 320-manhole floodplain program, E. coli TMDL compliance framework, SSO documentation methodology, manhole prioritization logic.
4. Civil, structural, and electrical references — Supporting design references for WMD infrastructure work. Less detailed than the primary engineering file but covers the regulatory and standards layer I work within.
5. Power BI and DAX standards — This one is almost entirely about my own decisions rather than external standards. My DAX naming conventions, calculation group architecture, European semicolon locale (yes, this matters — Power BI will break if you mix locales), SQLBI as the Tier 1 canonical authority.
6. Municipal water/wastewater administration — Utility billing methodology, rate ordinance context, leak adjustment policy (the specific ordinance section that governs), cost-of-service framework, Veolia contract financial structure.
-----
What Gets Left Out
I don’t put everything in skill files. Some things belong in memory (active project status, recent decisions, named relationships). Some things Claude already knows reliably enough from training that building a skill file would be redundant.
What I specifically don’t duplicate: textbook knowledge Claude already has well. Perry’s mass transfer correlations, NFPA 70 electrical requirements, general DAX syntax. I don’t need to re-teach Claude thermodynamics. What I do document: where my practice departs from the generic, what standards I’ve adopted, what decisions I’ve already made.
The test I use: “if I hired a new engineer tomorrow, what would I hand them on their first day to stop them from having to guess?” That’s the skill file.
-----
Maintenance and Decay
Skill files decay. Active project parameters change. Standards get updated. Decisions get revisited.
My current approach is to treat the skill files as living documents — I update them when something meaningful changes rather than on a schedule. The lift station file gets updated when a project moves to the next phase or when I make a design standard decision. The Power BI file gets updated when I establish a new pattern I want to carry forward.
The risk is drift: the skill file says one thing and current practice has moved on. I flag that risk explicitly in sessions where it might matter — “the file says X, but we revised that in February — use Y.” That friction is a signal to update the file.
-----
The Honest Percentage
When I audited how well my knowledge had been cloned, I got something like this:
- Technical reference library (ChE, civil, electrical, LS design): ~85%
- Regulatory and standards hierarchy: ~80%
- Active project context: ~70% (memory plus skill files combined)
- WMD operational and administrative knowledge: ~35%
- DataAxe BI/analytics engine: ~25%
- Tacit judgment and experience: ~15%
- Overall: ~55%
The tacit knowledge layer — 20 years of pattern recognition, the judgment calls that don’t have a textbook answer — doesn’t clone well through documentation. That layer clones through repeated working sessions where Claude observes corrections and decisions. It’s slower and harder to systematize. It’s also the most valuable thing to eventually transfer.
55% sounds low. It’s not — it’s the difference between a tool that produces generic output and a collaborator that produces “my”output.
-----
Next: The specific session where I built my operator profile from scratch, the questions I asked, and the structure that came out of it.