Reference

Glossary 93 terms

Every vocabulary term from the six-week course, gathered in one searchable list. Click a week tag to jump back to the section that defines the concept.

#

-p Week 3
the non-interactive Claude Code execution flag used for automation and CI-friendly runs.
.claude/settings.json Week 3
project-shared runtime settings (permissions, env, hooks, statusline); committed to the repo.
.claude/settings.local.json Week 3
project-scoped but personal overrides that should be gitignored; lets one developer adjust settings without changing what teammates see.
.mcp.json Week 3
the project-root file holding MCP server configuration that is shared with teammates through version control.
@import Week 3
a mechanism for splitting large instruction sets into smaller reusable files that can be loaded selectively.
~/.claude.json Week 3
the user-specific Claude Code configuration file in the developer's home directory; never travels with the repo.

A

adaptive decomposition Week 1
dynamic task splitting where the coordinator adjusts subtask structure as it learns more about the problem.
agentic loop Week 1
the repeated control cycle of asking the model for the next step, inspecting its state, running tools if requested, appending results, and continuing until completion.
allowed-tools Week 3
skill or agent configuration that limits which tools can be used during a specific workflow.

B

batch processing Week 4
asynchronous handling of many requests where lower cost and high throughput matter more than immediate response time.
batch workflow Week 3
a queued workload submitted via the Message Batches API for high-volume, latency-tolerant work in exchange for a discounted price.
boundary condition Week 2
a rule or edge case that defines where a tool should stop being used or when its behavior changes.
business error Week 2
a domain-rule failure where the system worked technically but the request could not be completed under policy or product rules.

C

clarification trigger Week 5
a condition where the system should ask for more information before safely proceeding.
CLAUDE.md Week 3
the core instruction file used to store persistent guidance for Claude Code at the relevant scope.
confidence calibration Week 5
the process of ensuring confidence scores correspond to real observed accuracy rather than vague model certainty.
contested finding Week 5
a result that remains disputed because credible evidence conflicts or one source cannot yet be resolved.
`context Week 3
fork`: a skill setting that isolates verbose or exploratory work from the main session by running it in a forked context.
context economy Week 2
the discipline of keeping tool output, system prompts, and reference material proportional to the reasoning the model actually needs to do.
control surface Week 6
the mechanism the system should use to influence behavior, such as tool contracts, gates, schemas, hooks, or routing logic.
coordinator Week 1
the primary agent responsible for planning, routing, aggregation, coverage checking, and recovery across a larger task.
customer-safe behavior Week 6
system behavior that avoids risky assumptions, hidden failure, or unsafe automation in user-facing contexts.

D

decomposition Week 1
the act of splitting a larger task into smaller units that can be solved more reliably or in parallel.
direct execution Week 3
the mode where the system proceeds straight to implementation because the change is already well understood.
directory scope Week 3
guidance that applies only within a particular subtree of the repository.
distractor Week 6
a plausible but wrong answer option that solves an adjacent problem instead of the one described.

E

end_turn Week 1
a stop_reason indicating that the model has finished its current turn and is returning control without another tool call.
enum Week 4
a field constrained to one of a known set of allowed values.
escalation trigger Week 1 · Week 5
a deterministic condition — explicit user request, threshold breach, unresolved identity — that routes a workflow to a human rather than relying on model discretion.
evidence-preserving synthesis Week 6
combining results into a final answer without losing attribution, uncertainty, or claim-source mappings.
explicit criteria Week 4
concrete category rules that state exactly what should be reported, skipped, escalated, or labeled at a given severity.

F

facts block Week 5
a stable structured record of critical operational facts such as IDs, dates, amounts, statuses, and constraints.
false positive Week 4
a finding that the system reports as a problem even though it should not have been flagged.
few-shot example Week 4
a small set of input-output demonstrations used to show the model how to handle ambiguous or judgment-heavy cases.
forced tool choice Week 2
a tool_choice configuration naming a specific tool, locking the next turn to exactly that action.
forked session Week 1
a branched working context created from a shared baseline so alternative approaches can be explored independently.

G

gap re-delegation Week 1
spawning a focused subagent to cover a specific coverage gap surfaced during synthesis, in place of restarting the full task.

H

handoff brief Week 1
a self-contained summary used at agent-to-agent or agent-to-human transitions, carrying case ID, established facts, root cause hypothesis, actions attempted, and a recommended next step.
hook Week 1
an application-level interception point that can inspect, normalize, block, or redirect tool behavior outside the model’s free-form reasoning.

I

idempotent tool Week 2
a tool whose effect is the same regardless of how many times it is called with the same input, which makes retry safe.
independent review Week 1 · Week 4
review of an artifact performed without exposure to the generator's prior reasoning chain, usually via a separately spawned subagent or a session forked from a point before the artifact was produced.
isError Week 2
the MCP error flag that tells the caller the returned payload represents a failure rather than a successful result.

L

latency tolerance Week 3
the operational property of a workload that determines whether batch is acceptable; jobs that can wait up to 24 hours for results are latency-tolerant.
least privilege Week 2
the design principle of giving an agent only the minimum tool access needed to do its role safely and reliably.
lost in the middle Week 5
the tendency for important information buried in the middle of a long context window to receive less reliable attention.

M

