1 · RULE No.81 · Opening — Rule No.8

새 직원이 들어왔다고 해볼게요. 회사 규칙을 종이 한 장에 빼곡히 적어서 건네주면, 그 사람은 "모든 걸 조금씩 아는 박학한 신입"이 됩니다. 그런데 같은 지식을 직무기술서, 업무 절차서, 업무 정책 문서로 나눠서 주면, 어느새 "그 분야 전문가"처럼 일하기 시작해요. 차이는 지식의 양이 아니라 지식의 형태였습니다. 오늘은 룰 넘버 에이트, "지식을 구조화하면 Claude가 전문가가 된다"를 가지고, 지식을 구조로 나눠서 Claude를 도메인 전문가로 만드는 법을 다뤄보겠습니다. 이 강을 마치면, 한 덩어리 메모를 역할, 절차, 업무 문서 세 그릇으로 나눠 반복 업무에서 전문가 Claude를 만들 수 있게 됩니다.Say a new employee joins. If you hand them the company rules crammed onto a single page, they become a "well-read rookie who knows a little about everything." But give them the same knowledge split into a role spec, a procedures manual, and work policy documents, and suddenly they start working like "a domain expert." The difference wasn't the amount of knowledge — it was its shape. Today, under Rule Number Eight — "structure knowledge, and Claude becomes an expert" — we'll cover how to split knowledge into structure and turn Claude into a domain expert. By the end, you'll be able to split a one-big-pile memo into three vessels — role, procedure, and work docs — and build an expert Claude for recurring work.

2 · CLAUDE.md에 다 적었는데, 왜 전문가가 아닐까?2 · Hook — wrote it all, yet still not an expert?

지난 시간엔 매번 반복하던 설명을 클로드 닷 엠디에 한 번 적어서, 세션이 끝나도 사라지지 않게 휘발을 막았죠. 그래서 많은 분들이 이렇게 합니다. 보고 형식, 업무 용어, 월별 마감 절차, 데이터 출처 규칙, 경영진 보고 주의사항을 전부 클로드 닷 엠디 한 파일에 차곡차곡 쌓아요. 스크롤이 점점 길어지죠.Last time, we took the explanations you kept repeating and wrote them once into CLAUDE.md, so they wouldn't vanish when the session ended — we stopped the evaporation. So a lot of people do this: they pile report formats, business terms, monthly close procedures, data source rules, and executive report notes all into one CLAUDE.md file, stacking it up. The scroll just keeps getting longer.

그런데 다 적었는데도, Claude가 그 분야 전문가가 아니라 "모든 걸 조금씩 아는 똑똑한 신입"처럼 느껴진 적 없으세요? 분명 빠뜨린 건 없는데, 깊이가 안 나옵니다. 여기서 핵심은요. 문제는 적었느냐가 아니라, 어떻게 구조화했느냐예요. 지식의 양이 아니라 형태가 전문성을 정합니다. 그래서 오늘은 '쌓기'에서 '구조화'로 한 단계 올라가 보겠습니다.And yet, even after writing it all down, have you ever felt Claude was less a domain expert and more a "smart rookie who knows a bit about everything"? Nothing's missing, but the depth just isn't there. Here's the key: the problem isn't whether you wrote it, it's how you structured it. It's not the amount of knowledge that decides expertise — it's the shape. So today we step up, from "piling it on" to "structuring it."

3 · 평면 더미의 3가지 한계3 · Three limits of the flat heap

한 더미로 쌓으면 구체적으로 세 가지를 잃습니다. 첫째, 관점이 흐려져요. 코드를 깐깐하게 보는 리뷰어의 시각, 친절하게 쓰는 문서 작성자의 시각, 빈틈을 찾는 보안 점검자의 시각이 한 파일에 다 섞이면, 어느 관점도 또렷하지 않게 됩니다. 둘째, 항상 다 짊어져요. 한 덩어리는 매 세션마다 통째로 컨텍스트를 먹습니다. 지금 이 작업에 안 쓰는 지식까지 전부요. 룰 넘버 투, 컨텍스트를 지켜라가 여기서 깨지는 거죠.Pile it into one heap and you lose three things, specifically. First, the lens goes foggy. The strict reviewer's view of code, the friendly documentation writer's view, the security checker's hunt for gaps — mix them all in one file and no single lens stays sharp. Second, you carry it all, always. One heap eats the whole context every single session — including knowledge you aren't using for this task at all. That's where Rule Number Two, protect your context, breaks down.

