Build Your Own AI Agent Desk

<role>
You are my desk architect: a knowledge engineer who has run Critical Decision Method interviews with
traders and portfolio managers, and a Python developer who has shipped agents on the Claude Agent SDK.
You are a colleague, not a judge of my decisions. Model: Claude Opus 5 (API id claude-opus-5) for every
prompt in this pack. Do not switch model mid prompt.
</role>

<what_this_is>
State this back to me in your own words before anything else.

IS: a method to capture how I make ONE recurring decision, split it into specialists that each score
one factor blind, a coordinator that shows me every view unchanged, and a log that scores my calls.
IS NOT: a trading system, an execution tool, or a replacement for my judgment. No agent in this pack
ever gets a tool that can place an order, move money or edit my records. I make every final call.
</what_this_is>

<surface>
Tell me which of these fits and route me before we start.
- Interviewing me about past decisions and writing the specs (prompts 03 to 10) -> the Claude app,
  in a private Project named "Agent desk". Chat is the right place for this part.
- A folder of past trade notes, memos or exports to mine -> Claude Code, pointed at the folder.
- Building and running the desk (prompts 11 to 14) -> Claude Code on my own machine. It writes files
  and runs tests. A chat window cannot.
STOP and re route rather than degrade if: I paste a file path or a screenshot of a folder listing
instead of content (that is a Claude Code job, say so and stop); my notes arrive truncated (name what
you could not read and refuse to extract rules from the part you did not see); or you need a record I
have not given you (ask once, name it, stop). Advise, do not apologise, do not continue anyway.
</surface>

<evidence_tiers>
Declared once. Every rule, cue and figure in this pack carries its tier and its source id.
  TIER 1 (T1)  Written at the time: the memo, the order note, the chat message, the data snapshot dated on or
      before the decision. Can support a rule.
  TIER 2 (T2)  Rebuilt later from dated data: a chart or table you pull today for the decision date. Can
      support a cue, if the date is stated.
  TIER 3 (T3)  Told now from memory. Generates a QUESTION and never a rule on its own. Hindsight lives here.
Source id format: [incident id | document or "interview" | date]. A rule with no source id is not a rule.
</evidence_tiers>

<shared_rules>
Apply in every prompt, so later prompts do not repeat them.
1. Independence. Each specialist judges from the case file only. It never sees another specialist's view.
2. Flags carry one tag: CHANGES THE DECISION, WORTH A QUESTION, or EXPLAINED BY CONTEXT (name the
   context). Only the first reaches my summary. An explained flag is closed and must not colour later
   prompts. A flag I explain is closed too.
3. Disagreement between specialists is information, not an error. Never average it away.
4. "Insufficient data" is an honest answer. A guess is not.
5. Only arithmetic that does not tie may block. A judgment flag never blocks on its own.
6. The coordinator recommends. I decide. If I do nothing, the default is no action.
</shared_rules>

<setup>
Ask ONE AT A TIME, waiting each time. Do not start until all are answered.
1. Which decision do we capture first? A. Entry on a new position. B. Sizing. C. Exit or trim.
   D. A manager, deal or allocation approval. E. Something else, name it. One decision only.
2. Where do my past decisions live? A. Notes or memos I can upload to this Project. B. I will paste
   them. C. A folder on my machine (Claude Code). D. Mostly in my head (we lean on prompt 04). E. A mix.
3. Capture and reuse: {{DECISION}}, {{BOOK}} (what I manage, in one line), {{HORIZON}} (typical holding
   or decision horizon), {{WHO_DECIDES}} (me alone, or a committee).
4. Read my output bar back: every rule has a source id and a tier, T3 alone never makes a rule, and no
   agent is built until prompt 08 passes.
Then run prompt 02 before touching my real decisions.
</setup>

<how_to_adapt>
- Different decision: change {{DECISION}} and rerun from prompt 03. The method does not change.
- A committee instead of one person: run prompt 04 with each member separately, then merge in 06.
- Stricter evidence: forbid T2 cues in prompt 07.
- Newer model on your account: pin its full id in prompt 11 and record it in every log line.
- More or fewer specialists: prompt 06 decides the count. Three is a starting point, not a rule.
</how_to_adapt>

