Level 5 — Give It a Way to Check Its Work

10 questions, drawn from a bank of 24 across 22 topics. Pass at 80%. Every wrong option carries a note explaining why it is tempting — those notes are the point of the quiz, so read them whether you pass or not.

attempt 1

1 / 10 · Choose one
A teammate reports that /verify built the wrong target on your project and gave up. It needs a database, an env file and a two-step build. What is the documented fix?
A teammate reports that /verify built the wrong target on your project and gave up. It needs a database, an env file and a two-step build. What is the documented fix?
Run /run-skill-generator once: it gets the app running from a clean environment, captures the install commands, env vars and launch script, and commits them as a per-project skill under .claude/skills/Explain the launch procedure in chat — the database, the env file and the two build steps — at the start of every session that needs itAccept that /verify fits standard projects only — it infers the launch from your project type and from the README, and this project is past that — so go back to reading diffs for this oneLet /verify record its own recipe: when it has to build and drive the app with nothing recorded, it writes what worked to .claude/skills/verify/SKILL.md for later runs
2 / 10 · Choose one
A two-hour unattended run has ended. Your Stop hook blocked the turn twice while Claude fixed failures, then pnpm test exited zero and the turn ended. Before you accept the diff, what has that green established?
A two-hour unattended run has ended. Your Stop hook blocked the turn twice while Claude fixed failures, then pnpm test exited zero and the turn ended. Before you accept the diff, what has that green established?
That the suite passed — the condition you wrote is the whole of what was asserted. Whether the diff is the right change is a separate question, and nothing in the run asked itThat the diff no longer needs your reading — the suite exercised the same code you would be reading, and it did so on every path the tests touch rather than the few lines your eye would land onThat the change is correct — a deterministic gate is the last rung before review, and it asserted the project’s own definition of workingNothing dependable — a Stop hook is overridden after eight consecutive blocks, so no green from a hook can be taken at face value
3 / 10 · Choose one
Claude ran the full build, said the log was clean, and moved on. The command exited 0 and printed about 40,000 characters. What did Claude actually read?
Claude ran the full build, said the log was clean, and moved on. The command exited 0 and printed about 40,000 characters. What did Claude actually read?
A truncated view that BASH_MAX_OUTPUT_LENGTH would have prevented — it defaults to 30,000 characters, and raising it towards the 150,000 ceiling keeps a long build inlineA head-and-tail excerpt cut from the read-back window, so the verdict at the end of the log arrived inline alongside the start of itA saved file path plus a short preview from the start of the output — the inline ceiling for a valid result is roughly 30,000 characters, and past it Claude reads or searches the file only if it decides toAll of it — exit code 0 makes the result valid, and the 30,000-character figure sizes the read-back window rather than capping what arrives inline
4 / 10 · Choose one
You build a check around jq -e, whose exit code 1 means "no match" and is a perfectly normal outcome. Which statement describes how Claude Code classifies that run, and why?
You build a check around jq -e, whose exit code 1 means "no match" and is a perfectly normal outcome. Which statement describes how Claude Code classifies that run, and why?
A failure — exit 1 counts as valid only for a recognised list (grep, rg, egrep, fgrep, find, diff, test, [, plus git diff and git grep), so jq -e gets the failure treatment and its smaller inline budgetA valid result — exit 1 is the documented "no match" outcome for jq -e, and Claude Code classifies by what a command means by its exit code rather than by the number aloneA failure — only exit code 0 is ever treated as a valid result, so any non-zero exit drops the run to the failure path and its smaller inline budgetA failure — jq is not a command Claude Code recognises, and an unrecognised command is filed as a failure whatever it exits with, exit 0 included
5 / 10 · Choose one
What is the bundled /verify skill documented as doing?
What is the bundled /verify skill documented as doing?
Standing in for a test suite on projects too immature to have one — which is why it waits to be invoked instead of being one of the bundled skills Claude reaches for on its ownLaunching the app so you can drive it yourself and watch the change working, which is why the docs list it beside /run in the same tableRunning the project’s test suite and reporting back which assertions failed, so you get the project’s own pass-or-fail without leaving the sessionBuilding and running your app to confirm a code change does what it should, without falling back to tests or type checks
6 / 10 · Choose one
The security-guidance plugin ran its end-of-turn review over Claude’s edits and reported nothing. What has that established?
The security-guidance plugin ran its end-of-turn review over Claude’s edits and reported nothing. What has that established?
That an unsafe commit would have been stopped — the deeper review fires on the commits and pushes Claude makes through its Bash tool, before they landThat one layer of defence in depth found nothing this time — none of the layers block writes or commits, findings reach the writing Claude as instructions, and the review model can miss issuesThe same thing a passing Stop hook establishes — both fire at the end of the turn, so a condition you defined was asserted and heldThat the diff is clear of the vulnerability classes the plugin checks — authorization bypass, insecure direct object references, injection, server-side request forgery and weak cryptography — since a separate model read the diff
7 / 10 · Choose one
You are changing the padding on a settings panel and there is no visual regression suite. What turns the design reference into a check rather than an opinion?
You are changing the padding on a settings panel and there is no visual regression suite. What turns the design reference into a check rather than an opinion?
Link the design ticket in the request so Claude can pull the reference up when it needs it, which keeps the image out of your context windowPaste the reference image and ask whether the result looks right — the model has both images in front of it and will say so if something is offPaste the reference image, then ask for a screenshot of the result compared to it, with the differences listed and fixedDescribe the intended spacing, states and breakpoint carefully in prose instead of pasting anything, since a written specification is more precise than an image
8 / 10 · Choose one
A migration will run for two hours while you are out. The end state is provable from Claude’s own output, it matters only for this session, and you do not want to edit a settings file. Which rung?
A migration will run for two hours while you are out. The end state is provable from Claude’s own output, it matters only for this session, and you do not want to edit a settings file. Which rung?
Put the check in the prompt — you already know the command, so ask for it to be run and iterated on in the same message that kicks the migration offA second opinion — a reviewer subagent reads the finished migration in a fresh context and reports what it can refute, which is the independence an unattended run needsA Stop hook — a script in the project settings file that blocks the turn from ending until the check passes, which is the strongest gate and so the right one for an unattended runA /goal condition — one typed command, nothing written to disk, and a separate evaluator re-checks it after every turn
9 / 10 · Choose one
Your Stop hook blocks on any linter finding. One finding sits in a vendored file Claude must not edit, so the check can never pass. What happens?
Your Stop hook blocks on any linter finding. One finding sits in a vendored file Claude must not edit, so the check can never pass. What happens?
Nothing bad, provided the hook returns hookSpecificOutput.additionalContext instead of blocking: the transcript labels that hook feedback rather than a hook error, so it sits outside the consecutive-block accountingThe turn never ends — the hook re-runs after every continuation, the linter reports the same vendored finding each time, and only interrupting the session gets control backClaude keeps working, and after 8 consecutive blocks Claude Code overrides the hook and ends the turn with a warning that it blocked too many consecutive timesClaude Code disables the hook for the rest of the session after the first block it cannot satisfy
10 / 10 · Choose one
You asked Claude to "make the tests pass". The run is green, and the diff loosened one assertion and skipped a case. What was missing from the request?
You asked Claude to "make the tests pass". The run is green, and the diff loosened one assertion and skipped a case. What was missing from the request?
Evidence — you accepted a green summary instead of asking for the command it ran and what that command printed, which is the documented habit for a session you were not watchingAn instruction to run the tests after implementing, which would have put the result in front of Claude and surfaced the case it skippedMore tests — with a case for every behaviour and no gaps left in the suite, loosening one assertion and skipping one case would not have been anywhere near enough to reach greenThe constraints — what must not change on the way to green, such as "no other test file is modified" and "address the root cause, don’t suppress the error"

10 questions still to answer