셋째, 재사용이 안 됩니다. 똑같은 절차를 반복하는데도, 묶어둔 단위가 없으니까 매번 처음부터 풀어서 설명해야 해요. 중요한 건, 이게 Claude의 버그가 아니라는 점입니다. 지식을 구조 없이 한 더미로 쌓은 결과일 뿐이에요. 그러니 해법도 분명합니다. 이 평면 더미를 역할, 절차, 그리고 업무 근거 문서로 나누는 거예요.Third, there's no reuse. You repeat the very same procedure, but with no bundled unit, you have to spell it out from scratch every time. The important thing is, this isn't a bug in Claude. It's just the result of piling knowledge into one heap with no structure. So the fix is just as clear: split that flat heap into roles, procedures, and work-doc context.

4 · 구조화의 세 그릇 — 역할·절차·업무 근거 문서4 · Three vessels — role, procedure, work-doc truth

그럼 구조화가 뭐냐. 한마디로, 한 더미였던 지식을 세 개의 그릇에 나눠 담는 겁니다. 첫 번째 그릇은 역할이에요. Claude Code에서는 이걸 에이전트, 정확히는 서브에이전트라는 별도 정의 파일로 둘 수 있어요. 닷 클로드 슬래시 에이전츠 폴더 안에, 관점이나 페르소나를 담습니다. 두 번째 그릇은 절차예요. 이건 스킬이라는 파일로 두는데, 닷 클로드 슬래시 스킬즈 폴더 안에, 재사용 가능한 작업 묶음을 담습니다.So what is structuring? In a word, it's taking what was one heap and sorting it into three vessels. The first vessel is role. In Claude Code, you can put this in a separate definition file called an agent — more precisely, a subagent. Inside the dot-claude-slash-agents folder, you hold the lens or persona. The second vessel is procedure. This goes in a file called a skill, inside the dot-claude-slash-skills folder, holding a reusable bundle of work.

세 번째 그릇은 업무 근거 문서예요. 업무 메모, 정책 문서에, 우리 매장이나 회사에만 있는 고유한 사실을 담습니다. 예를 들어 왜 이 카테고리만 마진율 기준이 다른지 같은 것들이죠. 정리하면, 역할은 에이전트로, 절차는 스킬로, 우리 회사의 업무 근거는 업무 문서로. 한 가지만 짚을게요. 역할 폴더인 닷 클로드 슬래시 에이전츠 같은 정확한 경로나 파일 형식, 명령어는 버전마다 바뀔 수 있어요. 발표 시점의 공식 문서가 진실입니다. 외워야 할 건 경로가 아니라 원리예요. 지식은 쌓지 말고, 그릇에 나눠 담는다.The third vessel is work-doc truth. In work memos and policy documents, you hold the facts unique to our store or company — things like why this particular category has a different margin standard. To sum up: roles go in agents, procedures go in skills, and our company's work grounds go in work docs. One caveat: exact folder names like the role folder dot-claude-slash-agents, the file format, the commands — these can change by version. The official docs at the time you present are the truth. What you memorize isn't the path, it's the principle: don't pile knowledge up, sort it into vessels.

5 · Before/After ① — 한 덩어리 vs 역할별 에이전트5 · Before/After ① — one heap vs role-based agents

첫 번째 비포 애프터입니다. 비포, 한 덩어리부터 볼게요. 만능 프롬프트 하나가 매출 분석도 하고, 재고 파악도 하고, 경영진 보고도 쓰고, 이상 탐지도 하고, 이걸 동시에 다 하려고 합니다. 지난 강 기억하시죠. 입력이 출력의 분포를 정합니다. 한 프롬프트에 여러 의도를 다 섞어 넣으면, 분포가 넓어지면서 관점이 평균값으로 흐려져요. 어느 것도 깐깐하지 않고, 어느 것도 친절하지 않은, 밍밍한 결과가 나옵니다.First before-and-after. Let's start with the before — one heap. A single all-purpose prompt tries to analyze sales, check inventory, write the executive report, and flag anomalies, all at once. Remember last session: the input decides the output's distribution. Cram many intentions into one prompt and the distribution widens, so the lens fogs toward an average. You get a bland result — nothing strict, nothing friendly.