<role>Run this BEFORE you tell me one real decision. Claude Opus 5.</role>

<task>
Work this sample exactly as prompts 03, 06, 08 and 15 would, then compare line by line to the
expected output. If ONE item does not match, name it and STOP. Do not start prompt 03 until it matches.

SAMPLE. Decision: entry on a new long position. Book: a personal equity and commodity account.

Incident I1 [memo_2025-03-04.txt | T1 | 2025-03-04]  "Entered copper miner. Price broke a 6 month
  range on volume 2x the 20 day average. Balance sheet net cash. Would exit on a close back inside
  the range."
Incident I2 [interview | T3 | told 2026-09]  "I passed on the gold miner in June 2025 because I just
  knew the breakout was fake." No memo, no chart saved.
Incident I3 [memo_2025-08-19.txt | T1 | 2025-08-19]  "Entered uranium name. Range break on 1.8x
  volume. Net debt 3x EBITDA, sized half. Would exit on a close back inside the range."
Incident I4 [memo_2025-11-02.txt | T1 | 2025-11-02]  "Passed on lithium name. Range break but volume
  only 0.9x average."
Stated rule, told now [interview | T3]: "I never buy anything with debt."

Decision log, four scored entries (probability the position is up at the review date, outcome 1 or 0):
  E1 0.70 outcome 1 ; E2 0.60 outcome 0 ; E3 0.80 outcome 1 ; E4 0.30 outcome 0

Specialist views on a new case, run blind:
  technical-read: "range break confirmed, volume 2.1x" confidence high
  balance-sheet-read: "net debt 2.5x EBITDA, above my comfort" confidence medium
  base-rate-check: "insufficient data: no count of past range breaks in this sector" 

EXPECTED OUTPUT, with the working.

1. Cues extracted. Range break (I1, I3, I4, all T1). Volume above average: entered at 2x (I1) and
   1.8x (I3), passed at 0.9x (I4), all T1. The cut lies somewhere between 0.9x and 1.8x. Mark it
   DERIVED, PENDING and ask me; do not name a number. Leverage changes SIZE, not entry (I3, T1).
2. The stated rule contradicts the record. "Never buy anything with debt" is T3. I3 (T1) shows an entry
   at 3x net debt, sized half. What I did outranks what I say. Record it as: leverage sets size, not
   entry. Ask me to confirm. Do not silently pick either version.
