Applications and Integration

Knowledge of

• The translation from business requirements to functional requirements (what the system must do) and infrastructure requirements (latency, throughput, data residency, availability, budget)
• The five extraction questions: latency sensitivity (interactive vs. tolerant), volume, accuracy/criticality (human review vs. automated action), data sensitivity (PII/regulated data), and cost ceiling
• How opposite requirement profiles -- a low-latency user-facing chat vs. an overnight bulk-analysis job -- call for opposite architectural choices (realtime vs. batch, larger vs. smaller model)
• That solution architecture is driven by the stated requirement, not by defaulting to the biggest model or the realtime API

Skills in

• Extracting latency, volume, accuracy/criticality, data-sensitivity, and cost signals from a business requirement before choosing a design
• Matching a requirement's profile to the opposite ends of the realtime-vs-batch and larger-vs-smaller-model spectrums as appropriate
• Recognizing when a requirement description ('cost is the primary concern, results aren't needed until morning') implies a specific architecture rather than a default one
• Avoiding the substitution of a familiar default (biggest model, synchronous API) for an architecture that actually fits the stated constraint

Knowledge of

• The standard SDLC phases -- requirements, design, implementation, testing/evaluation, deployment, operation, maintenance -- as the frame a Claude application still lives inside
• Why non-deterministic, model-version-dependent behavior means you can't unit-test a stochastic output with a single equality assertion
• Evaluation as a first-class SDLC phase built around success criteria rather than exact-match assertions
• Model-version pinning and regression testing as the mechanism for catching behavior changes before a new release reaches production
• Production monitoring of quality, latency, token cost, and error rates over time as an ongoing SDLC activity, not a one-time launch check

Skills in

• Mapping a Claude application's build process onto the standard SDLC phases
• Recognizing that stochastic output requires eval-style success criteria in place of single equality asserts
• Building in model-version pinning and regression testing as gates before adopting a new model release
• Designing production monitoring for quality, latency, token cost, and error rate rather than assuming launch-time testing suffices

Knowledge of

• The Messages API request shape: a messages list with alternating user/assistant roles, a top-level system parameter, required max_tokens, and optional tools/temperature/stream
• That the system prompt is a top-level parameter, not a message with role: "system"
• stop_reason values (end_turn, max_tokens, stop_sequence, tool_use) as the signal integration code branches on
• The usage field (input_tokens, output_tokens, plus cache read/creation tokens) as the basis for cost modeling
• Statelessness: the API retains no memory between calls, so the full conversation must be resent each request
• Streaming as server-sent events that lower perceived latency without changing total tokens or cost
• Tool use: a tools array of JSON-schema definitions, a tool_use content block with stop_reason tool_use, and a tool_result block sent back in a new user message
• Vision: content blocks that include images (base64 or URL) alongside text for multimodal input

Skills in

• Constructing a valid Messages API request with the required and optional parameters in their correct places
• Branching integration code on stop_reason rather than assuming a response always ends the same way
• Reading the usage field to model per-call cost
• Resending the full conversation on every call rather than assuming the API remembers prior turns
• Consuming streamed server-sent events (message_start, content_block_delta, message_stop) to assemble text incrementally
• Handling a tool_use response by executing the tool and returning a tool_result block in a new user message
• Including image content blocks alongside text for multimodal input

Knowledge of

• Extended thinking as a thinking budget that produces internal reasoning before the answer, with thinking tokens billed as output tokens -- a capability lever, not a free upgrade
• Prompt caching: marking a stable prefix with cache_control so subsequent requests reusing it pay a discount on cached tokens and start faster; writes cost slightly more than normal input, reads are much cheaper
• The Message Batches API: asynchronous processing of many requests within a 24-hour window at a substantial per-token discount, for latency-tolerant, high-volume, cost-sensitive workloads
• The realtime-vs-batch decision table: interactive/waiting-user work uses the (often streaming) Messages API; high-volume/24h-tolerant/cost-sensitive work uses the Message Batches API
• Claude's availability through Amazon Bedrock and Google Vertex AI alongside the direct API, with a largely consistent message format and differences limited to authentication, endpoint/region, and model-ID naming

Skills in

• Reserving extended thinking for tasks whose reasoning depth genuinely pays for the added output tokens and latency
• Marking a stable, reused prefix with cache_control instead of resending or truncating it on every call
• Recognizing a latency-tolerant, high-volume, cost-sensitive workload as a Message Batches API candidate rather than parallelized synchronous calls
• Choosing among the direct API, Amazon Bedrock, and Google Vertex AI based on cloud footprint, data residency, and procurement constraints

Knowledge of

• The Claude API as HTTPS + JSON: status codes, headers, request/response shape, idempotency, and pagination where relevant
• Asynchronous programming (async/await, concurrency) as the right tool for I/O-bound, slow LLM calls, with async clients offered by the SDKs
• Version control (Git) -- branching, PRs, history -- as the substrate for reviewing and rolling back prompt/model changes
• SDLC integration and code review that covers both code and prompts, treating prompts and model IDs as reviewable, versioned artifacts
• Refactoring, from tidying a function to restructuring a service, as a core competency for codebase-modernization use cases
• HTTP error semantics: 429 (rate limit) and 529/5xx (overloaded) as transient and requiring exponential backoff with jitter and retries; 400 as a malformed request; 401 as a bad key
• The SDKs surfacing typed exceptions for these error classes

Skills in

• Treating the Claude API as a standard REST/JSON service: reading status codes, headers, and response shape correctly
• Using async/await and concurrency to parallelize independent LLM calls and keep servers responsive
• Applying Git branching and PR review to changes that touch prompts and model IDs, not just code
• Implementing exponential backoff with jitter for 429/529/5xx responses
• Distinguishing a transient error (retry) from a client error (fix the payload or the key) before choosing a recovery strategy

Knowledge of

• The four primary interfaces -- API/SDKs, claude.ai, Claude Desktop, Claude Code -- and their primary use cases
• The distinct instruction mechanism each interface uses: system param + messages/tools/params for the API; chat plus Project instructions/knowledge for claude.ai; chat plus connected MCP servers for Claude Desktop; CLAUDE.md + settings.json + slash commands for Claude Code
• That instructions don't transfer verbatim across surfaces -- a CLAUDE.md shapes Claude Code but does not configure a raw Messages API call

Skills in

• Selecting the correct instruction mechanism for a given interface instead of assuming one mechanism generalizes across all of them
• Recognizing when a described design (e.g., 'set up a CLAUDE.md for the chatbot') has matched the wrong mechanism to the wrong surface
• Reasoning about how the same underlying model can be reached through fundamentally different instruction-authoring surfaces

Knowledge of

• Content boundaries: keeping trusted instructions separate from untrusted data (user input, retrieved documents, tool output), delimited clearly (e.g., XML-style tags) so injected text can't be read as instructions
• Schema design: defining a JSON schema and using structured output/tool-forcing for machine-readable output, designed strict but not brittle
• Session hygiene: because the API is stateless and context is finite, deliberately deciding what carries forward -- summarizing/compacting long threads, starting fresh sessions when context is polluted, not letting stale tool output accumulate
• Plugin management: explicitly tracking which MCP servers/plugins are enabled, what permissions they hold, and their versions

Skills in

• Delimiting untrusted input (user text, retrieved documents, tool output) so it cannot be interpreted as an instruction
• Designing a JSON schema and using structured output/tool-forcing for machine-readable responses that are strict but not brittle
• Deciding deliberately what context carries forward across turns rather than letting a session accumulate unbounded history
• Starting a fresh session when context is polluted instead of continuing to build on a degraded thread
• Tracking enabled plugins/MCP servers, their permissions, and their versions as an explicit inventory

Knowledge of

• CLAUDE.md as project/repo memory and instructions for Claude Code, checked into version control
• settings.json as Claude Code's settings surface: permissions, hooks, tool allow/deny lists, and environment
• Model-version pinning: using an explicit model ID rather than a floating alias so behavior stays reproducible, upgrading deliberately after re-running evals
• Prompt versioning: treating prompts as artifacts with version history so changes can be diffed, reviewed, and rolled back, and a quality change correlated to a specific prompt change
• Plugin dependencies: tracking which plugins/MCP servers a project depends on and at what versions, like any other dependency

Skills in

• Checking CLAUDE.md into version control as reviewable project memory rather than treating it as a local, untracked file
• Configuring settings.json permissions, hooks, and tool allow/deny lists deliberately rather than accepting defaults
• Pinning an explicit model ID in production and gating any upgrade behind re-run evaluations
• Versioning prompts so a quality regression can be traced to a specific prompt change and rolled back
• Tracking plugin/MCP-server dependencies and their versions as a first-class part of the project's dependency graph