Claude Code configuration and continuous integration

Episode Four moves from A P I orchestration into Claude Code as a governed engineering environment. By the end, you should be able to distinguish instructions from enforcement, place guidance in the right configuration layer, package reusable work as Skills, and design safe hooks and continuous-integration workflows. Now apply the same separation of guidance and enforcement to software development. The exam blueprint expects you to understand project instructions, rules, Skills, commands, plan mode, tools, sessions, hooks, and programmatic execution. Let us begin with CLAUDE dot M D. A CLAUDE dot M D file supplies persistent project or user guidance that Claude loads as context. It can explain architecture, build commands, testing conventions, repository boundaries, naming rules, and common hazards.

Text description

• Guidance: CLAUDE.md and path-specific rules describe architecture, conventions, tests, and hazards.
• Enforcement: Hooks, permissions, branch protection, tests, and backend controls impose mandatory policy.

Should it contain the entire engineering handbook? No. It should be concise, task-relevant, and linked or imported in a way that keeps the loaded context useful. A bloated instruction file competes with the code and task for attention. The hierarchy lets organisations provide broader guidance and repositories provide more specific guidance. Path-specific rules can apply instructions only when work touches matching areas of the codebase. For example, a payments directory can require extra tests and prohibit direct database writes. Does that prohibition become a hard security control because it appears in CLAUDE dot M D? No. Claude treats it as context, so hooks, permissions, branch protection, tests, and backend controls must enforce non-negotiable rules.

Current Claude Code documentation makes that distinction explicit. Use instructions to shape behaviour, settings to configure the client, and hooks or external systems to enforce events and policy. Claude Code also maintains auto memory in supported configurations. Memory can preserve useful recurring facts, but it should not become an unreviewed policy store or a dumping ground. Important project truth belongs in version-controlled documentation and configuration. Now distinguish Skills from simple commands. A Skill packages reusable instructions, knowledge, supporting files, and a workflow that Claude can load when relevant or invoke directly. A custom command expands a named interaction from the command menu or command directory.

Text description

• Skill workflow: Defines a narrow purpose, trigger, inputs, outputs, supporting knowledge, and review steps.
• Allowed tools: Permits only necessary actions, such as inspecting changed files and running approved tests.
• Excluded capabilities: Deployment and production-database access remain outside the review workflow.

Current documentation treats Skills as the preferred successor for many reusable command-style workflows, but the July 2026 exam guide expects familiarity with both. A good Skill has a narrow purpose, clear trigger, required inputs, expected outputs, and only the tools it needs. What might Harbour Resolution place in a Skill? A secure pull-request review workflow that loads the review rubric, checks changed files, runs approved tests, and produces a fixed finding schema. The Skill should not quietly inherit deployment or production-database capability. Arguments and hints can make an explicitly invoked workflow easier to use. Tool allowlists constrain what the workflow may call. Forking or subagent execution can isolate a specialised review from the main session where supported.

Text description

• Plan mode: Use for ambiguous, cross-cutting, high-impact, or unfamiliar work where reviewing the approach reduces risk.
• Direct execution: Use for bounded changes with clear acceptance criteria and a low blast radius.

Plan mode is another recurring exam topic. In plan mode, Claude explores and proposes an approach without immediately making the full set of changes. Use it for ambiguous, cross-cutting, high-impact, or unfamiliar work where reviewing the intended approach reduces rework and risk. Direct execution suits bounded changes with clear acceptance criteria and low blast radius. Is plan mode automatically safer in every circumstance? No. It improves reviewability, but permissions and controls still govern what tools can execute. Unnecessary planning can slow a trivial task without improving its result. The stronger question is whether the cost of a wrong implementation justifies an explicit plan review. Claude Code's built-in capabilities include file reading, file writing, targeted editing, shell execution, text search, and file matching.

Give each workflow the minimum sufficient set. A codebase orientation workflow needs read, grep, and glob, but probably not write or unrestricted shell. A test-fixing workflow may need edit and a constrained test command. A deployment workflow should usually remain outside an unconstrained coding session. How should engineers prompt Claude Code for reliable changes? State the goal, constraints, relevant locations, acceptance tests, and what evidence should be returned. Then let Claude inspect before editing, request a plan when the change is broad, and iterate against real test output. Examples of accepted patterns are often more useful than abstract style adjectives. An effective workflow might ask Claude to reproduce the issue, identify the cause, add a failing test, implement the smallest fix, rerun targeted tests, and summarise the diff.

Do not ask it to refactor everything while you are there unless that scope is genuinely required. Sessions allow work to continue across turns and can be resumed later. Forking a session is useful when comparing approaches or separating experimental work from the accepted branch. Parallel coding work should use isolated branches or worktrees so agents do not overwrite one another. Now move from interactive use to continuous integration. Claude Code can run programmatically with print mode, commonly invoked with the short p flag. A continuous-integration job should supply a bounded prompt, fixed working directory, controlled settings, explicit permissions, and machine-readable output. Machine-readable output in JavaScript Object Notation, or J S O N, makes downstream parsing more reliable than scraping prose, and a J S O N schema can constrain the structure further.

Text description

• Candidate JSON finding: Claude produces structured review output, optionally constrained by a JSON schema.
• Validate schema: Confirm that required fields and the expected structure are present.
• Validate meaning: Verify the cited file and line, allowed severity, explanation, and relevance to the submitted change.
• Publish or reject: Release supported findings and reject false, irrelevant, or malformed results.

The pipeline should validate both schema and semantics before publishing findings. What does semantic validation mean for a code review finding? Check that the cited file and line exist, the severity is allowed, the explanation is present, and the finding applies to the submitted change. Valid J S O N can still contain a false or irrelevant finding. To reduce false positives, define the review rubric precisely and include examples of reportable and non-reportable issues. Give Claude access to the diff and enough surrounding code, not the whole repository by default. Require concrete evidence and permit a clean result with no findings. An independent second pass can review candidate findings rather than letting the same reasoning path approve itself.

Text description

• Before tool use: A pre-tool hook can block dangerous commands or require metadata.
• After an edit: A post-edit hook can run formatting or a targeted check.
• Before completion: A completion hook can verify that expected tests ran before the workflow is treated as done.

Should Claude's C I review be the sole gate for merging? Not unless the organisation has deliberately validated that use and accepts its failure modes, because deterministic tests and required human review may remain necessary. High-severity automated findings can route to a human rather than silently block all work. Hooks can enforce or automate lifecycle behaviour around Claude Code. A pre-tool hook can block dangerous commands or require metadata. A post-edit hook can run formatting or a targeted check. A completion hook can ensure expected tests ran before a workflow is treated as done. Hooks should produce clear logs and fail in a defined manner, because invisible hook failures create confusing behaviour.

Episode Four is complete when you can point to which controls guide Claude Code and which controls actually enforce the engineering boundary. For source navigation, use the Claude Code references for project memory, settings, Skills, commands, hooks, headless execution, continuous integration, permissions, and security. In the next episode we will make model outputs precise enough for machines without pretending that syntax guarantees truth.