D
daemonstack
← Daemonstack for Developers

Module 00Free preview

Fundamentals

CLAUDE.md, SOUL.md, agents vs MCP vs skills. The vocabulary and the skeleton.

Why this matters

You probably already use Claude. Maybe you ship code with it. But you keep hitting the same wall: it forgets the project's conventions, it suggests changes that contradict last week's decisions, it can't find the right file in your monorepo.

The issue isn't Claude. It's that you're using it as a chatbot, not as an engineer with context.

This module is the foundation. By the end, you'll have a mental model for how Claude *should* work in a real codebase: not session-by-session, but stateful, opinionated, and consistent.

The three layers

Daemonstack treats Claude in three layers:

  1. Constitution — CLAUDE.md. The project's principles, conventions, approval rules. Loads at session start. Rarely changes.
  1. Persistent memory — MEMORY.md. What happened, what was decided, what we learned. Grows over time. Pruned occasionally.
  1. Capabilities — agents (specialists), skills (procedures), hooks (lifecycle triggers). Loaded as needed. Composable.

Most people skip layers 2 and 3. They have a CLAUDE.md (sometimes) and treat each session as new. That's why their Claude feels generic.

The shift in mindset

You're not "asking Claude to write code".

You're configuring an engineer who:

  • Reads the project's constitution before every change
  • Remembers what was decided last sprint
  • Activates specialized agents for review, debugging, refactoring
  • Asks for approval on risky moves
  • Records new decisions to memory

That's the difference between Claude-as-tool and Claude-as-teammate.

What `CLAUDE.md` is NOT

Common mistake: people stuff CLAUDE.md with: - "Use proper variable names" - "Write good code" - "Always test your changes"

These are obvious. They waste context window. Claude already knows.

CLAUDE.md should contain: - Your stack (with versions if they matter) - Conventions specific to this project (file structure, naming patterns *your team* picked) - Approval rules (what requires confirmation before doing) - Pointers to detailed docs (ADRs, runbooks) rather than copy-pasting them

If a rule would apply to any project, it doesn't belong here.

What `MEMORY.md` is NOT

Common mistake: treating MEMORY.md as a diary.

2026-05-23: spent 4 hours on the bug, lunch was good, finally got the test green

That's useless to future-you (and future-Claude).

A memory entry should be:

Why: Mobile clients started failing with 401 after the JWT lib upgrade. Root cause: lib changed the default expiry from 24h to 1h.

Decision: Pin the lib version + add explicit expiry config. Don't trust library defaults for security-critical settings.

Side effects: Bumped expiry to 12h (matches mobile session expectations). ```

The future reader (you, a teammate, Claude) gets context, decision, and what changed.

Your first task after this module

  1. Open the CLAUDE.md that came with your Starter Pack
  2. Read it line by line. Edit anything that doesn't match your actual project
  3. Delete sections that don't apply
  4. Add the 3 things your project does that nobody outside knows about

Should take 15-20 minutes. The result is your project's first real Constitution.

In Module 1 we'll dig into the diagnostic loop: how to know what's actually slowing you down and where Claude can help most.