How do you make a Claude conversation remember context and behave consistently? In this module, you will build a reusable conversation runner that stores history, applies a stable system prompt, and is checked against a small graded evaluation set. You will use the Messages API with user and assistant roles, helper functions and a chat loop, system prompts, temperature and model selection, prefill and stop sequences, clear task prompts with examples, and code-based, model-based, and human grading. You will also learn which business rules belong in application code instead of a prompt. The module is for developers who can read basic Python and call an API; no previous Claude experience and no other module is required, because prepared fixtures and starter files are supplied. You will practice changing one prompt instruction at a time and re-running the same test cases to confirm that an improvement does not silently break another case. You will leave with a working conversation runner, a documented system prompt, a prompt-evaluation dataset with expected outputs, and a grading approach you can reuse to compare prompt versions in your own applications with confidence.

How do you turn a free-form customer message into data your application can trust? In this module, you will build a return-request extractor that produces schema-shaped output and passes a validator before anything downstream uses it. You will use tool definitions, input schemas, tool_choice modes, JSON Schema fields such as required, nullable, enum, and other-plus-detail, bounded retries, and review routing for ambiguous cases. You will separate syntactic validity from business validity by checking order ownership, return eligibility, and normalization in application code, and you will see why a model-reported confidence value is not a calibrated probability. The module is intended for developers who can read basic Python and JSON; no earlier Claude tool-use experience and no other module is required, and prepared support fixtures cover malformed, schema-valid but wrong, and correct examples. You will take away a return-request schema, a working extraction prompt and tool call, an application-side validator, and clear rules for when a case advances, is corrected once, or goes to a person. You can reuse the same pattern for other extraction tasks in your own projects, with a clear way to check that each change keeps the extractor reliable.

How do you keep a Claude integration fast, correct for every customer, and easy to diagnose when it breaks? In this module, you will extend a text-only client into one that handles typed content blocks and images, runs independent calls asynchronously, streams output, isolates customer sessions, and recovers from failures by tracing them. You will use the SDK async client, server-sent events, a WebSocket relay example, provider adapters for Anthropic and third-party routes, session keys, correlation identifiers, redacted logs, and an error classification of invalid input, configuration, rate limit, transient, and wrong-output failures. The module suits developers with basic Python and an understanding of requests and responses; no earlier Claude experience and no other module is required, since prepared traces, fixtures, and scaffolds are supplied. You will practice finding the earliest incorrect step before changing a prompt or retrying, because blind retries can duplicate side effects. You will take away a content-aware client design, a fixed shared-history bug, a streaming trace that rejects truncated output, and a justified recovery choice for two sample failures that you can explain to a teammate or reviewer.

How do you let Claude use backend operations without handing it the keys to your customers' data? In this module, you will expose lookup, customer, refund, and escalation tools behind enforced boundaries, so that unauthorized or duplicated actions are stopped in code. You will use authentication versus authorization checks, ownership and role validation, least privilege, injection and data-leakage defenses, PII redaction, tool dispatch with matched tool_use and tool_result identifiers, structured success and error responses, approval gates, and idempotency keys for refunds. The module is designed for backend and AI application developers who can read basic Python; no earlier Claude tool experience and no other module is required, and a mock backend with synthetic data is provided so nothing touches real customers. You will practice treating model output, customer claims, and order notes as untrusted input, and confirming that a requested operation has not happened until its executor reports it. You will take away an authorization policy function, a tool dispatcher that returns correctly matched results, structured errors that separate missing data, invalid input, denial, and outages, and a refund path that safely deduplicates a retried request.

How do you share backend capabilities with Claude applications through the Model Context Protocol? In this module, you will build a minimal MCP server that exposes a tool, a resource, and a prompt template, and connect a client application that routes a Claude tool request through it. You will use the Python MCP SDK, stdio and Streamable HTTP transports, capability discovery, schema mapping, and error handling that keeps diagnostic logs apart from the protocol stream. You will also decide when a built-in tool, a custom tool, a Skill, or an MCP server is the right extension mechanism, using capability fit, execution location, reuse, ownership, and permissions. The module is for developers who can read basic Python and JSON; no earlier MCP or Claude experience and no other module is required, because a prepared scaffold and synthetic order data are supplied and no infrastructure orchestration is involved. You will practice distinguishing MCP connections from Claude API streaming and recognizing that the client, not the model, decides which context is supplied. You will take away a running MCP server, a connected sample client, and a completed model-to-MCP-to-backend round trip.

