Quick setup: a structured Claude

The map: what a structured Claude looks like

Out of the box, Claude Code is a brilliant amnesiac. Every session starts from zero: no memory of your projects, no knowledge of your rules, no accumulated lessons. Everything you taught it yesterday is gone this morning. This module fixes that. It is a hands-on assembly guide: at the end, you will have a structured Claude, one that remembers, follows your rules, improves over time, and maintains itself. Budget about one hour of setup.

A structured Claude is made of seven components, each covered by one lesson in this module:

• The engine: Claude Code itself, installed and logged in (next lesson).
• The constitution: a global CLAUDE.md file with your absolute rules, loaded at every session start.
• The memory: a folder of Markdown notes that Claude reads and writes across sessions, opened in Obsidian so you can see and navigate the same knowledge as a graph.
• The transport: the memory folder versioned with git, so your brain is backed up and synchronized across machines (including a phone).
• The reflexes: hooks, small scripts that run automatically at lifecycle events (session start, session end, after each turn) and keep the memory synchronized without you thinking about it.
• The capabilities: skills, installable expertise packs. We will install two proven collections, ECC (everything-claude-code) and superpowers, and learn to curate rather than hoard.
• The heartbeat: scheduled tasks that run nightly and weekly consolidation, so the structure maintains itself even when you are asleep.

Why bother? Because the value of an assistant compounds only if its knowledge does. An unstructured Claude solves the same problem for you twice and makes the same mistake twice. A structured Claude writes the lesson down the first time, links it to related lessons, and recalls it in the right context next month. The difference after three months of daily use is not subtle: this whole course was built with (and is largely a product of) exactly the setup you are about to install.

This module is deliberately self-contained. It overlaps with the deep-dive modules on extending Claude Code and on the second brain: those explain the why and the internals; this one gives you the ordered, copy-paste path. If a step intrigues you, follow the pointer to the full lesson. If you just want a working setup today, follow the commands in order and come back for theory later.

One principle before we start: structure lives in files, not in chat. Everything we install below is plain text on your disk: Markdown rules, Markdown notes, JSON settings, small scripts. Nothing is locked in a proprietary database, everything is versionable, inspectable and portable. That is what makes this setup durable across Claude versions: the files survive even when the tool changes.

Install Claude Code and log in

First component: the engine. Anthropic's recommended path since 2026 is the native installer, a self-contained binary that auto-updates and does not depend on Node.js at runtime:

• macOS / Linux / WSL: curl -fsSL https://claude.ai/install.sh | bash
• Windows (PowerShell): irm https://claude.ai/install.ps1 | iex

Package managers work too if you prefer them (brew install --cask claude-code, winget install Anthropic.ClaudeCode, or npm install -g @anthropic-ai/claude-code), with one caveat: brew and winget installs do not auto-update, and the npm route wants Node.js 22 or newer since v2.1.198. On native Windows, install Git for Windows as well: it gives Claude Code a proper Bash tool instead of falling back to PowerShell for everything.

Then run claude in a terminal. On first launch a browser opens for OAuth login. Two account types work, and the distinction matters for your wallet:

• A Claude subscription (Pro, Max, Team, Enterprise): usage is covered by the flat monthly fee, within the plan's rate limits. The free claude.ai plan does not include Claude Code.
• A Claude Console account (API): pay-as-you-go billing per token. Fine for teams with API budgets, dangerous for a personal setup, because a heavy agentic day can cost more than a month of subscription.

For a personal structured setup, the subscription route is almost always the right one. Watch one trap: if the ANTHROPIC_API_KEY environment variable is set, it can take precedence over your subscription and silently bill you per token. If you have an old key lying around in your shell profile, remove it or scope it to the projects that need it.

Verify the install with claude --version, then from inside a session run /doctor (alias /checkup). Doctor is a bundled diagnostic skill that checks your install health, PATH issues, unparseable settings files, slow hooks, and even flags unused skills or MCP servers that cost you context for nothing. Run it now to confirm a clean baseline, and remember it exists: it is the first thing to run whenever your setup misbehaves after the customizations we are about to add.

Where things live from now on: the directory ~/.claude/ is your Claude home. ~/.claude/CLAUDE.md will hold your global rules (next lesson), ~/.claude/settings.json your configuration and hooks, ~/.claude/skills/ your installed skills, and ~/.claude/projects/ the per-project data including memory. Every component of this module is a file somewhere under this tree or referenced from it.