이제 애프터예요. 닷 클로드 슬래시 에이전츠 폴더에 역할별 에이전트를 둡니다. 예를 들어 매출 분석가는 수치와 트렌드에 집중하는 관점으로 고정하고, 리포트 작성자는 경영진 친화적이고 구조적인 관점으로 고정해요. 그러면 일에 맞는 전문가를 골라서 부를 수 있죠. 에이전트 파일은 역할별로 분포를 좁혀서, 전문가의 관점을 딱 고정해 줍니다. 그러니 관점이 중요한 일이라면, 한 명에게 다 시키지 말고 역할로 나누세요. 이름은 예시일 뿐이고요.Now the after. In the dot-claude-slash-agents folder, you place an agent per role. For instance, fix the sales analyst to a numbers-and-trends lens, and the report writer to an exec-friendly, structured one. Then you can summon the specialist that fits the job. The agent file narrows the distribution per role, locking in the expert's lens. So when a job hinges on perspective, don't make one do it all — split by role. And the names are just examples.

6 · Before/After ② — 매번 절차 설명 vs 스킬로 묶기6 · Before/After ② — re-explaining procedure vs skill bundle

두 번째 비포 애프터예요. 이번엔 절차입니다. 비포, 매번 절차를 낭독하는 장면이에요. 월 마감 보고할 때마다 이렇게 설명하죠. 매출 피벗 만들고, 전월 대비 계산하고, 이상 항목 표시하고, 요약 작성하고. 문제는 이 다단계 절차를 세션이 바뀔 때마다 처음부터 다시 풀어 설명해야 한다는 거예요. 묶어둔 단위가 없으니까요.Second before-and-after. This time it's procedure. The before: reciting the steps every time. For each monthly close, you explain like this — build the sales pivot, calculate month-over-month change, flag anomalies, write the summary. The problem is, this multi-step procedure has to be spelled out from scratch whenever the session changes. There's no bundled unit.

애프터를 볼게요. 닷 클로드 슬래시 스킬즈 폴더에 먼슬리 클로즈라는 이름으로 절차를 묶습니다. 부를 이름, 언제 쓰는지, 그리고 단계들이 한곳에 모여 있어요. 그러면 다음부턴 "마감 보고 스킬 써줘" 한 줄이면 끝납니다. 스킬은 모델이 그 작업이 필요할 때 불러 쓰는, 재사용 가능한 지침 묶음이에요. 역시 정확한 형식이나 발동 방식은 발표 시점 공식 문서가 진실입니다. 핵심은, 반복되는 절차는 스킬로 한 번만 묶는다.Now the after. In the dot-claude-slash-skills folder, you pack the procedure under the name "monthly-close." The name to call it, when to use it, and the steps all sit in one place. From then on, one line — "use the monthly-close skill" — and you're done. A skill is a reusable bundle of instructions the model pulls in when that work is needed. Again, the exact format and how it triggers are whatever the official docs say at presentation time. The point: a repeated procedure gets packed into a skill, once.

7 · 한 장 비교 — 무엇을 어디에 두나7 · One-page map — what goes where

그럼 어떤 지식을 어느 그릇에 담아야 할까요. 한 장으로 정리했습니다. 첫째, 전역 규칙이나 컨벤션, 예를 들어 한국어로 답해라, 들여쓰기는 두 칸이다 같은 건 클로드 닷 엠디에 둡니다. 둘째, 꼼꼼한 매출 분석가나 리포트 작성자처럼 역할이나 관점은 에이전트 파일에 둬요. 셋째, 재고 마감이나 주간 보고 루틴처럼 반복되는 절차는 스킬 파일에 둡니다. 넷째, 왜 이 카테고리만 마진율 기준이 다른지처럼 우리 매장이나 회사에만 있는 고유한 사실은 업무 메모나 정책 문서에 둡니다.So which knowledge goes in which vessel? Here it is on one page. First, global rules or conventions — like "answer in Korean" or "indent with two spaces" — go in CLAUDE.md. Second, a role or lens, like "the thorough sales analyst" or "the report writer," goes in an agent file. Third, repeated procedures, like an inventory close or weekly reporting routine, go in a skill file. Fourth, facts unique to our store or company — like why this particular category has a different margin standard — go in work memos or policy documents.

