Claude Code with PHP course

The foundation: CLAUDE.md

The file Claude reads at the start of every session. Most of this section is about what you leave out of it.

• The three levels and their scope: yours across every project, the repository's for the team, the local one for your own unversioned settings.
• What belongs there: the project's conventions, its pitfalls, the rules of judgement.
• What does not belong: an instruction that must apply every single time — that is a hook's job — and reference documentation, which is read on demand.
• Writing instructions that hold: short, imperative, verifiable, and born of a real mistake rather than an intention.
• What the file costs: it takes up context at every session. Measure before adding a line.
• Bootstrap with /init, then correct it session after session.

The "memories"

What Claude carries from one session to the next, and why it differs from a CLAUDE.md.

• The distinction that governs everything: memory is learned as the work goes, a CLAUDE.md is decided and reviewed.
• The four kinds: who you are, the corrections you have given, the project's constraints, external resources.
• What not to store: what the repository already states, and what is only true for the length of one conversation.
• How a memory resurfaces — and why to check it before acting: it dates from the day it was written.
• Upkeep: merge duplicates, delete what has become false.

Skills

A set of instructions kept aside, loaded only when the subject comes up.

• The problem they solve: a growing CLAUDE.md costs you at every session, a skill only costs you the day it is needed.
• The anatomy: a folder, a SKILL.md, a name — and a description, which is what triggers loading. That is the line to get right.
• The scopes: a project skill, versioned and shared with the team; a personal skill; a skill shipped by a plugin.
• Triggering one by hand, or letting it come.
• Workshop: write the skill for a procedure you already repeat.

Hooks

A script run by the tool, not an instruction entrusted to the model. Whatever must happen every time lives here.

• The available events: session start, message sent, before and after a tool call, end of turn.
• The wiring in settings.json, and the trap: hooks are frozen at startup — restart the session after changing them.
• What a hook can do: inject context, warn, and even block a tool call.
• Four production examples: inject the technical documentation at session start, inject the deployment runbook as soon as a production intent is detected, warn before an infrastructure file is edited, clear caches at the end of a turn.
• Writing, testing and debugging a hook.

Cross-repository configuration

• What is shared across all your repositories, and what must stay specific to one project.
• The settings layers — user, project, local: which one wins, and where a permission belongs.
• Sharing skills and hooks across repositories without duplicating them.
• Plugins: shipping a team a coherent set of skills, hooks and commands.
• Shared MCP servers: database, browser, issue tracker.
• A real case: two projects living on the same machine, with shared infrastructure and documentation that cross-references itself.

Security

• Permissions: what you allow once, what you allow always, what you never delegate.
• Secrets: what must enter neither a repository nor a session.
• Irreversible actions — migrations, deletions, production — and the rule of prior agreement.
• Prompt injection: anything coming from a web page, a ticket or a third-party file is data, never an instruction.
• Reviewing what is produced: what the tool cannot guarantee on your behalf.
• Hooks as guardrails, and the traceability of changes.