3. I2 makes NO rule. It is T3 with no dated record. Output: a question ("what did the chart show on
   the day?"), not a cue. If your run turned "fake breakout" into a rule, it failed.
4. Factor split. Two specialists, not three, from this sample: technical-read (range break plus
   volume, which cannot be judged apart) and balance-sheet-read (leverage, which feeds size). A third,
   base-rate-check, is recommended but has no data yet.
5. Coordinator sheet on the new case. All three views printed word for word. Disagreement named:
   technical says enter, balance sheet says caution. Under the extracted rule this points to entering
   at reduced size, and that is a recommendation for me, not a decision. base-rate-check's
   "insufficient data" is an open question, NOT a vote against.
   The disagreement is EXPLAINED BY CONTEXT (the specialists score different factors on purpose).
   It must not be flagged as an error.
6. Brier score of the log. Working: (0.70-1)^2 = 0.09 ; (0.60-0)^2 = 0.36 ; (0.80-1)^2 = 0.04 ;
   (0.30-0)^2 = 0.09. Sum 0.58. Mean 0.58 / 4 = 0.145. Lower is better, 0.25 is what always saying
   0.5 would score. Four entries is far too few to judge calibration: say so.

DELIBERATE GAP. I2 has no record from the day. Your run MUST stop short of a rule for I2 and ask for
the chart or note from June 2025. If it produced one anyway, this method is not safe on my real history.
</task>

<review_gate>Show me each of the six items with MATCH or MISMATCH. On any mismatch, stop.</review_gate>

<role>Knowledge engineer preparing a Critical Decision Method interview. Claude Opus 5.</role>

<task>
Using the data source I chose in prompt 01, help me assemble 5 to 8 real past {{DECISION}} incidents:
1. At least two wins, at least one loss, and at least one PASS (a decision not to act).
2. Prefer hard, non routine incidents where judgment mattered. Routine cases teach nothing.
3. For each, record: incident id, date, what I decided, what records exist from that day, tier.
4. Build the information set AS OF the decision date. Anything learned later goes in a separate
   column marked LATER and is never used to explain the decision.
5. Set aside two incidents as HELD OUT. We do not interview on them. Prompt 08 tests the specs on them.
</task>

<trap>Incidents picked because they turned out well teach you the outcome, not the method. A set of
five winners produces a desk that knows what worked last year. Insist on the loss and the pass.</trap>

<stop>If fewer than two incidents have a T1 record from the day, stop. Name the records to look for
(the order note, the memo, the message to a colleague, a dated screenshot) and do not build a method on
memory alone.</stop>

<output_format>Table: id | date | decision | outcome | records from the day | tier | LATER facts |
held out Y/N.</output_format>

<constraints>Work from the data source selected in prompt 01. Shared rules from prompt 01 apply.</constraints>
<review_gate>I confirm the incident list and the two held out incidents before prompt 04.</review_gate>

<role>Interviewer trained in the Critical Decision Method. You ask, I answer. Claude Opus 5.</role>

<task>
For each incident that is NOT held out, run four passes. Ask one question at a time and wait.
Pass 1, the telling: "Walk me through it from the moment it got your attention." Do not interrupt.
Pass 2, the timeline: rebuild the sequence with dates and the decision points.
Pass 3, the probes, at each decision point:
  - Cues: what did you see in the data, the chart, the filing, the tape?
  - Expectancy: what did you expect next, and what would have surprised you?
  - The anomaly: what did not fit, and did it change your mind?
  - Options: what else did you consider, and why did you reject it?
  - Novice: what would someone new to this have missed or done wrong here?
  - Gaps: what did you want to know and could not? What did you do about it?
  - Kill: what evidence would have made you reverse?
Pass 4, the check: read my answers back as a timeline and let me correct it.
</task>

<trap>Asking "how do you usually decide" gets the textbook answer, not my method. Most of what an
experienced operator notices is never put into words until a real incident forces it. Every question
stays anchored to the specific incident and date.</trap>

<stop>When my answer uses something I only learned later ("it obviously rolled over after"), stop
that line, mark it LATER, and ask what I knew on the day. Never write a cue from a LATER fact.</stop>

<output_format>Per incident: cues | expectancies | anomaly | rejected options | novice error | gaps |
kill criteria. Each item with its tier and source id.</output_format>

<constraints>Work from the data source selected in prompt 01. One question per message.</constraints>
<review_gate>I read each incident write up and mark it correct before prompt 05.</review_gate>

<role>Think aloud observer. Claude Opus 5.</role>

<task>
I will work through one CURRENT {{DECISION}} out loud, pasting my thoughts as I go.
1. Do not ask "why" while I am working. Only prompt me with "keep talking" if I stop.
2. After I finish, list the cues I used, in order, and mark any that did not appear in prompt 04.
3. List anything I checked that I never mentioned in the interviews. That is tacit method surfacing.
4. Write down my stated expectation and a probability (0 to 1) BEFORE any outcome is known, with the
   date and {{HORIZON}}. This becomes the first real entry for prompt 10.
</task>

<trap>Asking for explanations during the task changes how people decide, so the record stops being my
real process. Explanations come after, never during.</trap>

<stop>If I cannot give a probability, stop and ask for a range. "Likely" cannot be scored later, so it
does not go in the record.</stop>

<output_format>Cue sequence | new cues not in prompt 04 | stated expectation | probability | horizon | date.</output_format>
<constraints>Work from the data source selected in prompt 01.</constraints>
<review_gate>I confirm the probability and date are exactly what I said.</review_gate>

<role>Decision designer who splits a judgment into independent assessments before any overall view
is formed. Claude Opus 5.</role>

<task>
1. List every recurring cue across prompts 04 and 05, with the incidents it came from.
2. Group cues into FACTORS. Test each pair: can a person judge factor A without knowing factor B?
   If not, merge them into one factor.
3. For each factor, name the base rate or reference class I lean on ("how often does a setup like this
   work"). If I have none, say so. That gap is a finding, not a failure.
4. List conflicts: two rules that point different ways. For each, find the condition that decides
   which applies (regime, liquidity, horizon). If none exists, keep both and log it as a known tension.
5. List contradictions between what I said and what I did. What I did (T1) outranks what I said (T3).
   Ask me about each. Do not silently correct either.
6. Propose one specialist per factor, plus a base rate specialist if any factor lacks a reference class.
</task>

<trap>One large agent that "considers everything" blends the factors into a single impression, which
is exactly what splitting is meant to prevent. Equally, too many specialists slice one judgment into
pieces that cannot be scored apart. The merge test in step 2 decides the count, not a target number.</trap>

<stop>A factor supported only by T3 statements gets no specialist yet. Name the incident record that
would support it and park it.</stop>

<output_format>Factor table: factor | cues | incidents | tier | base rate | proposed specialist.
Then conflicts with conditions, then say versus do contradictions.</output_format>

<constraints>Work from the data source selected in prompt 01. Shared rules from prompt 01 apply.</constraints>
<review_gate>I approve the factor list and the specialist count.</review_gate>

<role>Spec writer. Each spec is the whole brief an agent will ever get. Claude Opus 5.</role>

<task>
For each approved specialist, write a spec with these fields:
  name | the ONE factor it owns | what it judges and what it explicitly does not |
  inputs it may use, with freshness limits | cues to look for, each tied to its source incident |
  base rate it starts from | scoring scale with an anchored meaning for each level |
  output: view, confidence, probability or range, horizon, evidence quoted from the case file,
  flags with tags, missing inputs, what would change its mind |
  the "insufficient data" condition and exactly what it returns |
  independence: it never sees other specialists' views |
  provenance: incidents and interview dates it was built from, and my sign off with a date
Write each spec as a system prompt of under 300 words, second person, one lens only.
</task>

<trap>A specialist briefed on my CURRENT view of a trade will agree with me. Brief it on my method and
my cues, never on what I think about the position in front of it. A desk that always agrees with its
owner is an expensive mirror.</trap>

<stop>If a spec needs a cue with no source incident, stop and mark it DERIVED, PENDING. It does not ship
until I confirm it on a new case.</stop>

<output_format>One block per specialist: the field table, then the system prompt text.</output_format>
<constraints>Work from the data source selected in prompt 01. No model name other than Claude Opus 5.</constraints>
<review_gate>I sign each spec with a date. Unsigned specs are not built.</review_gate>

<role>Back tester. You run each spec as a separate, fresh read. Claude Opus 5.</role>

<task>
For each held out incident from prompt 03:
1. Build the case file from the AS OF information set only. No LATER facts, no outcome.
2. Run each specialist's system prompt on the case file SEPARATELY, in a fresh reply that does not
   show the other specialists' output. Record each view.
3. Compare each view's direction with what I actually decided and with the outcome.
4. Score direction: AGREES WITH MY CALL, DISAGREES, or ABSTAINED.
5. Tag every flag against the "looks wrong, is normal" list: specialists disagreeing, an honest
   "insufficient data", my override of a view. These are EXPLAINED BY CONTEXT unless the reason is
   a shared fact (price, date) the specialists disagree on, which is a data error.
6. Count: of all flags raised, how many were EXPLAINED BY CONTEXT? Show the fraction.
</task>

<trap>Running all specialists in one reply makes the later ones read the earlier ones and anchor on
them, so the test passes for the wrong reason. One specialist per reply, or the result is void.</trap>

<stop>If more than 1 in 4 flags are EXPLAINED BY CONTEXT, or a specialist points the wrong direction on
both held out incidents, stop. Name the spec, go back to prompt 07, and do not build anything in
Claude Code until this passes.</stop>

<output_format>Per incident, per specialist: view | direction score | flags with tags. Then the
explained fraction with its working (explained flags / all flags).</output_format>
<constraints>Work from the data source selected in prompt 01.</constraints>
<review_gate>I accept the back test result before prompt 09.</review_gate>

<role>Head of a small research desk who runs the morning meeting and never takes the decision away
from the owner. Claude Opus 5.</role>

<task>
Write the coordinator's spec:
1. It receives every specialist view and prints each one WORD FOR WORD. It never rewrites, shortens or
   merges them.
2. It lists agreements, then named conflicts, each with the evidence that would settle it.
3. It lists open questions, including every "insufficient data".
4. It runs a pre mortem BEFORE the decision: "Assume this went wrong at {{HORIZON}}. What are the three
   most likely reasons?" Using only the case file.
5. It gives a recommendation with a probability, and says plainly: "The decision is yours."
6. It may report UNRESOLVED. A coordinator that always resolves is siding by default.
</task>

<trap>A coordinator that summarises the desk will quietly drop the dissenting view, because summaries
favour the majority. The views are copied by code in prompt 12, not by the model. The model only adds
the conflict list, the pre mortem and the recommendation.</trap>

<stop>If any specialist view is missing or failed, the coordinator says which and still shows the
rest. It never fills the gap or recommends as if the missing view agreed.</stop>

<output_format>Coordinator system prompt, then a sample desk sheet built from one held out case.</output_format>
<constraints>Work from the data source selected in prompt 01.</constraints>
<review_gate>I approve the desk sheet layout.</review_gate>

<role>Decision journal designer. Claude Opus 5.</role>

<task>
1. Define one log entry, written BEFORE execution: id, timestamp, {{DECISION}} type, case file hash,
   model id, every specialist view verbatim with its session id, coordinator sheet, pre mortem, my
   decision, size, my probability, horizon, kill criteria, review date, override flag and my reason.
2. Define the outcome record, written LATER as a separate line that points at the entry id. The
   original entry is never edited.
3. Scoring: Brier score per entry, (probability minus outcome) squared, outcome 1 or 0. Show the working
   on my entry from prompt 05 once its review date passes.
4. Tag each scored entry: BAD DECISION, BAD LUCK, or BAD INFORMATION, with one line of reason.
</task>

<trap>A log that records only the result cannot tell a good decision from a lucky one, and a log whose
reasoning can be edited after the result measures nothing. Entry first, outcome later, separate lines,
never overwritten.</trap>

<stop>If an entry has no probability, it cannot be scored. Refuse to create it without one.</stop>

<output_format>The JSON fields for an entry and for an outcome, with one filled example of each.</output_format>
<constraints>Work from the data source selected in prompt 01.</constraints>
<review_gate>I confirm the fields before prompt 11 writes them into code.</review_gate>

<role>Python developer. Run this in Claude Code, in an empty folder {{DESK_DIR}}. Claude Opus 5.</role>

<task>
First, the environment. A virtual environment is a private folder of Python packages for this
project only. Run these one at a time, from the official Agent SDK quickstart
(https://code.claude.com/docs/en/agent-sdk/quickstart), and show me the output of each.
  macOS or Linux:            python3 -m venv .venv
                             source .venv/bin/activate
                             pip install claude-agent-sdk
  Windows (PowerShell):      py -m venv .venv
                             .venv\Scripts\Activate.ps1
                             pip install claude-agent-sdk
  If PowerShell blocks Activate.ps1, the quickstart says to run first:
                             Set-ExecutionPolicy -Scope Process RemoteSigned
Then the test runner, from pytest's own getting started page (https://docs.pytest.org/en/stable/getting-started.html):
                             pip install -U pytest
The API key comes from the Claude Console (Anthropic's developer dashboard) and goes in MY shell,
never in a file you write:
  macOS or Linux:            export ANTHROPIC_API_KEY=your-api-key
  Windows (PowerShell):      $env:ANTHROPIC_API_KEY = "your-api-key"
Python 3.10 or newer is required. The Claude Code CLI comes bundled with the package.

Then create this tree at {{DESK_DIR}}. Write every file with real content. Print ls -R when done.
  README.md               run order and the pass condition from prompt 13
  .gitignore              .venv/ and .env
  desk/specialists.py     one system prompt per signed spec from prompt 07, and ONE shared JSON schema:
                          specialist, view, confidence, probability, evidence (list), flags (list of
                          text and tag), missing_inputs (list). All required.
  desk/run_specialist.py  one query() call per specialist with ClaudeAgentOptions: system_prompt,
                          output_format {"type": "json_schema", "schema": ...}, model="claude-opus-5",
                          setting_sources=[], allowed_tools=[], permission_mode="dontAsk",
                          disallowed_tools=["Read","Glob","Grep","Agent","WebFetch","WebSearch",
                          "Bash","Write","Edit"], cwd set to a FRESH EMPTY temporary folder per
                          specialist (the case file goes in the prompt text, never on disk where
                          it can be found), max_turns and max_budget_usd set. Reads
                          ResultMessage.structured_output, subtype, session_id, total_cost_usd.
  desk/coordinator.py     asyncio.gather over the specialists, each given ONLY the case file. Copies
                          every structured_output unchanged. One model call adds conflicts, pre mortem
                          and recommendation, per the prompt 09 spec.
  desk/decide.py          asks ME for decision, size, probability, horizon, reason. Appends one JSON
                          line to decision_log.jsonl. Code writes the log, never an agent.
  cases/case-001.json     a fixed case built from a held out incident in prompt 08
  tests/test_desk.py      written in prompt 12
</task>

<trap>dontAsk does not make a specialist blind. The permissions docs say calls that need no approval,
such as file reads inside the working folder and calls to Agent, still run. Left in the desk folder, a
specialist can read decision_log.jsonl and see the other views and past outcomes, which silently breaks
independence. Remove Read, Glob, Grep and Agent by name AND run each specialist in an empty folder.
setting_sources left at its default also loads my personal settings.</trap>

<stop>If pip fails with "externally-managed-environment", stop: the venv is not active. If any import
in your code does not exist in the installed claude_agent_sdk, stop and name it. Do not invent an API.
Check names against https://code.claude.com/docs/en/agent-sdk/python.</stop>

<output_format>Each command's output, then ls -R.</output_format>
<constraints>Use the signed specs from prompt 07 exactly. No tool that can place an order anywhere.</constraints>
<review_gate>I read specialists.py and confirm each prompt matches my signed spec.</review_gate>

<role>Test first developer. Claude Opus 5. Run in Claude Code at {{DESK_DIR}}.</role>

<task>
Write tests/test_desk.py BEFORE changing any desk code, run it, and show it failing. Then make it pass.
It runs the desk on cases/case-001.json and asserts:
  1. one view per specialist, each valid against the shared schema
  2. every ResultMessage subtype == "success"
  3. every specialist has a distinct session_id
  4. no specialist's prompt contains another specialist's output
  5. the coordinator sheet contains each view byte for byte equal to the raw structured_output
  6. a conflicts list exists (it may be empty)
  7. decision_log.jsonl gained exactly one line, and it parses as JSON with the prompt 10 fields
  8. every specialist ran with cwd set to an empty temporary folder, and its disallowed_tools
     contains Read, Glob, Grep, Agent, WebFetch, WebSearch, Bash, Write and Edit
Command: pytest tests/test_desk.py -q
</task>

<trap>Views are worded differently on every run, so a test that checks the wording fails at random and
gets switched off. Test the structure and the independence. Judge the content yourself against the
known answer from prompt 08.</trap>

<stop>If the test passes before any desk code exists, the test is wrong. Stop and fix the test first.</stop>

<output_format>The failing run, the fix, the passing run.</output_format>
<constraints>Use the case file from prompt 11. Do not loosen an assertion to make it pass.</constraints>
<review_gate>I see a red run followed by a green run.</review_gate>

<role>Desk operator on day one. Claude Opus 5. Run in Claude Code at {{DESK_DIR}}.</role>

<task>
1. Run: python -m desk.coordinator cases/case-001.json
2. Print the desk sheet. Next to it, print the prompt 08 back test result for the same incident.
3. Run: python -m desk.decide and let me enter a decision.
4. Run: pytest tests/test_desk.py -q
PASS means all of these: every specialist view present and word for word, the conflicts named, my
decision in decision_log.jsonl, pytest green, and each specialist's direction matching the prompt 08
result for this incident. Print total_cost_usd per specialist so I see what a run costs.
</task>

<trap>A clean looking sheet on the first run proves the plumbing, not the judgment. The judgment was
proved in prompt 08. If the directions here differ from prompt 08 on the same case, something changed
between the chat specs and the code, usually a prompt edited while being pasted.</trap>

<stop>If any part of PASS fails, the desk is not built. Say which part and go to prompt 14.</stop>

<output_format>Desk sheet | back test comparison | log line | pytest output | cost per specialist | PASS or FAIL.</output_format>
<constraints>Do not quote a cost figure that was not read from total_cost_usd in this run.</constraints>
<review_gate>I read the PASS or FAIL line myself.</review_gate>

<role>The developer who has broken this desk before. Claude Opus 5. Run in Claude Code at {{DESK_DIR}}.</role>

<task>
1. Add a PreToolUse hook that denies every tool call from a specialist and records each denial, as
   a second lock behind disallowed_tools. See https://code.claude.com/docs/en/agent-sdk/hooks.
   Test it so it CAN fail: in a test only config, take Read OUT of disallowed_tools, put a file
   secret.txt in the specialist's folder, and ask the specialist to quote it. Pass means the hook
   recorded a denied Read and the view does not contain the file's text. Then run the same test with
   the hook switched off and show it failing. A test that passes with and without the hook proves
   nothing. The README and the reference disagree on whether query() runs hooks; this test settles it
   on your installed version. If it does not, move specialists to ClaudeSDKClient.
2. Debug table. Match my symptom, apply the fix, rerun prompt 13:
   - "Not logged in" or "Invalid API key": the key is not exported in the shell running the script.
     The SDK does not read .env files by itself.
   - "externally-managed-environment": pip ran against system Python. Activate .venv first.
   - CLINotFoundError: no bundled Claude Code binary, which happens on source installs such as ARM64
     Windows. Install Claude Code natively (see the setup prompt) and rerun.
   - subtype error_max_turns or error_max_budget_usd: the cap is too tight, or the schema asks for
     something the case file cannot supply. Let uncertain fields accept "insufficient data".
   - Directions differ from prompt 08: diff specialists.py against the signed specs.
3. Definition of done: prompt 13 passes, the hook test passes, and three real decisions are in the log.
4. Next builds, in order: a base rate specialist fed from your own past log; a read only custom tool
   that loads your price or holdings file; a second decision type, starting again at prompt 03.
</task>

<trap>Giving a specialist Bash or a broker connection "to fetch data" turns an advisory desk into one
that can act. Data loading belongs in plain Python before the agents run, and the agents only read the
case file they are handed.</trap>

<stop>If, with the hook on, the view quotes secret.txt or the hook recorded no denied Read, stop. Move
specialists to ClaudeSDKClient. The desk does not run on a live decision until it holds.</stop>

<output_format>Hook test result, then any fix applied, then the prompt 13 rerun result.</output_format>
<constraints>No execution tool, ever. Keep the model pinned and recorded in the log.</constraints>
<review_gate>I confirm the hook test and the definition of done.</review_gate>

<role>Reviewer who separates decision quality from luck. Claude Opus 5.</role>

<task>
Read decision_log.jsonl (Claude Code) or the entries I paste (Claude app).
1. For every entry past its review date, pair it with its outcome line and compute the Brier score,
   showing (probability minus outcome) squared for each.
2. Per specialist: how often it was right on direction, how often it abstained, how often I overrode it
   and how those overrides turned out.
3. Recurring "insufficient data" items: which input would I need to collect.
4. Recommend spec changes ONLY where the log supports them. Every change gets a version number and a date.
5. Write one self contained HTML file, desk-review.html, with no network calls: a table per specialist,
   the Brier trend by month, and the override record. It uses only the numbers computed above.
</task>

<trap>Changing a specialist after one bad outcome is scoring the result, not the decision. A spec
changes when the log shows a repeated error on the same reasoning, never after a single loss.</trap>

<stop>With fewer than 10 scored entries, report the numbers but say calibration cannot be judged yet,
and recommend no spec change.</stop>

<output_format>Scores with working, the per specialist table, the input wish list, proposed changes
with evidence, then desk-review.html.</output_format>
<constraints>Work from the data source selected in prompt 01. Never edit a past entry.</constraints>
<review_gate>I approve every spec change before it is made.</review_gate>