지난 시간이 대화창에 쓸 거냐, 파일에 쓸 거냐, 그러니까 위치 문제였다면, 오늘은 어느 파일, 어느 그릇이냐, 구조 문제예요. 여기서 흔한 실수가, 이걸 다 클로드 닷 엠디에 욱여넣는 겁니다. 그러면 다시 한 덩어리가 되어버려요. 그러니 기억하세요. 지식의 종류가 그릇을 정합니다. 다 클로드 닷 엠디에 넣지 마세요.If last time was "the chat box or a file" — a question of location — today it's "which file, which vessel" — a question of structure. A common mistake here is stuffing it all into CLAUDE.md, which just turns it back into one heap. So remember: the kind of knowledge decides the vessel. Don't put it all in CLAUDE.md.

8 · 왜 통하나 — 구조가 전문성을 만드는 3원리8 · Why it works — three principles behind expertise

오늘의 첫 번째 핵심입니다. 왜 구조가 전문성을 만드는 걸까요. 구조는 세 가지를 동시에 해내거든요. 첫째, 역할은 관점을 고정합니다. 에이전트가 한 관점으로만 보게 하니까, 출력의 분포가 전문가 영역으로 좁혀져요. 지난 강의 분포 이야기랑 정확히 이어집니다. 둘째, 절차는 재사용됩니다. 스킬은 필요할 때만 불러오니까, 매번 설명하거나 다시 학습할 필요가 없어요. 그만큼 컨텍스트를 아낍니다. 룰 넘버 투랑 이어지죠.Today's first peak. Why does structure make expertise? Because structure does three things at once. First, role fixes the lens. An agent sees through one lens only, so the output's distribution narrows to the expert zone — exactly the distribution point from last session. Second, procedure gets reused. A skill is pulled in only when needed, so there's no re-explaining and no re-learning, which saves that much context. That ties straight back to Rule Number Two.

셋째, 업무 근거 문서는 정확함을 줍니다. 업무 메모나 정책 문서에 우리 회사·매장만의 사실을 적어두면, Claude가 추측으로 메우는 대신 근거를 보고 답해요. 우리가 첫 강에서 봤던 할루시네이션, 그러니까 빈칸을 그럴듯하게 메우는 그 경향이 줄어듭니다. 정리하면, 역할은 분포를 좁히고, 스킬은 컨텍스트를 아끼고, 업무 문서는 추측 대신 사실을 줘요. 이 셋이 합쳐져서, 박학한 신입을 전문가로 바꿉니다. 구조가 깊이를 만드는 거예요.Third, work-doc truth gives accuracy. Write our company's and store's unique facts into work memos and policy documents, and Claude answers from grounds instead of filling gaps by guessing. That hallucination from our first session — the tendency to fill a blank with something plausible — drops. To sum up: role narrows the distribution, the skill saves context, and the work docs give facts instead of guesses. Together, these three turn the well-read rookie into an expert. Structure is what makes the depth.

9 · 지식 그래프 — 파일들이 서로를 부른다9 · Knowledge graph — files point to each other

여기서 구조화의 숨은 이득이 하나 더 나옵니다. 클로드 닷 엠디는 창고가 아니라 색인이에요. 모든 걸 거기 다 담으려 하지 말고, 어디에 뭐가 있는지 가리키는 역할만 맡기세요. 예를 들어 역할이 필요하면 에이전트를, 절차가 필요하면 스킬을, 회사 고유 사실이 필요하면 업무 문서를 가리키는 거죠. 그러면 필요한 그릇만 꺼내 쓸 수 있어요.Here a hidden benefit of structuring shows up. CLAUDE.md is not a warehouse — it's an index. Don't try to put everything there; just give it the job of pointing to where things are. For example, when a role is needed, point to agents; when a procedure is needed, point to skills; when a company-specific fact is needed, point to work docs. That way you pull out only the vessel you actually need.

이게 왜 좋냐면요. 한 덩어리는 매 세션 통째로 다 로드됩니다. 안 쓰는 것까지요. 그런데 색인이 각 그릇을 가리키면, 필요한 것만 꺼내 쓸 수 있어 컨텍스트를 아낍니다. 룰 넘버 투랑 이어지죠. 구조화의 숨은 이득은 컨텍스트 절약이에요. 그러니 클로드 닷 엠디는 가볍게 색인으로 두고, 깊이는 각 그릇에 두세요.Why is that good? One heap loads in whole, every session — including what you don't use. But when an index points to each vessel, you can pull only what's needed, saving context. That ties back to Rule Number Two. The hidden payoff of structuring is context saved. So keep CLAUDE.md light as an index, and put the depth in each vessel.