Optional extras, worth knowing but not blocking: the IDE extensions (VS Code, JetBrains) embed the same engine in your editor; the desktop and web apps offer Claude Code sessions outside the terminal; and yes, Claude Code runs natively on an Android phone via Termux, which becomes genuinely useful once your memory is git-synced. The second brain module has a dedicated lesson on that pocket setup.

Your global CLAUDE.md: a constitution, not a novel

Second component: the constitution. The file ~/.claude/CLAUDE.md is injected into every session, across all projects, with the strongest instruction priority the harness gives to user content. It is the single most leveraged file in your whole setup: one line here changes the behavior of every future session. That leverage cuts both ways, so the file must be curated ruthlessly.

A battle-tested structure, refined over months on the course author's setup:

• Absolute rules first. The non-negotiables, stated as commands, at the very top: formatting bans, safety rules (archive, never delete), how secrets are handled (environment variables, never pasted in chat), and where Claude's autonomy ends (for the author: external paid costs, security decisions and product decisions go to the human; everything technical is Claude's call).
• Session startup. What Claude should do at the start of each session: which memory index to read, how to route to the right project context when you name one.
• Pointers, not content. One line per recurring protocol, pointing to the file that owns it (a skill, a memory note). The detailed protocol lives in exactly one place; CLAUDE.md just routes to it.

The pointer principle deserves emphasis, because it is where most setups rot. If you paste a full protocol into CLAUDE.md and into a skill and into a memory note, the three copies drift apart within weeks and Claude follows whichever it read last. The rule: CLAUDE.md is a router. Detail lives in the skill or note it points to, and is updated there only. This also keeps the file small, which matters twice: every byte is loaded into every session's context, and a short constitution is one Claude actually follows. Under 5 KB is a good target; if yours crosses 10 KB, it has almost certainly absorbed content that belongs in a skill.

A minimal skeleton to start from:

# Rules (absolute)
- Never delete: archive to _ARCHIVES/ instead.
- Secrets never in chat: set env vars, verify by length, never echo.
- Technical decisions: decide and execute. Escalate only paid costs,
  security, and product decisions.
- Update the memory after every delivered batch of work.

# Session start
- Read the memory index. When I name a project, load its memory notes
  before acting.

# Protocols (pointers)
- Memory sync protocol: see the sync-memory note.
- New project: attach the code-graph tool, reuse existing patterns first.

Three operational details. First, changes apply at the next session, not the current one: CLAUDE.md is read once at startup, so test edits by opening a fresh session. Second, keep an archive of previous versions (a dated copy in an archive folder) before any rewrite: your constitution is exactly the kind of file you will want to roll back someday. Third, if you work on Windows with PowerShell scripts touching your files, consider keeping the file pure ASCII: it avoids a whole class of encoding corruption when tools rewrite it.

Project-level CLAUDE.md files (in each repo root) stack on top of the global one and carry project-specific facts: build commands, architecture notes, conventions. Same principles apply: short, imperative, pointers over prose. The global file carries who you are and how you work; the project file carries what this codebase is.

Plug Obsidian into Claude's memory

Third component: the memory, and the window into it. Claude Code persists memory as plain Markdown notes in a per-project folder under ~/.claude/projects/<project-slug>/memory/, with an index file, MEMORY.md, loaded into context at each session start. That folder is the brain. Obsidian is the free tool that turns the same folder into something a human can navigate: backlinks, full-text search, and a graph view where your knowledge becomes visible.

The setup move that makes everything work is deceptively simple: open the memory folder itself as your Obsidian vault. Not a copy, not an export, the folder itself. Download Obsidian from obsidian.md (free, no account needed; on Windows, winget install Obsidian.Obsidian), choose "Open folder as vault", and point it at the memory directory. From then on there is a single source of truth: what you see and edit in Obsidian is exactly what Claude loads and writes. No synchronization, because there is nothing to synchronize.

Inside the vault, three conventions keep the brain healthy as it grows from ten notes to several hundred:

• Atomic notes. One fact per note, with a frontmatter header carrying a name, a one-line description (used for recall relevance), and a type: is this about the user, a piece of feedback on how to work, a project state, or an external reference? A note with two ideas is a note you cannot link precisely.
• Wikilinks everywhere. Every note links to its related notes with [[note-name]] links. Link liberally: the graph's value is the connections. A link to a note that does not exist yet is not an error, it is a marker of something worth writing.
• Maps of content. A handful of hub notes (a common convention prefixes them _MOC_) that gather links by theme: projects, feedbacks, references. Plus the index MEMORY.md: one line per note with its hook. The iron rule: no orphan notes. Every new note gets a line in the index and a link from the relevant hub, or it will never be recalled.