manifest Week 5
a structured restoration record used to resume work or reconstruct workflow state after interruption or branching.
MCP resource Week 2
structured content exposed by an MCP server for reference or discovery without invoking an action tool.
Message Batches API Week 3
the Anthropic API surface for batch processing — currently offers a ~50% discount, up to 24-hour turnaround, and a per-batch request/size cap.
multi-pass review Week 4
a review design that breaks evaluation into more than one focused pass, such as local and cross-file analysis.

N

nullable field Week 4
a schema field that may intentionally contain null when the source does not provide the value.

O

other Week 4
an extensibility pattern used when a known enum does not fully cover the observed case and more detail must be captured separately.
over-engineering Week 6
adding heavier architecture than the scenario needs instead of making the smallest correct change.
overlap Week 2
a situation where two tools appear to solve the same problem, making tool selection ambiguous and error-prone.

P

partial result Week 1 · Week 5
work a subagent finished before failing or timing out, preserved and returned to the coordinator instead of being discarded.
path-scoped rules Week 3
rules that apply only to files matching specified glob patterns rather than to the entire repository.
permission error Week 2
a failure caused by missing authorization, denied access, or insufficient scope.
plan mode Week 3
an exploratory operating mode used when the task is broad, uncertain, architectural, or likely to touch many files.
prerequisite gate Week 1
a deterministic check that must pass before the system is allowed to perform a downstream action.
project scope Week 3
configuration stored with the repository so teammates and automation share the same behavior through version control.
prompt chaining Week 1
a fixed multi-step workflow where the next step is preplanned rather than chosen dynamically from evolving evidence.
proportionate fix Week 6
the smallest intervention that directly solves the actual problem without adding unnecessary complexity.
provenance Week 5
the trace of where a claim came from, including source identity, date, and supporting evidence.

R

reliability-first reasoning Week 6
the habit of prioritizing correctness, safety, and recoverability over impressive but brittle behavior.
resource URI Week 2
the addressable identifier of an MCP resource, used by the model to reference content without invoking an action.
retry with feedback Week 4
a repair pattern where the retry prompt includes explicit validation errors or mismatch details.
retryable Week 2
a property indicating that trying the same action again, usually after a delay or minor adjustment, could reasonably succeed.
root cause Week 6
the actual underlying system problem rather than the visible symptom it creates.

S

scenario diagnosis Week 6
the process of identifying what failed, where it failed, and which layer owns the fix.
schema compliance Week 4
conformance to the required output structure, field names, and field types.
schema validation Week 4
a shape-level check that the output's field names, types, and required-vs-nullable patterns match the contract; collapsed into the API call by tool_use plus a JSON schema.
scratchpad Week 5
a working state area that preserves intermediate findings during a long or complex reasoning process.
segment weakness Week 6
underperformance concentrated in one subgroup, file type, document type, or workflow segment despite stronger aggregate metrics.
semantic validation Week 4
a logic-level check that the values are internally consistent and match real-world constraints (line items sum to total, dates parse, currencies align), regardless of whether the output is well-formed.
skill Week 3
a task-focused packaged capability with its own instructions and optional tool restrictions.
slash command Week 3
an invoked reusable workflow stored as a command rather than always-loaded memory.
stale tool output Week 2
a tool result that is no longer accurate because the underlying state changed after the call, requiring a fresh invocation rather than reuse.
state manifest Week 1
a structured export of long-running workflow state (subagent outputs, intermediate facts, completion markers) used to recover after interruption without rebuilding from a session transcript alone.
stop_reason Week 1
the API control signal that tells the application why the model stopped and therefore what the system should do next.
stratified sampling Week 5
evaluation by important subgroups so weak segments are not hidden by strong aggregate metrics.
structured error envelope Week 4
a failure record that names which validation layer failed and what specifically failed inside it, so downstream code can pick the right retry, escalation, or engineering fix.
structured failure context Week 1
an explicit record of what a subagent attempted, what it completed, what it failed to complete, and the reason — used by the coordinator to choose between synthesis on partial evidence, targeted re-delegation, and escalation.
subagent Week 1
a specialized agent invoked for a bounded part of the work, usually with narrower instructions and tool access than the coordinator.
synchronous workflow Week 3
an API call where something downstream — a user, a CI gate, another service — is actively waiting on the response before it can proceed.
syntax validation Week 4
a parser-level check that the output is well-formed (valid JSON, balanced brackets, escaped strings); the cheapest of the three layers and the one tool_use enforces by default.

T

temporal context Week 5
the date or time framing needed to interpret evidence correctly, especially when newer information may supersede older information.
tool contract Week 2
the practical agreement for what a tool does, what inputs it expects, what outputs it returns, and what failure modes it exposes.
tool description Week 2
the language the model uses to decide when a tool applies, how it should be used, and how it differs from similar tools.
tool_choice Week 2
the setting that controls whether tool use is optional, mandatory, or forced to a specific tool.
tool_use Week 1
a stop_reason indicating that the model wants one or more tools to be executed before the task can continue.
transient error Week 2
a temporary failure such as a timeout or flaky dependency that may succeed on retry.

U

user scope Week 3
personal configuration that affects one developer’s environment but is not automatically shared with the team.

V

validation error Week 2
a failure caused by malformed, incomplete, or invalid input rather than by infrastructure instability.
validation layer Week 4
one of the three categories — syntax, schema, semantic — at which an extraction or structured-output check happens; each layer catches a different failure type and warrants a different recovery.