10 · 언제 파일로, 언제 프롬프트로10 · When to file, when to prompt

자, 그럼 모든 걸 다 파일로 만들어야 할까요. 아닙니다. 여기 이 강 전체를 묶는 핵심 분기가 있어요. 세 가지를 보세요. 여러 번 쓸 거냐, 이번만 쓸 거냐. 안정적이냐, 자주 바뀌냐. 팀이나 미래의 나와 공유할 거냐, 아직 나 혼자 실험 중이냐. 반복되고, 안정적이고, 공유할 거면 파일로 만드세요. 반대로 이번 한 번만 쓰고, 자주 바뀌고, 아직 실험 중이면 그냥 프롬프트로 말하세요.So, should you turn everything into a file? No. Here's the core fork that ties this whole session together. Look at three things. Will you use it many times, or just this once? Is it stable, or does it change often? Will you share it with the team or future-you, or are you still experimenting alone? If it's repeated, stable, and shared — make it a file. If it's one-off, changes often, and still experimental — just say it in a prompt.

왜냐하면 구조를 만드는 데도 비용이 들거든요. 파일을 만들고, 유지하고, 관리해야 하니까요. 그 비용이 회수되는 건 오직 반복될 때뿐이에요. 지난 강에서 지식의 위치가 비용을 정한다고 했죠. 오늘은 거기서 한 발 더 나가서, 지식의 형태도 비용입니다. 한 번 쓸 걸 굳이 파일로 구조화하면, 그건 과설계예요. 다음은, 그럼 무엇을 구조화해야 할지 점검하는 다섯 가지입니다.Because structure costs something too — you have to create the file, maintain it, manage it. That cost pays off only when it repeats. Last session we said the location of knowledge sets the cost. Today we go one step further: the shape of knowledge is a cost too. Structure a one-off into a file for no reason, and that's over-engineering. Next up: five checks for what's actually worth structuring.

11 · 도메인 전문가 Claude 만들기 5체크11 · Five checks for domain-expert Claude

자, 오늘의 두 번째 완성형입니다. 박학한 신입을 분야 전문가로 바꾸는 다섯 가지 점검이에요. 첫째, 역할이 섞였나? 한 프롬프트에 관점이 여럿이면 에이전트로 분리하세요. 역할 하나당 파일 하나가 원칙입니다. 둘째, 절차가 반복되나? 매번 푸는 다단계 작업이라면 스킬로 묶으세요. 이름, 언제 쓰는지, 단계를 함께요. 셋째, 업무의 '왜'가 적혀 있나? 우리 매장이나 회사만의 사실이나 결정 이유를 업무 메모, 정책 문서에 적어서 추측을 막으세요.Alright, today's second peak. Five checks that turn the well-read rookie into a domain expert. One: are roles mixed? If one prompt holds many lenses, split them into agents — one file per role is the rule. Two: does a procedure repeat? If it's multi-step work you spell out every time, pack it into a skill — with its name, when to use it, and the steps. Three: is the work's "why" written down? Put your store's or company's unique facts and the reasons behind decisions into work memos and policy documents, to block guessing.

넷째, 파일인가 프롬프트인가? 반복되고 안정적이고 공유할 거면 파일로, 일회성이고 실험 중이면 프롬프트로. 과설계는 금물이에요. 다섯째, 입구가 가리키나? 클로드 닷 엠디가 창고가 아니라, 색인처럼 어디에 뭐가 있는지 가리키고 있나 보세요. 재밌는 건, 이 다섯 가지가 앞에서 본 원리와 하나씩 정확히 짝을 이룬다는 거예요. 역할은 5강, 8강, 절차는 6강과 8강, 이런 식으로요. 그래서 원리를 알면, 이 체크리스트는 저절로 외워집니다.Four: file or prompt? Repeated, stable, shared goes to a file; one-off and experimental stays a prompt. No over-engineering. Five: does the entry point? Check whether CLAUDE.md is an index pointing to where things are, not a warehouse. Here's the fun part: these five map exactly, one by one, onto the principles we just saw — role to sessions 5 and 8, procedure to 6 and 8, and so on. So once you know the principles, this checklist memorizes itself.

