Tutorial · System Architecture
Files. Layers.
Architecture.
An introduction to the engineering and philosophy behind how your Claude system actually works — and what to tell it from day one.
Nathaniel Solace
·
ThoughtLeaderAI
The Problem
Most people skip
the foundation.
They start prompting before they’ve built anything for Claude to stand on. No file structure. No rules. No context system. Every session starts from zero because there’s nothing to start from.
The Truth
Your Claude system is only as good as the architecture underneath it. This tutorial shows you what that architecture looks like.
The Framework
Every Claude system has
four layers.
Whether you’ve built one intentionally or not, these layers exist in every system. The question is whether yours are designed or accidental.
L1
Physical Layer
What files exist, where they live, what format they’re in. The raw materials of your system.
L2
Functional Layer
What each component does. Rules files govern behavior. Skills handle workflows. Dashboards track state.
L3
Logical Layer
How things connect. Routing protocols, handoffs between components, what reads what and when.
L4
Principle Layer
Why it’s set up that way. The governing philosophy. This layer makes every other layer coherent.
Layer 1 · Physical
The files that make up
your system.
Every Claude system is built from a small set of file types. Each one has a distinct job. Understanding these is understanding the atoms of your system.
.md
Markdown — The Operating Manual
Rules files, context documents, guides, protocols, debriefs. These are what Claude reads to understand how to behave. They’re the nervous system of your operation.
.html
HTML — The Visible Layer
Dashboards, landing pages, command centers. Single-file apps where data lives in a JavaScript block. No server needed. Claude reads and writes the DATA block directly.
.json
JSON — The Config Layer
Settings, permissions, hook definitions. These tell Claude Code what it’s allowed to do, what tools are available, and how the environment is configured.
SKILL.md
Skills — The Capability Layer
Reusable instruction sets that tell Claude how to handle specific types of work. The depth of a skill directly determines the quality of its output.
Layer 1 · Physical
How your folders
should look.
Your working directory is the physical container for everything. Organize it by domain, not by file type.
CLAUDE/ ← your working directory
├── _CLAUDE_RULES.md ← master operating rules
├── TASK_FLOW.md ← capture inbox between sessions
├── System Debriefs/ ← reference docs for orientation
├── project-maps/ ← visual trackers per project
├── skills/ ← reusable capability files
├── 01_PROJECT_A/
│ └── _CLAUDE_RULES.md ← project-level overrides
├── 02_PROJECT_B/
│ └── _CLAUDE_RULES.md
└── 99_ARCHIVE/ ← completed or inactive work
├── _CLAUDE_RULES.md ← master operating rules
├── TASK_FLOW.md ← capture inbox between sessions
├── System Debriefs/ ← reference docs for orientation
├── project-maps/ ← visual trackers per project
├── skills/ ← reusable capability files
├── 01_PROJECT_A/
│ └── _CLAUDE_RULES.md ← project-level overrides
├── 02_PROJECT_B/
│ └── _CLAUDE_RULES.md
└── 99_ARCHIVE/ ← completed or inactive work
Key Principle
Every project folder gets its own _CLAUDE_RULES.md. This file extends the master rules with project-specific context and constraints.
Layer 2 · Functional
What each piece
actually does.
The Key Components
Five types of files. Five distinct jobs.
1. Rules files (_CLAUDE_RULES.md) — Govern Claude’s behavior. What to do, what never to do, how to route work, what voice to use.
2. Context files — The shared brain. Persists across sessions and interfaces. Updated as the system evolves.
3. Skills (SKILL.md) — Reusable workflows. When a type of work comes up, the skill fires and handles it with zero re-explanation.
4. Dashboards (.html) — Visual state. Command centers, project maps, client trackers. Claude reads and writes the data; you see the result.
5. Logs and debriefs — Institutional memory. What happened, what was decided, what the next session needs to know.
2. Context files — The shared brain. Persists across sessions and interfaces. Updated as the system evolves.
3. Skills (SKILL.md) — Reusable workflows. When a type of work comes up, the skill fires and handles it with zero re-explanation.
4. Dashboards (.html) — Visual state. Command centers, project maps, client trackers. Claude reads and writes the data; you see the result.
5. Logs and debriefs — Institutional memory. What happened, what was decided, what the next session needs to know.
Layer 2 · Deep Dive
The rules file is the
most important file you’ll write.
What Goes In a Rules File
It’s not instructions. It’s an operating system.
A good _CLAUDE_RULES.md contains:
• Who Claude is in this context — its role, its domain, its boundaries
• What it should do at session start — what to read, what to check, what to report
• How work gets routed — what belongs here vs. what gets handed off
• Naming conventions — how files, projects, and codes work
• Voice and tone standards — how output should sound
• Hard no’s — things Claude must never do (these prevent drift)
• Protocols — session-open, handoff, end-of-day, approval loops
This file is a living document. It gets smarter every session. When Claude gets something wrong, you codify the correction. When a pattern emerges, you add it. The document accumulates intelligence.
• Who Claude is in this context — its role, its domain, its boundaries
• What it should do at session start — what to read, what to check, what to report
• How work gets routed — what belongs here vs. what gets handed off
• Naming conventions — how files, projects, and codes work
• Voice and tone standards — how output should sound
• Hard no’s — things Claude must never do (these prevent drift)
• Protocols — session-open, handoff, end-of-day, approval loops
This file is a living document. It gets smarter every session. When Claude gets something wrong, you codify the correction. When a pattern emerges, you add it. The document accumulates intelligence.
Layer 3 · Logical
How everything
connects.
Files don’t work in isolation. The logical layer defines how data flows between components, what triggers what, and how the system stays coherent.
📱
Capture Interface
Mobile, chat, voice. Captures inputs and routes them. Does not execute.
📊
Source of Truth
Dashboard or command center. Stores all state. Claude reads and writes. You see the whole picture.
⚡
Execution Layer
Claude sessions, agents, automations. Handles the work. Drafts externals for your approval.
The Golden Rule
Capture interfaces capture. The source of truth stores. The execution layer executes. Each layer does one thing. Never mix them.
Layer 3 · Routing
Teach Claude where things go
from day one.
Routing Principles
Every input needs a home. Claude should know where.
Your rules file should define:
Project routing: "Anything about X goes to folder Y."
Domain routing: "Tasks about marketing go here. Client work goes there."
Approval routing: "Internal work runs autonomously. External work needs my sign-off."
Handoff routing: "If a session is getting long, write a handoff report and tell me where to pick up."
Without routing rules, Claude has to guess where things go. Guessing creates drift. Routing creates order.
Project routing: "Anything about X goes to folder Y."
Domain routing: "Tasks about marketing go here. Client work goes there."
Approval routing: "Internal work runs autonomously. External work needs my sign-off."
Handoff routing: "If a session is getting long, write a handoff report and tell me where to pick up."
Without routing rules, Claude has to guess where things go. Guessing creates drift. Routing creates order.
Layer 4 · Principle
The philosophy that makes
everything coherent.
Why This Layer Matters Most
Without principles, your system is just a collection of files.
The principle layer answers the questions that guide every design decision:
• What is Claude’s role? — Infrastructure, not a tool. An operator, not an assistant.
• What do I own vs. what does Claude own? — Creative direction and approval vs. execution and continuity.
• What should compound? — Context, skills, and institutional knowledge. Every session makes the next one better.
• What should never happen? — External actions without approval. Generic output. Lost context between sessions.
When you’re unsure how to set something up, your principles give you the answer. They’re the constitution of your system.
• What is Claude’s role? — Infrastructure, not a tool. An operator, not an assistant.
• What do I own vs. what does Claude own? — Creative direction and approval vs. execution and continuity.
• What should compound? — Context, skills, and institutional knowledge. Every session makes the next one better.
• What should never happen? — External actions without approval. Generic output. Lost context between sessions.
When you’re unsure how to set something up, your principles give you the answer. They’re the constitution of your system.
Practical
What to tell Claude
from day one.
You don’t need a perfect system to start. But you need to start with the right things in place.
Your Day-One Checklist
Five things to establish before you do anything else.
1. Create your working directory. One folder. Everything lives here.
2. Write your first _CLAUDE_RULES.md. Even five lines is enough: who Claude is, what your domain is, what it should never do.
3. Establish naming conventions. How files are named. How projects are coded. One system, used everywhere.
4. Set up a capture inbox. A TASK_FLOW.md or equivalent. Somewhere to drop things between sessions so nothing falls through.
5. Define the approval boundary. What can Claude do autonomously? What needs your sign-off? Draw the line on day one.
2. Write your first _CLAUDE_RULES.md. Even five lines is enough: who Claude is, what your domain is, what it should never do.
3. Establish naming conventions. How files are named. How projects are coded. One system, used everywhere.
4. Set up a capture inbox. A TASK_FLOW.md or equivalent. Somewhere to drop things between sessions so nothing falls through.
5. Define the approval boundary. What can Claude do autonomously? What needs your sign-off? Draw the line on day one.
The Path Forward
From foundation to
full system.
01
Week 1: Foundation
Working directory. Rules file. Naming conventions. Capture inbox. You have a system — not just a chat window.
02
Week 2: Context
Context files that persist across sessions. Project-level rules. Living documents that accumulate intelligence.
03
Week 3: Skills & Routing
Your first skills. Routing rules. Handoff protocols. The system starts to handle work without re-explanation.
04
Week 4: Infrastructure
Dashboards. Automation. Cross-interface sync. The system runs while you’re not in it.
The Point
You don’t build the whole thing at once. You build the foundation, then add layers. Each layer makes the next one possible.
The Architecture
Build the system
first.
Files. Layers. Routing. Principles. This is the backend of your Claude system. Everything you prompt, everything Claude produces, everything that compounds — it all stands on this architecture.
Remember
The people who get the most from Claude didn’t write better prompts. They built better architecture.
Nathaniel Solace
·
ThoughtLeaderAI
© 2026 Nathaniel Solace / Solace Labs. All rights reserved. ·
Terms & Conditions · Privacy & AI Safety
