Claude Architect · Lesson

Reading a Scenario Prompt

Spot the domain, the constraint and the failure cost.

Reading a Scenario Prompt is a free Claude Architect lesson on CoddyKit — lesson 2 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the Claude Architect learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.

Why Reading Comes First

The Claude Certified Architect exam is scenario-based: every question is a short situation followed by four options, exactly one correct. You see 4 of 8 scenarios, scored 100-1000, and you pass at 720.

Most wrong answers aren't knowledge gaps - they're reading gaps. The prompt always tells you which domain it lives in, what constraint must hold, and what it costs when the system fails. Miss any of those three and a plausible distractor will catch you.

This lesson trains one skill: dissect a scenario into domain, constraint, and failure cost before you ever look at the options.

The Three Signals

Train your eye to extract three signals from any scenario:

Domain - which of the five exam areas is being tested. This tells you which mental model applies.
Constraint - the hard requirement the answer MUST satisfy (e.g. "must be deterministic", "runs in CI", "context resets between subagents").
Failure cost - what breaks if the constraint is violated (financial, legal, safety, or just a slow report). High cost changes the right answer.

Read the prompt three times if needed - once per signal. The options are designed so the wrong ones satisfy two signals but violate one.

Signal 1 - Naming the Domain

The exam weights five domains. Knowing the split tells you what shows up most and which model to reach for:

D1 Agent Architecture & Orchestration - 27% (the largest)
D3 Claude Code Config & Workflows - 20%
D4 Prompt Engineering & Structured Output - 20%
D2 Tool Design & MCP - 18%
D5 Context Management & Reliability - 15%

Keywords map fast: "coordinator/subagent" - D1; ".mcp.json / tool description" - D2; "CLAUDE.md / plan mode / -p" - D3; "JSON Schema / few-shot" - D4; "summarization / lost-in-the-middle" - D5.

# Keyword -> domain map you keep in your head:
DOMAIN_HINTS = {
    "coordinator|subagent|delegate": "D1 Agent Architecture (27%)",
    ".mcp.json|tool description|isError": "D2 Tool Design & MCP (18%)",
    "CLAUDE.md|plan mode|-p|slash command": "D3 Claude Code (20%)",
    "JSON Schema|few-shot|tool_choice": "D4 Prompt Eng & Output (20%)",
    "summarization|lost-in-the-middle|provenance": "D5 Context & Reliability (15%)",
}

Spotting the Domain in Practice

Read this stem and name the domain before reading on:

"A coordinator delegates three independent lookups to subagents. One subagent returns empty; the others succeed. How should the system respond?"

Signals: "coordinator", "subagents", "delegates" - this is D1 Agent Architecture & Orchestration, specifically the Multi-Agent Research scenario. Now your mental model loads: subagents don't inherit history, distinguish an access FAILURE from a valid EMPTY result, and return partial results with coverage annotations rather than aborting the whole workflow.

Naming the domain pre-loads the correct anti-patterns to reject.

from anthropic import Anthropic

client = Anthropic()
# Coordinator delegates; each subagent gets context EXPLICITLY -
# subagents do NOT inherit the coordinator's conversation history.
subagent_prompt = (
    "You are a research subagent. Context: " + shared_facts + "\n"
    "Task: look up Q3 revenue for ACME. Return partial results "
    "and a coverage note if data is missing."
)

Signal 2 - The Constraint

The constraint is the requirement the answer cannot violate. It is often a single load-bearing phrase. Watch for these triggers:

"must never" / "guarantee" / "always block" - demands DETERMINISTIC enforcement (a hook), not a prompt.
"in CI" / "in a pipeline" - demands non-interactive -p with --output-format json.
"blocking" / "pre-merge" / "time-sensitive" - rules OUT the Batch API (no latency SLA).
"shared via VCS" vs "personal" - project ./CLAUDE.md vs user ~/.claude/CLAUDE.md.

The constraint is what separates two options that otherwise look identical.

Constraints That Force Determinism

The single most common constraint trap: a rule with financial, legal, or safety consequences. The fact sheet is blunt - hooks are 100% deterministic; prompts are ~90% probabilistic. When failure is costly, prompt guidance is the wrong answer.

If the stem says "refunds over $500 must require approval", the correct option is an outgoing-call hook that blocks the action - not "add a clear instruction to the system prompt". Same logic for identity verification: a programmatic precondition (block process_refund until get_customer returns a verified ID) beats any wording.

# Deterministic enforcement - a hook, not a prompt.
def pre_refund_hook(tool_call, state):
    if tool_call.name == "process_refund":
        if not state.get("verified_customer_id"):
            return block("Identity not verified")
        if tool_call.input["amount"] > 500:
            return block("Refund > $500 requires human approval")
    return allow()

Signal 3 - The Failure Cost

Failure cost is the lever that changes which trade-off wins. The exam rewards matching the mechanism's strength to the cost of being wrong.