One structural subtlety if you work on several projects: Claude keeps a separate memory folder per working directory, so knowledge fragments across stores. The fix on the author's setup is filesystem links (junctions on Windows, symlinks elsewhere): the per-project memory folders are mounted as subfolders (for example _projets/<name>) inside the one home vault. Obsidian sees a single unified brain; each project store remains physically where Claude expects it; editing through the mount edits the real store. One vault, many stores, zero copies.

Two quality-of-life touches worth stealing: color the graph by note type (Obsidian graph groups: one color for project_ notes, another for feedback_, another for reference_), so the shape of your knowledge is readable at a glance; and keep bulky, regenerable material (exported conversation logs, generated code graphs) excluded from the main graph filter so it does not drown the signal.

That is the whole trick. No plugin marketplace spelunking required, no paid sync: one folder, opened by two programs, each seeing what the other writes. The deep-dive lessons earlier in the second brain module cover the recall mechanics and note-writing discipline; the next lesson makes this brain durable and portable with git.

Version your brain with git

Fourth component: the transport. Your memory vault is now the most valuable directory on your machine, and it lives in a dot-folder that no backup tool thinks about. The fix is the same one code uses: make the vault a git repository with a private remote. You gain history (every note change is a commit you can inspect and revert), backup (the remote survives your disk), and synchronization (the same brain on your desktop, your laptop, and even your phone).

Before the first push, audit for secrets. This step is not optional. Months of working notes accumulate exactly the things that must never reach a remote: tokens pasted during debugging, passwords quoted in session summaries. Grep the vault for the classic patterns (sk_live, ghp_, AKIA, long hex strings, the words password and token) and redact hits by replacing the value with a marker before committing. The author's first scan of a mature vault found a production admin password sitting in a session note; assume yours has an equivalent.

Then scope what travels. A good default .gitignore excludes what is bulky, regenerable, or risk-laden:

• Exported conversation logs (they can contain anything you ever pasted, including secrets),
• Generated artifacts like code graphs (regenerable from source),
• Archive folders and workspace state files of Obsidian.

The atomic notes, the index, the hub notes: those are the brain, and those travel.

The daily protocol is two habits: pull at the start of any session that will touch memory, commit and push after each memory update, with a message naming the subject. If that sounds like discipline you will forget, you are right, which is why the next lesson automates both ends with hooks. On conflicts, apply the memory-specific rule: never overwrite, keep both versions in the note and flag the contradiction for review. A brain merges by accretion, not by force-push.

