Français
Applied AI · Advanced 🔴 · Session 6
📝 Teacher's Guide
← Return to program 📄 Source .md

Teacher Guide — Session 6: Claude Code & CI/CD

Program : Applied AI — Advanced Level (certification preparation Claude Certified Architect ) Instructor: Yann Isola Duration : 2 hours 30 minutes (150 minutes) Modules covered: Chapters 5 and 13 of the reference guide — Claude Code, integrated tools, continuous integration

1. Session overview

Educational objectives

At the end of this session, each participant should be able to:

  1. Set Claude Code : a coding assistant agentic (agentic coding assistant) which runs in the terminal, capable of reading, modifying and executing code autonomously within a controlled permissions scope.
  2. Structure a file CLAUDE.md effective : project overview, conventions, common commands, known gotchas — and explain why this file is lever n°1 of the quality of the outputs.
  3. Configure directory .claude/ : settings.json (tools authorized via allowedTools ), custom orders (.claude/commands/), hooks.
  4. Master the permissions model : allow/deny by tool, auto-accept patterns, principle of least privilege applied to a coding agent.
  5. Design a hook system : lifecycle events (PreToolCall , PostToolCall , Notification , Stop ) for custom automation — auditing, guardrails, notifications.
  6. Execute Claude Code in headless mode (without interface, non-interactive) with --print / -p to integrate it into a CI/CD pipeline (Continuous Integration / Continuous Deployment).
  7. Design three CI/CD integration patterns : automatic PR review (Pull Request, merge request), test generation, documentation update.
  8. Map built-in tools (Chapter 13): Read , Write , Edit , MultiEdit , Bash , Glob , Grep , LS , TodoRead , TodoWrite , WebFetch , mcp__* — and associate each tool with its level of risk and its need for permission.
  9. Manage costs : order /cost , prompt caching in long sessions, /compact to compress the context.

Prerequisites

Certification positioning

This session covers an area heavily weighted in the exam Claude Certified Architect : the configuration of agentic environments and their industrialization. Typical exam questions cover:

Insist on participants: the exam tests architectural judgment, not memorization of flags . Each part of the course ends with a “certification standard question” — use them.

Necessary equipment

Central message of the session

“Claude Code is not a chatbot that talks about code: it’s a agent which acts on your deposit, within a perimeter that YOU define. The file CLAUDE.md is its contextual brain, settings.json is its cage, the hooks are your surveillance cameras, and headless mode makes it an employee of your pipeline. »

Repeat this metaphor in four parts (brain / cage / cameras / employee) — it structures the entire session.

Narrative thread

The entire session is based on a unique common thread project : facturation-api , a mock billing API in Python with pytests. Each concept is illustrated on this same project:

Repetition of the same context anchors concepts and prepares for the certification scenario questions.

2. Rolled out minute by minute

Hourly Duration Sequence Support
0:00 – 0:05 5 mins Welcome, reminder Session 5, objectives, certification issue Slides 1–3
0:05 – 0:25 20 mins Part A — Claude Code: Anatomy of a Terminal Agent Slides 4–8 + live demo
0:25 – 0:45 20 mins Part B — CLAUDE.md : the contextual brain Slides 9–12 + web builder
0:45 – 1:05 20 mins Exercise 1: Write a CLAUDE.md Worksheet + web builder
1:05 – 1:10 5 mins ☕ Short break —
1:10 – 1:30 20 mins Part C — Permissions & integrated tools: the cage Slides 13–18 + web configurator
1:30 – 1:45 15 mins Part D — Hooks: surveillance cameras Slides 19–22
1:45 – 2:00 15 mins Exercise 3 (getting started): Design a hook system Worksheet
2:00 – 2:15 15 mins Part E — Headless mode & CI/CD: the pipeline employee Slides 23–27 + web pipeline designer
2:15 – 2:25 10 mins Exercise 2 (scoping): CI/CD pipeline with Claude Code — launch, finishing at home Worksheet
2:25 – 2:30 5 mins Quick quiz + Exit Tickets + announcement Session 7 Slides 28–30

Flexibility rating: Exercise 2 (complete CI/CD) is the longest — it is designed to be framed in session and finished at home . If you fall behind, compress Part D to 10 minutes (show only PreToolCall And Stop ), but do not sacrifice Never Part C (permissions): this is the heart of the security model and the most tricky subject under examination.

3. Detailed teaching notes by sequence

0:00 – 0:05 | Reception and framing

What to say:

“So far, you have designed agents In applications. Today, we turn the tables: the agent is your colleague at the terminal. It reads your code, modifies it, runs your tests. And at the end of the session, it will work on its own in your CI/CD pipeline, at night, while you sleep. The question of the session is not “is it possible?” — it’s “how to stay in control?”. »