High cost (money/law/safety): choose deterministic guarantees - hooks, preconditions, structured validation. Never settle for "probably right".
Low cost (an overnight audit, a draft report): cheaper, slower, model-driven paths are fine - Batch API at 50% off, adaptive decomposition.

A correct mechanism applied where the cost doesn't justify it can still be the wrong answer if a simpler option fits - but under-protecting a costly failure is always wrong.

Cost Maps to Mechanism

Tie the cost to the right tool. The Batch API is 50% cheaper with up to a 24h window but no latency SLA and no multi-turn tool calling - perfect for an overnight compliance audit, disqualified for a pre-merge check.

If a scenario says "validate each pull request before merge", the failure cost is a blocked developer and a broken main branch - that's time-sensitive, so Batch is out and an interactive -p review session is in.

# Time-sensitive / blocking -> NON-interactive CI run, NOT Batch.
claude -p "Review the diff for correctness bugs only" \
  --output-format json \
  > review.json
# Batch API (50% cheaper, <=24h, no SLA) is for overnight audits,
# never for a pre-merge gate.

Mapping All Three Together

Now combine the signals on a full stem:

"A support agent processes refunds. Policy: refunds above $500 need human sign-off. The team added a sentence to the system prompt but a few large refunds still slipped through. What should they do?"

Domain: D1 - Customer Support Agent.
Constraint: the $500 rule must hold every time ("must").
Failure cost: financial - unapproved money leaving.

Three signals point the same way: replace the probabilistic prompt with a deterministic outgoing-call hook. The reading did the work; the answer is now obvious.

signals = {
    "domain": "D1 - Customer Support Agent",
    "constraint": "refunds > $500 MUST get human sign-off",  # 'must'
    "failure_cost": "financial",                              # high
}
# high cost + 'must' -> deterministic enforcement
verdict = "Outgoing-call hook (block), NOT a system-prompt sentence"

Distractors Attack One Signal

Distractors are engineered to satisfy two signals and quietly break the third. Learn the shapes:

Right domain, right intent, wrong mechanism strength - "add explicit wording to the prompt" where a hook is required.
Right mechanism, wrong constraint - "use the Batch API" for a blocking check.
Plausible but a known anti-pattern - parsing text for "done", iteration caps as the primary stop, requiring a possibly-absent schema field, single-pass multi-file review, same-session self-review.

When two options feel close, find the signal they disagree on - that's the whole question.

A Repeatable Reading Routine

Run this routine on every scenario, in order:

1. Domain - one keyword scan; name D1-D5.
2. Constraint - underline the load-bearing phrase ("must", "in CI", "blocking", "shared").
3. Failure cost - financial/legal/safety = high; report/draft = low.
4. Predict the answer BEFORE reading options.
5. Eliminate any option that violates the constraint or matches a top anti-pattern.

And remember: there's no penalty for guessing. After eliminating, commit to your best remaining option and move on - answer every question.

# Mental checklist as pseudocode you run per question:
for scenario in exam:
    domain   = name_domain(scenario)        # D1..D5
    constraint = find_must_phrase(scenario) # the hard requirement
    cost     = failure_cost(scenario)       # high | low
    guess    = predict_answer(domain, constraint, cost)
    answer   = eliminate_antipatterns(options, constraint) or guess
    # never leave it blank - no penalty for guessing

Quick Check

Apply the three-signal routine to the scenario in the question.

Recap - Read Before You Answer

Reading a scenario well is the highest-leverage exam skill. Lock in the routine:

Domain - keyword-scan to D1-D5; the right mental model loads with it.
Constraint - find the load-bearing phrase; "must/guarantee" forces determinism, "in CI" forces -p, "blocking" rules out Batch, "shared" picks project CLAUDE.md.
Failure cost - high (money/law/safety) demands hooks and preconditions; low tolerates cheaper model-driven paths.

Predict before reading options, eliminate anything that breaks the constraint or matches a top anti-pattern, and - since there's no guessing penalty - always commit to an answer. Read three signals first, and the correct option stops being a guess.

Frequently asked questions

Is the “Reading a Scenario Prompt” lesson free?

Yes — the full text of “Reading a Scenario Prompt” is free to read here on the web, and the Claude Architect course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the Claude Architect course, upgrade to CoddyKit PRO.

What will I learn in “Reading a Scenario Prompt”?

Spot the domain, the constraint and the failure cost. You practise Claude Architect with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.

Do I need any experience to start Claude Architect?

No prior experience is required. Claude Architect on CoddyKit is structured for beginners through advanced learners; this is — lesson 2 of 4, so you can start here or from the beginning and move at your own pace.

How long does the “Reading a Scenario Prompt” lesson take?

Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.

Can I write and run code in this Claude Architect lesson?

Yes. Every Claude Architect lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.

All lessons in this course

← Back to Claude Architect