AI at work · course 31 of 105
Claude Code Under Your Rules
Control what Claude Code remembers, may do and runs around it: where memory and settings files live and which one wins, permission rules, and hooks with their exit codes.
Not on sale yet. When sales open: $4.99 for this course, paid once, or every course for $9.99 a month. Prices
Preview
What it teaches
The parts of Claude Code that decide what it remembers, what it may do and what runs around it, as Anthropic’s docs state them. Where the memory files and settings files live and which one wins when two disagree (a project CLAUDE.md, your own ~/.claude/CLAUDE.md, the user, shared-project and project-local settings files, the command line, managed settings). The permission rules (allow, ask, deny; Bash(...), Read(...), WebFetch(domain:...)), which list wins when several match, what a rule does to a given request, and writing a permissions block for a stated need (“never let it read .env”). Hooks: the events, what a matcher matches, what exit code 2 does against exit 0 and exit 1, and writing a hooks block. The AI asks 3 questions, places you, shows a short card per module, then gives you one question at a time.
It is a drill on the documented rules, not a setup service: it can’t see your files or tell you why your own Claude Code does something.
Not in this course: MCP servers (claude mcp add, .mcp.json and MCP scopes), the Claude API, and how to write prompts.
How long
36 items (9 concept, 27 scored). About 15-35 rounds for someone who already edits settings files, up to about 55-70 for a beginner, plus a 12-item final: 2-3 sessions (AI-simulated students took 17 and 65 rounds; not timed with a real student). The tutor gives a one-line save code at the end of each session.
The modules
4 modules, drilled one item at a time.
- M0
The words
The words the docs use: CLAUDE.md, settings files, permission rules and modes, hooks, commands, subagents
- M1
Memory and settings files
Where memory and settings files live, which settings file wins, and what lists and @ imports do
- M2
Permissions
Which commands or hosts a permission rule matches, which rule wins, and writing a permissions block
- M3
Hooks
Hook events, what a matcher matches, what exit code 2 does, and writing a hooks block
Before it teaches, it asks
- 1What do you want Claude Code to do for you (your own projects, work with a team, just looking around), and have you edited a CLAUDE.md or a settings file before?
- 2Where is the settings file that applies to you in every project on this machine?
- 3Your settings have deny Bash(aws *) and allow Bash(aws s3 ls). Claude wants to run aws s3 ls. Does it run, ask you, or get blocked?
What’s exact, and what isn’t
Show
Straight from the course’s own notes.
- Quotes
- The facts on a card are sentences or table cells from Anthropic’s Claude Code docs, quoted word for word (each M0 answer is built from a quoted sentence); the short connecting phrases around them (for example the first and sixth lines of the M2 card and the order list on the M1 card) are this course’s wording of what the same pages say (the settings, permissions, memory, hooks, overview, commands and sub-agents pages, all read 2026-10-13). A script checks every quoted fragment in the module files word for word on a saved copy of its page, and fails if a saved page changes. It does not re-fetch the live pages. The Claude Code docs pages read state no licence, so the course uses short quotes only. The one-line “Plain words” at the end of each card are this course’s own glosses of general terms, not quotes.
- M1
- The file keys are paths the docs name (a script checks each is in the quoted text and never in the question); the keys for lists and for imports are what the docs say happens (lists combine; an @ import loads at launch). The two “which file wins” keys are computed from the order of the settings page’s own list (managed, command line, project local, shared project, user), read from the page text by script.
- M2
- The commands-and-hosts keys and the which-list-wins keys come from a small matcher written for this course from the permissions page’s stated rules (* wildcards, a trailing space then *, WebFetch domains, deny then ask then allow); it is checked against that page’s own example rows, and each wrong answer for these keys is reproduced by a named wrong reading of the same matcher. It models the documented rules, not Claude Code itself, and only cases the docs state. Each JSON key is valid against SchemaStore’s published claude-code-settings.json schema (draft-07, checked with jsonschema 4.26.0) and passes a field check; each wrong block fails that field check, and a script proves it is the slip it names.
- M3
- Event names and the exit-code-2 effect per event are parsed by script from the hooks page’s two tables (33 events listed there); matcher keys come from an engine that follows the page’s matcher table; the two hooks blocks are checked against the schema and a field check, like M2's.
- Honest limits
- Claude Code changes fast: docs read 2026-10-13, Claude Code 2.1.293 installed on the machine that built this. The schema can lag the program (the settings page says so; it lists 31 hook events, the hooks page 33, and no key uses an event the schema lacks). The course can’t see your real setup. Settings that need an administrator or a paid organisation plan (managed settings) are named, not practised. Hooks are drilled as shell-command hooks only. No running code is needed or checked.
- Not in it yet
- The .claude/rules/ folder, auto memory, AGENTS.md, the @path import depth limit, Read/Edit path anchors (//, ~/, /) and ! negation, permission modes in practice (named in M0 only), sandboxing, hook JSON output (permissionDecision), the if field, HTTP, prompt and agent hooks, onFailure (needs Claude Code 2.1.295; the course was built on 2.1.293), skills, plugins and custom subagent files.