The payoff that surprises people: the phone. Claude Code runs natively on Android inside Termux, and once your vault is a git repo, the phone clones it and mounts it as its own session memory (a symlink from the phone's ~/.claude/projects/<slug>/memory to the clone). Desktop Claude and pocket Claude then read and write the same brain, a commit apart. A dedicated lesson in this course's second brain module walks through that pocket setup, traps included.

One caution to close: a private repo is private to the hosting account. Treat the vault remote with the same care as a password manager export: strong authentication on the account, no sharing the repo casually, and remember that redaction before commit beats deletion after push, because git history remembers what you pushed even after you remove it.

Hooks that keep the structure alive

Fifth component: the reflexes. Everything installed so far depends on habits: pull before working, update memory after a batch, push when done. Habits decay. Hooks are Claude Code's mechanism for turning them into automation: shell commands that the harness itself runs at lifecycle events. They are configured in ~/.claude/settings.json (user-wide) or a project's .claude/settings.json, and as of mid-2026 there are around thirty events to hook, from SessionStart and SessionEnd to Stop (end of each assistant turn), PreToolUse, PostToolUse and beyond.

For a structured setup, two hooks carry most of the value:

• SessionStart pulls the brain. A script that runs git pull --ff-only on the vault, with a short timeout, and never blocks the session if the network is down. Every session starts with the freshest memory, automatically.
• SessionEnd (or Stop) pushes it. The mirror image: commit and push memory changes when the session closes, so nothing you learned is stranded on one machine.

The shape in settings.json:

{
  "hooks": {
    "SessionStart": [{ "hooks": [{ "type": "command",
      "command": "bash ~/.claude/hooks/pull-brain.sh" }] }],
    "SessionEnd": [{ "hooks": [{ "type": "command",
      "command": "bash ~/.claude/hooks/push-brain.sh" }] }]
  }
}

A more advanced pattern from the author's setup solves a real gap: there is no native "session went idle" event, yet you want memory synchronized when you wander off mid-session. The solution is a two-stage architecture. Stage one, a global Stop hook: after every assistant turn, a tiny script registers the session (id, transcript path, working directory) in a pending file, costing milliseconds. Stage two, a scheduled task every 15 minutes: it checks pending sessions, and for any whose transcript has not changed in 30 minutes, runs Claude headless against that same session (claude -p --resume <session-id> "sync memory...") so the model itself writes the session's lessons into the vault. Idle sessions get their memory saved without anyone touching the keyboard.

Automation that calls Claude from a hook chain needs anti-loop guards, and they are worth internalizing even if you copy nothing else: the headless runs set a marker environment variable so the Stop hook ignores their own turns (otherwise each sync spawns registrations that spawn syncs); a stamp file records what state was already synced so the same idle session is never processed twice; a lock prevents overlapping runs; and caps bound the damage (at most two syncs per pass, hard timeout each). Any hook that can trigger the thing that triggered it must carry this kind of guard.

Operational notes. Hooks load at session start: sessions already open when you edit settings.json do not gain the new hook until relaunched. Keep hooks fast and non-blocking: a slow SessionStart hook delays every session you will ever open (the /doctor checkup flags slow hooks for exactly this reason). Log failures somewhere visible instead of failing loudly: the author's scripts append a line to an alerts note in the vault, which surfaces in Obsidian where a human actually looks. And treat hooks as code: they run unattended with your permissions, so version them alongside the vault.

Skills: install ECC and superpowers, curate hard

Sixth component: the capabilities. Skills are folders of instructions (a SKILL.md plus optional scripts) that teach Claude a workflow, and the ecosystem around them has matured into real collections you can install in minutes. Two are worth installing on day one of a structured setup, and one discipline keeps them from backfiring.

ECC (everything-claude-code) is the largest curated collection, by Affaan Mustafa, MIT-licensed. Note the repository was renamed in 2026: the canonical address is now github.com/affaan-m/ECC (the old everything-claude-code URL redirects). As of July 2026 it bundles 278 skills, 67 agents, 34 rules and a set of hook automations, covering agent orchestration, frontend patterns, testing, git workflows, security scanning and much more. Install it as a plugin:

/plugin marketplace add https://github.com/affaan-m/ECC
/plugin install ecc@ecc

superpowers, by Jesse Vincent, is the other keystone: not a pile of capabilities but a process discipline. It installs workflow skills that force good engineering habits: brainstorming before building, systematic debugging before patching, test-driven development, verification before claiming completion. It lives in the official Anthropic plugin marketplace, so installation is a single command, no marketplace add needed:

/plugin install superpowers@claude-plugins-official

Its core rule is worth adopting verbatim: if a skill might apply to the task at hand, invoke it before acting. Skills you have but never invoke are dead weight.

Now the discipline: curate, do not hoard. It is tempting to install all 278 ECC skills. Resist. Every installed skill's name and description participates in skill matching; hundreds of irrelevant ones pollute that matching and burden the context. When the author of this course integrated ECC, he kept 67 skills out of the 271 the repo had then: the agent-orchestration, frontend, engineering, QA and content categories that matched his real stack, and deliberately skipped whole categories (crypto trading, HIPAA healthcare, five backend stacks he never touches). Install what maps to work you actually do; you can always add a skill the day you need it. The /doctor checkup now even flags unused skills as context cost, which tells you how real the problem is.

Third-party skills from outside big-name sources deserve one more gate: an audit before installation. A skill runs with the full permissions of your agent. The vetting protocol, covered in depth in the safety module's lesson on auditing third-party skills: clone into a quarantine folder without executing anything, read every script, grep for dangerous patterns (eval and exec calls, network calls, base64 blobs, destructive commands, prompt-injection phrasing like "ignore previous instructions"), then copy only the audited folder into ~/.claude/skills/, never a whole unaudited bundle. Discovery beyond the marketplaces: the find-skills skill searches the open ecosystem, and directories like skills.sh rank skills by real installs.

After installing, restart the session (or run /reload-plugins) and test-drive one skill end to end: ask for a task the skill covers and confirm Claude announces it is using it. If it does not trigger, the usual cause is a description mismatch: the skill's description does not contain the words you naturally use. That is fixable (edit the description), and knowing to check it puts you ahead of most users.

The heartbeat: scheduled tasks, nightly dreaming, statusline

Seventh component: the heartbeat. Hooks react to sessions; scheduled tasks act when no session is running. This layer is what makes the structure self-maintaining: consolidation, refresh and audits happen nightly and weekly whether or not you showed up that day. On Windows the scheduler is Task Scheduler (schtasks or PowerShell's ScheduledTasks module); on macOS and Linux, cron or launchd. Each task is a small script plus a schedule.

The rhythm on the author's setup, as a template:

• Evening, conversations flow into the brain. A daily task exports recent Claude sessions to Markdown inside the vault (the pip package claude-conversation-extractor does this) and refreshes the derived knowledge graphs. Past conversations become searchable material instead of lost history. One hard-won guard: pipe the exports through a secret-redaction script before anything indexes them, because raw transcripts contain whatever was ever pasted.
• Night, the dream. A daily consolidation task (the author runs it at 21:00, after the export) launches Claude headless with a dedicated skill: reread recent conversations and memory, extract durable facts into properly formed notes, merge duplicates, weave wikilinks, keep the index clean. Two safety rules are built in: a dated backup of the notes before each run, and archive, never delete: a contradicted note gets an obsolete banner and moves to an archive folder rather than vanishing. The name is no accident: Anthropic previewed exactly this idea as "dreaming", agents consolidating memory between sessions; a self-hosted version is a few dozen lines of prompt.
• Every 15 minutes, the idle-sync from the hooks lesson, catching sessions you abandoned mid-thought.
• Weekly, the vault lint. A task that walks the vault for broken wikilinks, orphan notes, dead index entries and oversized notes. Entropy accumulates in any linked system; a weekly sweep keeps the graph honest.

One convention ties the layer together: alerts land in the vault. Every task appends failures and findings to a single alerts note at the vault root. Logs live next to the scripts for forensics, but the note is what a human sees, because it shows up in Obsidian where you already look. Automation you never hear from is automation you cannot trust; automation that emails you is automation you learn to ignore. A note in the brain is the middle path.

Finishing touch, the statusline: Claude Code renders a custom status bar by piping session JSON (model, context usage, cost, rate-limit state) into a command you configure under statusLine in settings.json. A small script turns that into a live dashboard: context percentage, quota bars, cost of the session. One documented trap from the author's machine: refreshInterval is in milliseconds. Set to 1, it spawned a fresh interpreter process roughly 28 times per second and visibly froze the terminal; 1000 (one tick per second) is a sane value. When your terminal stutters mysteriously, check that number first.

With the heartbeat installed, step back and look at what you built across this module: rules that load themselves, memory that writes itself, sync that happens without you, skills that fire on their own triggers, and maintenance that runs while you sleep. The last lesson compresses it all into a checklist you can rerun on any new machine.

The one-hour checklist

Everything in this module, compressed into the runbook you can replay on any new machine. Times are honest estimates for someone doing it the second time; first time, double them and enjoy the scenery.

Phase 1: engine (10 min)

• Native installer for your OS, then claude --version.
• Log in with the subscription account; hunt down any stray ANTHROPIC_API_KEY.
• /doctor: clean baseline confirmed.

Phase 2: constitution (10 min)

• ~/.claude/CLAUDE.md: absolute rules first, session-start routine, pointers only.
• Fresh session recites your rules back correctly.

Phase 3: memory and Obsidian (10 min)

• Install Obsidian, open the live memory folder as the vault.
• First atomic note with frontmatter; line in MEMORY.md; wikilink from a hub.
• New session recalls the note's fact unprompted.

Phase 4: git transport (10 min)

• .gitignore for conversations, generated graphs, archives.
• Secrets scan, redact, THEN first push to a private remote.
• Edit, commit, push: history works.

Phase 5: hooks (10 min)

• SessionStart pull-brain hook (ff-only, timeout, exit 0 always).
• SessionEnd or Stop push path, with anti-loop guards if anything calls Claude.
• Fresh session proves the pull fired; /doctor confirms no slow hook.

Phase 6: skills (10 min)

• /plugin install superpowers@claude-plugins-official.
• ECC marketplace added, installed, then pruned to your stack.
• One skill triggers from a task phrased in your own words.

Phase 7: heartbeat (10 min, plus overnight to verify)

• Daily conversation export with secret redaction; nightly dream with backup and archive-never-delete; weekly vault lint.
• Alerts note at the vault root as the single reporting channel.
• Statusline configured, refreshInterval at 1000 ms.

The verification mindset matters more than the list: every phase ends with a proof, not a feeling. A fresh session that recites rules, a note recalled unprompted, a hook that demonstrably fired, a skill that triggered unnamed. If you cannot show the proof, the phase is not done, whatever the config files say.

Where to go from here: the extending module for MCP servers and writing your own skills, the second brain module for recall mechanics and the pocket setup on Android, the orchestration module when one Claude stops being enough, and the safety module before your hooks and skills multiply. The structure you just built is the foundation all of those stand on. Maintain it with the one habit that outranks every tool in this course: when you learn something durable, write it into the brain before you close the session.