Prompt and Context Engineering

Knowledge of

• Clear, direct, specific instructions as the standard for steering a single call; ambiguity is the top cause of poor output
• Positive instructions ('respond only in JSON matching this schema') as more reliable than long 'don't' lists
• The system/user placement rule: durable role, rules, and constraints in the system prompt; the specific request and per-request data in the user message
• Output constraints that specify the exact shape, length, and structure of the desired response

Skills in

• Stating the task, constraints, and desired output explicitly instead of relying on the model to infer intent
• Writing positively framed instructions instead of long negative constraint lists
• Placing durable rules and role definitions in the system prompt and per-request specifics in the user message
• Specifying exact output shape, length, and structure rather than leaving format to inference

Knowledge of

• Few-shot examples (zero-/one-/multi-shot) as often more effective than a paragraph of description for locking in format and style
• Placement effects: long documents go before the instruction, and the key instruction goes near the end, right before the response
• XML-style tags and headings as delimiters that separate instructions from data and enable input sanitization
• Input sanitization: wrapping and delimiting untrusted user/retrieved text so it cannot be read as an instruction
• Iterative refinement as diagnosing a specific gap, changing one thing, re-running, and comparing

Skills in

• Providing worked examples to lock in format and edge-case behavior when prose instructions alone are insufficient
• Placing long input material before the instruction and the key ask near the end of the prompt
• Using delimiters/XML tags to separate instructions from data and to label parts of a prompt
• Sanitizing and delimiting untrusted input so it is not read as an instruction
• Iterating on a prompt one change at a time and folding recurring lessons into the standing system prompt

Knowledge of

• The context window as a shared budget: system prompt, tool schemas, conversation history, tool results, and retrieved documents all compete for the same finite space
• Context rot: attention degradation caused by the window filling with irrelevant or stale content, distinct from simply running out of room
• Context drift: the gradual loss of track of instructions or facts over a long interaction
• The goal of finding the smallest set of high-signal tokens that maximizes the odds of the desired outcome

Skills in

• Tracking how full the context window is rather than assuming raw capacity is sufficient
• Recognizing symptoms of context rot/drift (ignored earlier instructions, degraded quality) in a long-running session
• Avoiding the trap of dumping entire documents or full tool outputs when a summary or relevant slice suffices
• Curating context toward the smallest high-signal set rather than maximizing what is included

Knowledge of

• Tool-output pruning: keeping only what later steps need from a large tool payload and dropping raw dumps from history
• Compaction: periodically summarizing older turns into a compact recap to reclaim budget while preserving the thread
• The distinction between compaction (summarize to reclaim budget) and truncation (blindly dropping tokens, risking lost facts)
• Context isolation: delegating a heavy subtask to a subagent with its own context window that returns a condensed result
• Just-in-time retrieval: pulling information into context when needed rather than front-loading everything

Skills in

• Pruning large tool outputs down to the slice later steps actually need
• Compacting older turns into a recap instead of carrying the full transcript or truncating blindly
• Delegating heavy subtasks to a subagent to keep the main context window clean
• Retrieving information just-in-time rather than front-loading an entire knowledge base or document set

Knowledge of

• Structured output patterns: requesting JSON against a schema via tool use/tool-forcing or structured-output features, and prefilling the assistant turn to nudge JSON-only responses
• Response validation: checking types, required fields, and allowed values before trusting output, since well-formed JSON can still be semantically wrong
• Defensive parsing: tolerating extra prose, handling truncation (stop_reason: max_tokens), and retrying, repairing, or falling back on failure
• Skepticism toward confident output: Claude can be confidently wrong, so polish and certainty are not evidence of correctness

Skills in

• Defining a tool whose input schema is the target output shape and requiring Claude to call it for reliable structured output
• Validating both the structure and the semantic correctness of model output before acting on it
• Writing defensive parsing logic that tolerates imperfect output instead of crashing on a parse error
• Grounding high-stakes claims in sources and keeping a human in the loop rather than trusting confident-sounding output