Phase 2: Context Engineering for Builders · 45 min · Claude Code · MCP · Python

Rules, Skills, and Persistent Context

Everything always-needed goes in the rules file. Everything sometimes-needed goes in a skill you load on demand. Confusing the two bloats every single session.

Hiring signal: Structuring persistent context into always-loaded rules versus on-demand skills is a concrete architecture decision — describing it well signals you've actually built and maintained one of these systems, not just read about CLAUDE.md.

What you will learn

Distinguish rules files (CLAUDE.md, AGENTS.md, .cursorrules), skills, and MCP connections by when their content should load
Decide whether a piece of persistent context belongs in an always-loaded rules file or an on-demand skill
Explain MCP's role as a live context protocol rather than a copy-pasted, stale integration
Audit a real rules file for narrow, rarely-needed content that should be extracted into a skill

Introduction

Rules, Skills, and Persistent Context

A team's engineers each re-explain the same handful of project conventions at the start of nearly every AI-assisted session: use uv instead of pip, run the full test suite before committing, follow the existing error-handling pattern in errors.py, never touch the legacy billing module without flagging it for review. Nobody wrote this down anywhere the agent could read automatically. Some engineers remember to mention the billing warning; others don't, and one of them ships a change that violates it. This isn't a knowledge problem — everyone on the team actually knows these conventions. It's a persistence problem: the same information is being re-typed, inconsistently, in every session instead of living somewhere the agent loads it automatically.

Rules files: the always-loaded layer

A rules file — CLAUDE.md, AGENTS.md, .cursorrules, .windsurfrules, depending on the tool — is project-level, persistent context that loads automatically into every session without anyone re-typing it. This is the "write" strategy from earlier in this phase, applied at the project level instead of the session level: instead of re-stating conventions every time, you write them once, durably, and the tool reads them back automatically each session. This is exactly where the uv-not-pip convention and the test-before-commit rule belong — they're relevant to nearly every session, so they should load every time without anyone remembering to mention them.

The rules file test
Before adding something to a rules file, ask: will most sessions on this project need this? If yes, it belongs there. If it's only relevant to a specific, occasional task, putting it in the always-loaded rules file means every other session pays the token cost (and, per the distraction failure mode from the previous lesson, the attention cost) of content it never needed.

Unlock the full lesson

You've read the first 2 sections. The rest of this lesson covers Skills: the on-demand layer, MCP: live context, not a stale copy-paste, The three layers together, Build It — plus a hands-on lab, quiz, and project artifact.

Create a free account to unlock Phase 0 and Phase 1 of every course — no credit card.