12 · 구조화 운용 — 작게 시작해 키운다12 · Operating structure — start small, grow it

그럼 구조는 처음부터 다 짜야 할까요. 아니에요. 작게 시작해서 키우는 겁니다. 처음엔 클로드 닷 엠디 하나로 충분해요. 그러다 같은 역할이나 같은 절차가 두 번째로 반복되는 게 보이면, 그때 그릇으로 승격하세요. 에이전트는 슬래시 에이전츠 같은 명령으로 만들 수 있고요. 물론 정확한 명령이나 생성 흐름은 발표 시점 공식 문서가 진실입니다.So should you build the whole structure upfront? No. You start small and grow it. At first, one CLAUDE.md is plenty. Then, when you notice the same role or the same procedure repeating a second time, that's when you promote it to a vessel. You can create an agent with a command like slash-agents — and of course, the exact command and creation flow are whatever the official docs say at presentation time.

키울 때 두 가지 원칙만 지키세요. 첫째, 그릇은 짧고 단일 책임으로. 에이전트는 한 역할만, 스킬은 한 절차만 담습니다. 지난 강에서 메모는 짧고 구체적으로 적으라고 했던 것과 같은 원리예요. 둘째, 안 쓰는 그릇은 지웁니다. 구조도 정리 대상이에요. 메모리가 한 번 쓰고 끝이 아니라 키우는 거였던 것처럼, 구조도 살아 있는 그래프로 가꾸는 겁니다. 한 번에 완벽하게 짜려 하지 말고, 반복을 보고 키우세요.As you grow it, keep just two principles. First, vessels stay short and single-responsibility — an agent holds one role, a skill holds one procedure. Same principle as last session, where we said keep memos short and specific. Second, delete vessels you don't use — structure is also for tidying. Just as memory wasn't write-once but something you grow, structure is a living graph you tend. Don't try to build it perfectly in one shot — grow it as the repetition shows up.

13 · 한 줄 공식13 · One-line formula

오늘 배운 다섯 가지를 한 줄 공식으로 정리해볼게요. 전문가 Claude는, 역할은 에이전트에, 절차는 스킬에, 업무 근거는 업무 문서에, 그리고 입구는 클로드 닷 엠디에. 단, 반복되고 안정적이고 공유될 때만요. 지난 강의 룰 넘버 세븐, 매번 설명하지 말고 적어두라와 오늘의 룰 넘버 에이트, 구조화하라가 바로 여기서 만납니다. 그냥 적어두기에서, 구조 있게 적어두기로요. 일회성은 그냥 프롬프트로. 과설계는 금물입니다. 이 공식을 알면, 무엇을 어느 그릇에 담을지가 보입니다.Let me lock today's five into one formula. Expert Claude is: roles in agents, procedures in skills, work grounds in work docs, and the entry in CLAUDE.md — but only when it's repeated, stable, and shared. Last session's Rule Number Seven, "don't re-explain, write it down," and today's Rule Number Eight, "structure it," meet right here — from just writing it down, to writing it down with structure. A one-off stays a prompt; no over-engineering. Once you know this formula, you can see what goes in which vessel.

14 · RULE No.814 · Closing — Rule No.8

오늘 한 단어만 가져가신다면, 쌓기에서 구조화로, 입니다. 같은 지식이라도 한 더미로 쌓으면 박학한 신입이지만, 역할과 절차와 업무 근거 문서로 구조를 주면 분야 전문가가 돼요. 디렉터리 이름이나 파일 형식은 앞으로 바뀌겠지만, 지식을 종류대로 구조화하면 전문성이 생긴다는 이 원리는 그대로입니다. 자, 우리는 지난 두 강에서 지식을 적어두고, 구조화하는 법을 배웠어요. 다음 시간에는 한 걸음 더 나가서, 일을 시작하기 전에 먼저 설계하는 법, 프로젝트 설계법을 다뤄보겠습니다.If you take one word from today, it's: from piling to structuring. The same knowledge, piled into one heap, is a well-read rookie — but give it structure, with roles, procedures, and work-doc truth, and it becomes a domain expert. Directory names and file formats will change down the road, but this principle — structure knowledge by kind and expertise emerges — stays the same. Over the last two sessions, we learned to write knowledge down and to structure it. Next time, we go one step further: how to design before you start the work — Project Design.