Announce the certification issue: this chapter weighs heavily on the exam. Distribute the plan.

0:05 – 0:25 | Part A — Claude Code: Anatomy of a Terminal Agent

Key concepts:

  1. Definition. Claude Code is a command-line agentic coding wizard. “Agentic” means: he doesn’t just respond, he loop — reads files, suggests changes, executes commands, observes results, corrects. This is the agentic loop of Session 3, embodied in the terminal.

  2. Starting a project. The order /init inspects the warehouse and generates a first CLAUDE.md automatically. Insist: it’s a draft — a good architect always reworks it (transition to Part B).

  3. Natural language interaction. We do not type rigid commands: “fixes the VAT calculation bug in invoice.py and add a test" is a valid statement. Claude Code schedules, opens the correct files (via Glob /Grep ), edit (via Edit /MultiEdit ), tests (via Bash ).

  4. Multi-file editions. Unlike classic autocompletion, Claude Code reasons at the scale of the repository: a function renaming can affect 12 files in a single task.

  5. Built-in slash commands:

    • /init — generates the CLAUDE.md initial ;
    • /compact — compresses conversation history to free up context (automatic summary);
    • /cost — displays the token consumption and the cost of the session;
    • /review — launches a code review;
    • orders personalized In .claude/commands/*.md — a Markdown file = a command (ex. .claude/commands/deploy-check.md becomes /deploy-check ).

Live demo (8 min): on the project facturation-api , launch claude , Then /init , show it CLAUDE.md generated. Then ask in natural language: "List the test files and tell me what is not covered." Show the permission requests that appear — it’s the perfect teaser for Part C.

Educational trap: some participants will think that Claude Code "sees" the entire repository all the time. False: he explore on demand (via Glob , Grep , Read ). The context is built incrementally — hence the importance of CLAUDE.md which is systematically loaded.

Standard certification question: “A developer notices that Claude Code ignores team naming conventions. What is the first corrective action? » → Document conventions in CLAUDE.md (not: repeat the instruction at each prompt, nor: change model).

0:25 – 0:45 | Part B — CLAUDE.md : the contextual brain

Key concepts:

  1. What it is. A Markdown file at the root of the project, loaded automatically at the start of each session . It is the project equivalent of the system message: permanent instructions, versioned with the code, shared by the entire team.

  2. Canonical structure (to be noted):

    • Project overview — what, for whom, technical stack. 3 to 5 lines.
    • Agreements — code style, naming, folder structure, comment language.
    • Common commands — how to run the tests, the linter, the build, the local server. Accurate and copyable.
    • Known traps (gotchas) — “module X has a misleading API”, “never touch the folder migrations/ by hand”, “integration tests require Docker”.

  3. Why it works. Each instruction in CLAUDE.md saves dozens of downstream corrections. Analogy: this is the onboarding document of a new developer — except that this developer rereads it at each session , completely, without ever forgetting it.

  4. Anti-patterns to denounce:

    • THE CLAUDE.md of 800 lines: it consumes context in each session and dilutes critical instructions. Target : less than 150 lines , dense.
    • Generalities (“write clean code”): zero value. Each line must be project specific .
    • The outdated file: commands that no longer work = the agent loses confidence... no, correction: YOU waste time because the agent executes broken commands. Treat CLAUDE.md like code: review, update, accountability.

  5. Hierarchy. There may be a CLAUDE.md global (user level, ~/.claude/CLAUDE.md ) and CLAUDE.md by subfolder for monorepos. The more specific complements the more general.

Activity (5 min): project it builder of CLAUDE.md of the web page. Fill it live with the room for facturation-api . Generate the file, critique it together: what’s missing? What is too vague?

Standard certification question: “Which section of CLAUDE.md has the most impact on reducing order fulfillment errors? » → Exact common orders (the agent does not have to guess npm test vs. pnpm test vs. make test ).

0:45 – 1:05 | Exercise 1 — Write a CLAUDE.md

See worksheet. Participants write a CLAUDE.md complete for a project described in the statement (or their own project if they have one). The web builder can be used as a scaffold, but require a manual densification pass.

Correction criteria (announce them):

Traffic : identify the “generic” files (which could describe any project) and challenge: “if I give this file to another pair, will they know that it is not their project? If not, everything has to be rewritten. »

1:10 – 1:30 | Part C — Permissions & integrated tools: the cage

This is the most important part of the session. Slow down.

Key concepts:

  1. The catalog of integrated tools (Chapter 13). Have the table constructed with the room, by increasing risk level:

    Tool Function Risk Typical permission
    Read Read a file Low (possible information leak) Often self-accepted
    LS List a directory Weak Self-accepted
    Glob Find files by pattern Weak Self-accepted
    Grep Search in contents Weak Self-accepted
    TodoRead / TodoWrite Manage internal task list Negligible Self-accepted
    WebFetch Retrieve a web page Medium (exfiltration, unreliable content) Recommended validation
    Write Create/overwrite a file Pupil Validation
    Edit / MultiEdit Edit one/multiple files Pupil Validation or targeted reasons
    Bash Execute a shell command Critical Systematic validation or fine whitelist
    mcp__* External MCP tools (Model Context Protocol servers) Variable — server dependent On a case by case basis

  2. The allow/deny model. In .claude/settings.json , the key allowedTools defines what is allowed without confirmation. The granularity goes down to reason for order : Bash(npm test) exactly authorizes npm test , Bash(git diff:*) allows variations of git diff . Anything not explicitly allowed triggers an interactive confirmation request — or a refusal in headless mode (crucial point for Part E).

  3. Canonical example to project:

{
  "permissions": {
    "allow": [
      "Read", "Glob", "Grep", "LS",
      "Bash(npm test:*)",
      "Bash(git diff:*)",
      "Bash(git log:*)",
      "Edit"
    ],
    "deny": [
      "Bash(rm:*)",
      "Bash(git push:*)",
      "WebFetch"
    ]
  }
}

⚠ The exact syntax of the settings file changes with versions of Claude Code — check the official documentation before the session and adapt the slide if necessary. There logic (explicit allow, priority deny, patterns by prefix) is stable and it is this which is tested in certification.

  1. Architect principle: THE deny always prevails over allow . We think in three circles: free reading (exploring costs nothing), monitored writing (validated or targeted modifications), locked execution (the shell is a total attack surface — Bash unconstrained is equivalent to giving SSH access).

  2. What Claude Code CANNOT do: exit the working directory without permission, execute anything without going through its declared tools, hide an action (any tool call is visible and logable via hooks). But remember attack vector #1:prompt injection via the content read (a malicious code comment, a page WebFetch trapped may contain instructions). Permissions are the defense: even manipulated, the agent cannot execute what is refused.

Activity (5 min): web page permissions configurator. Scenario: “Claude Code must do code review in CI, read-only + comments”. The room chooses the tools, the page generates the settings.json . Expected response: Read/Glob/Grep/LS only, everything else in deny.

Standard certification question: “A CI pipeline uses Claude headless code to generate tests. What minimum set of tools should be allowed? » → Read, Glob, Grep, LS (exploration), Write or Edit (create test files), Bash(pytest:*) or equivalent (check that the tests pass). Nothing else. Every superfluous tool is a wasted point.

1:30 – 1:45 | Part D — Hooks: surveillance cameras

Key concepts:

  1. Definition. A hook is a script to you that Claude Code executes automatically at specific points in the lifecycle. Unlike the prompt (which the model can misinterpret), a hook is determinist : it always executes, exactly as written.

  2. The four events:

    • PreToolCall — Before each tool call. Can to block the appeal (safeguard). Ex.: refuse everything Bash containing DROP TABLE .
    • PostToolCall — After each tool call. Do not block, but observe and react. Ex.: launch the code formatter after each Edit .
    • Notification — when Claude Code needs human attention (permission request, question). Ex.: send a Slack message.
    • Stop — when the agent completes its response/task. E.g.: play a sound, trigger the rest of the pipeline, archive the session log.

  3. Architect use cases (the three families):

    • Guardrails (PreToolCall): security policies inviolable , complementary to permissions — permissions say which tools, hooks say what uses of these tools.
    • Quality automation (PostToolCall): Auto lint/format, check that modified files compile.
    • Observability (all): complete audit log of each agent action — common requirement in a regulated environment. Link to the context of the participants: in a bank, this log is what the auditor will ask for.

  4. Blocking semantics: a hook PreToolCall which exits with a failure code (and/or message) prevents the call and sends the explanation back to the model, which can adjust its strategy. It’s a dialogue, not just a wall.

To say:

“Remember the division of labor: CLAUDE.md = what the agent should do (persuasion). Permissions = what can do (ability). Hooks = what happens when he acts (control and reaction). A certified architect knows how to choose the right level: you don't put in the prompt what should be a hook, and you don't put in a hook what should be a permission. »

Standard certification question: “The security team requires that no order containing curl to an external domain is never executed, even if the user approves it. Prompt, permission or hook? » → Hook PreToolCall (inspection of order content + unconditional blocking). A permission deny Bash(curl:*) is also defensible — excellent opportunity for debate: permission blocks All curl, the hook allows fine logic (internal curl OK, external no).

1:45 – 2:00 | Exercise 3 (getting started) — Design a hook system

See worksheet. Work on paper/publisher: design the hooks for a regulated environment. No need to perform — the exercise assesses the design : choice of event, filtering logic, action.

Traffic : the classic mistake is to put everything PreToolCall . Push to justify: “why this control Before rather than After ? What does it cost in latency? »

2:00 – 2:15 | Part E — Headless mode & CI/CD: the pipeline employee

Key concepts:

  1. Headless mode. claude -p "instruction" (Or --print ) executes the task without interactive interface : Claude Code receives instruction, acts, prints result, exits. Exit code usable by the pipeline.

  2. Critical consequence: headless, no one clicks “allow”. All permissions must be pre-granted in settings.json (or via command line permission flags). An unauthorized tool = action refused = potentially incomplete task. Hence the golden rule: calibrate headless permissions to what is strictly necessary for the task, and nothing more — it is an agent without human supervision.

  3. The three integration patterns to know for certification:

    a) Automatic PR review. Trigger: opening/updating a PR. The job checks out the code, launches claude -p "Révise ce diff : bugs, sécurité, conventions du CLAUDE.md. Formate en Markdown." with permissions read only + Bash(git diff:*). The output is posted as a PR comment via the forge API (GitHub/GitLab). Architect's point: the AI ​​review complements the human review, it does not replace it — configure it as non-blocking at the start.

    b) Test generation. Trigger: coverage drop or manual request. Permissions: read + Write (limited to the file tests/ if possible via hook!) + Bash(pytest:*). The job commits the tests to a branch and opens a PR — never direct push on hand . Here is a perfect permission + hook marriage: Write allowed hook PreToolCall which checks that the path begins with tests/.

    c) Documentation update. Trigger: merge on main. Claude Code compares code and doc, updates outdated sections, opens a doc PR. Permissions: read + Edit on docs/.

  4. CI cost management:

    • Each run consumes tokens: follow /cost in interactive, and in CI, cap (turn limit, job timeout).
    • THE prompt caching (caching of prompt prefixes) greatly reduces the cost of long sessions: the CLAUDE.md and stable context are cached, only new content is billed at full price. ⚠ Prices and cache reduction rates change - give the order of magnitude (“the cached token costs a fraction of the normal token”) and refer to the current price list.
    • /compact in a long interactive session: summarizes the history to avoid cluttering the context (and the degradation of quality that goes with it).

  5. Anti-pattern to nail to the wall: --dangerously-skip-permissions (or any equivalent “allow all”) in a pipeline connected to production secrets. If you have to use it, it's in a disposable container, no outgoing network, no secrets. An architect who puts “authorize everything” in a CI runner with AWS credentials has failed his certification And its security audit.

Activity (5 min): web page pipeline designer. Build the PR flow live → review Claude → tests → deployment, configuring each step (permissions, blocking/non-blocking).

Standard certification question: “In headless mode, Claude Code stops without finishing because a tool is refused. Most likely cause? » → Permission missing in settings.json : in headless mode there is no interactive confirmation possible.

2:15 – 2:25 | Exercise 2 (scoping) — CI/CD pipeline

Start exercise 2: reading the statement together, choosing the pattern in pairs, writing the workflow skeleton. The finishing (complete YAML workflow + settings.json + hook) is done at home. Announce that the productions will be reread at the start of Session 7.

2:25 – 2:30 | Fence

4. Frequently asked questions from participants (and answers)

“Can Claude Code destroy my repository? » With default permissions: no — write and execute actions require confirmation, and Git protects you (everything is reversible before push). With “allow all” and without Git: yes, like any script to which you give the keys. The architect's answer: it's not a question of confidence in the model, it's a question of the scope of permissions.

“Why not put everything in CLAUDE.md rather than in hooks? » Because CLAUDE.md is from the persuasion : The model follows the instructions with a very high probability, but not a guarantee. A hook is code : it runs 100%. Security policies go into hooks/permissions; preferences and conventions go in CLAUDE.md .

“Is headless mode the same binary? » Yes — same tool, flag -p /--print . What changes: no interactivity, therefore no confirmations, therefore mandatory pre-configuration.

“What are AI PR reviews worth?” » Excellent for: obvious bugs, convention inconsistencies, oversights (error handling, edge cases), documentation errors. Limited for: business relevance, choice of background architecture. Hence the recommendation: non-blocking, in addition to humans.

“And the MCP tools (mcp__*) ? » Each connected MCP server exposes its tools under the prefix mcp__nomserveur__nomoutil . They fit into the same allow/deny model. Architect's rule: audit each MCP server as a security dependency (who wrote it? what does it really do?) before authorizing it — that was the focus of Session 5.

5. Scale and summary corrections

6. To go further (to be mentioned at the end)