Exercise 1

MCP — The 3 primitives and their role

Objective: understand the 3 primitives of the Model Context Protocol and what they allow to expose to Claude.

🔧

Tools

Actions Claude can execute (API calls, functions)

📄

Resources

Data Claude can read (files, DB, feeds)

💬

Prompts

Reusable templates the user can invoke

1

Deepen the 3 primitives with concrete examples:

💬 Type in Claude Code
Explain the 3 MCP primitives with a concrete example for each, in the context of an MCP server that exposes a support ticket database: 1. Tools: what actions could this server expose? 2. Resources: what data could it expose? 3. Prompts: what templates could it provide? For each primitive, also give the difference from the other 2 (why not put everything in Tools?)
✅ Key distinctions Tools = actions (create ticket, close ticket). Resources = read data (ticket list, ticket detail). Prompts = predefined templates for recurring cases (escalation response template). Resources are read-only, Tools can modify.
2

Explore the MCP config in real conditions:

💬 Type in Claude Code
Show me the structure of the MCP configuration file for Claude Code (where it lives and what it looks like). Then show me the MCP servers currently configured in this project or globally.
✅ Expected result Claude reads .claude/settings.json or ~/.claude/settings.json. Structure: {"mcpServers": {"name": {"command": "...", "args": [...]}}}.
⚠️ Exam Trap

"MCP is a proprietary Anthropic protocol" → FALSE. MCP (Model Context Protocol) is an open protocol, not proprietary. It allows any external server to expose capabilities to Claude in a standardized way.

Exercise 2

CLAUDE.md — Persistent instructions per project

Objective: create an effective CLAUDE.md and understand its scope. CLAUDE.md is automatically injected into every conversation — it is the most important configuration file in Claude Code.

1

Ask Claude to inspect existing CLAUDE.md files and explain the hierarchy:

💬 Type in Claude Code
Search for all CLAUDE.md files in the current directory and its parents (up to ~/ if possible). For each: 1. Indicate its path and scope (global, project, subdirectory) 2. Summarize its content 3. Explain what priority it has relative to the others Then explain the loading order of CLAUDE.md files when Claude Code starts in a project.
✅ Expected hierarchy ~/.claude/CLAUDE.md (global, all sessions), project/CLAUDE.md (this project), project/src/CLAUDE.md (this subdirectory). All loaded and concatenated — no replacement.
2

Create a CLAUDE.md for the training project:

💬 Type in Claude Code
Create a CLAUDE.md file in /tmp/cert-training/ with these sections: - Project context (what TaskManager does) - Code conventions (Python, snake_case, docstrings) - Commit rules (conventional format: feat/fix/chore) - What Claude should NOT do (no debug prints, no TODOs) - Preferred tools (pytest for tests) Then explain why each section is useful in a professional CLAUDE.md.
💡 What makes an effective CLAUDE.md

Project context, code conventions, commit rules, what to avoid (anti-patterns), tools to use. Do NOT put in CLAUDE.md: code patterns derivable from the code itself, git history, temporary debug solutions.

Exercise 3

Skills — Create and invoke a reusable capability

Objective: create a Skill, understand its structure, and invoke it with /skill-name. Skills are packaged instructions invocable via a slash command.

1

Start by understanding the structure of a skill:

💬 Type in Claude Code
Show me the structure of a Skill file in Claude Code: 1. Where are they stored (which directory)? 2. What file format? 3. What are the required frontmatter fields? 4. How to invoke a skill (what syntax)? 5. What is the difference between a Skill and a CLAUDE.md?
✅ Expected answers Stored in .claude/agents/ (.md files). Frontmatter with name, description. Invoked with /skill-name. Difference: CLAUDE.md = always active, Skill = activated on demand via /.
2

Create a simple skill:

💬 Type in Claude Code
Create a "code-review" skill in /tmp/cert-training/.claude/agents/code-review.md that: - Has a clear 1-line description - Explains it analyzes Python code on these criteria: security, performance, maintainability, tests - Gives a structured output with a score /10 per criterion and 2 recommendations per category - Specifies it reads all .py files in the directory before starting Then invoke this skill with /code-review
✅ Expected result Claude creates the skill file, then when you type /code-review, it loads the skill instructions and runs a structured code review on the project. The slash command triggers the skill.
3

Distinguish a standard Skill from a subagent Skill:

💬 Type in Claude Code
In Claude Code Skills, what is the difference between a skill that runs in the main conversation and a skill that launches a subagent? Which frontmatter differentiates the two? Give an example of a case where you would prefer a subagent.
⚠️ Exam Trap

"A Skill replaces the CLAUDE.md instructions when invoked" → FALSE. CLAUDE.md instructions remain permanently active. The Skill is added to the existing context — it does not replace it.

Exercise 4

Synthesis — MCP vs CLAUDE.md vs Skills: which for what?

Objective: consolidate the 3 configuration mechanisms and know how to choose the right tool for the need.

1

Decision exercise:

💬 Type in Claude Code
For each of these needs, which mechanism to use (MCP server, CLAUDE.md, or Skill) and why? 1. Give Claude read access to a company Postgres database 2. Remind it every session that we use strict TypeScript and ESLint with specific rules 3. Create a /deploy command developers can invoke to follow the deployment process 4. Allow Claude to search Slack and post messages 5. Document the team's git branch naming conventions
✅ Expected answers 1→MCP (DB access = external tool/resource). 2→CLAUDE.md (always active, conventions). 3→Skill (on-demand invocable procedure). 4→MCP (Slack integration). 5→CLAUDE.md (convention always relevant).
💡 Decision rule

MCP = access to external systems (tools/resources Claude doesn't have natively). CLAUDE.md = context/rules always active in this project. Skills = packaged procedures invocable on demand via /.