When should Claude decide the next step, and how do you keep that freedom safely bounded? In this module, you will build a support agent with a bounded loop, reliable case facts, deterministic hooks, and a clear stopping and escalation path. You will use stop_reason-driven control flow, a harness for tools, state, and permissions, context pruning and summaries, the Claude Agent SDK, pre-tool hooks, supervisor and subagent delegation, a comparison of Strands, LangGraph, and PydanticAI, and self-hosted versus Anthropic-hosted execution. The module is intended for developers who can read basic Python and are comfortable with tool calls; no earlier agent experience and no other module is required, since prepared scaffolds, dispatchers, and fixtures are supplied. You will practice choosing a fixed workflow when rules are known and an agent when investigation is needed, and you will see that a hook is one layer rather than the whole security boundary. You will take away a decision rubric for workflow versus agent, a working loop with a forced step-limit exit, a case-facts check that survives context reduction, a hook that blocks an over-limit refund, and an integrated multi-tool support agent that escalates to a human.

How do you choose a Claude model and configuration using evidence instead of habit? In this module, you will compare models on the same support cases, set a token and cost budget, reuse a stable prompt prefix, and select between realtime and batch processing. You will use Haiku, Sonnet, and Opus benchmarks, thinking, effort, and fast-mode settings checked against a dated compatibility card, usage fields, cost-per-resolved-case worksheets, prompt caching with cache checkpoints, and Message Batches with per-item results. The module is for developers who can read basic Python and run an API request; no earlier Claude optimization experience and no other module is required, and prepared comparison tables, usage data, and illustrative rates are supplied, so you do not memorize prices. You will practice measuring quality, latency, and spend together, because a cheaper request that fails repeatedly can cost more overall, and you will confirm that caching is neither memory nor permission to share customer context. You will take away a justified model choice for two workloads, a budget estimate, a cache-friendly prompt layout, and a batch submission with a matched result set that includes a failed item.

How do you make Claude Code behave the same way for everyone working in a repository? In this module, you will configure a sample repository with project instructions, a reusable Skill, a focused review Agent, controlled sessions, and a pinned plugin. You will use the CLAUDE.md hierarchy, scoped Rules, settings.json, custom commands and Skill invocation, Agent Memory, resumed and headless sessions, permission and output modes, and plugin manifests with dependency and version checks. The module is for developers who write code in a Git repository and can use a terminal; no earlier Claude Code experience and no other module is required, since a prepared sample checkout is provided and all data is synthetic. You will practice verifying which configuration is actually active, keeping secrets and customer data out of persistent agent memory, and separating coding helpers from any deployed application. You will take away a configured repository with a project instruction and rule, a minimal SKILL.md applied to a sample diff, a refund-code review Agent with an appropriate memory entry, a headless review run, and a plugin whose missing dependency you diagnosed and restored to a pinned version.

How do you ship a Claude application change that you can review, reproduce, and roll back? In this module, you will review a refactor, version prompts, schemas, and models as a release record, run an operations feedback loop, and reason through original exam-style scenarios. You will use branches, small commits and pull-request diffs, focused regression tests, staged migrations, model version pinning, release manifests, re-run evaluation sets, redacted monitoring of success, latency, spend, tool failures, and access events, and an SDLC feedback cycle from requirements through retirement. The module is intended for developers and technical leads who keep hands-on responsibility and can read basic Python; no earlier Claude release experience and no other module is required, since prepared diffs, manifests, regression reports, and incident artifacts are supplied. You will practice identifying the requirement, the responsible component, and the trust boundary before choosing a feature. You will take away a reviewed change with a staged refactor plan, a release decision that accepts or rejects a model upgrade with a rollback path, a regression case created from an incident, and a repeatable decision process for CCDV-F implementation scenarios.