Skip to content
Cheat sheets

CCAR-F · Domain 4: Prompt Engineering & Structured Output · 20% of the exam

Task 4.1: Design prompts with explicit criteria to improve precision and reduce false positives

Replacing vague instructions with concrete criteria for what to report and what to skip, severity definitions with examples, and protecting developer trust from noisy categories.

Study it

  • Explicit review criteria, severity definitions and false-positive control

    Partly covered by: Evaluating LLMs

Sample questions

Try each one before opening the answer. Every option is explained, with the Anthropic documentation page that proves it.

Question 1 · choose 1

Your CI reviewer is told to "check that code comments are accurate." Most of its comment findings are about wording or slightly dated phrasing, and developers have started ignoring them, along with the few that point to real mismatches. How should you change the prompt?

  1. AHave Claude score its confidence per finding and drop those below 0.8
  2. BFlag a comment only when the behavior it describes contradicts what the code does
  3. CAsk Claude to be conservative and to report noticeably fewer comment findings in each pull request
  4. DAdd "Only report comment issues you are highly confident about" to the end of the review prompt
Show the answer and why

  • AHave Claude score its confidence per finding and drop those below 0.8

    Incorrect

    Filtering on a self-reported score does not change what Claude considers a finding in the first place.

  • BFlag a comment only when the behavior it describes contradicts what the code does

    Correct

    A specific criterion tells Claude exactly what to report and what to leave out, which is what lowers false positives.

  • CAsk Claude to be conservative and to report noticeably fewer comment findings in each pull request

    Incorrect

    A vague request to report less cuts real and trivial findings alike instead of separating them.

  • DAdd "Only report comment issues you are highly confident about" to the end of the review prompt

    Incorrect

    Confidence wording does not define what counts as an issue, so the same style findings keep coming, now labeled confident.

Explicit, categorical criteria beat general instructions such as "be conservative" or "high confidence only": define the condition that makes a comment worth flagging.

Anthropic documentation

Task 4.1Report a problem with this question

Question 2 · choose 1

Your CI reviewer covers a production service and a scripts/ folder of one-off maintenance scripts. Serious problems still matter in scripts/, but the many style and robustness comments on those throwaway scripts bury the findings in the service code. How should the review instructions change?

  1. AGive scripts/ its own higher bar, such as severe problems only, and keep the normal criteria elsewhere
  2. BLeave scripts/ out of the review entirely so that the service findings stand out
  3. CAdd "be less strict" to the instructions so that the reviewer reports fewer findings overall
  4. DKeep every finding in scripts/ but label them all as minor so that developers can skip them
Show the answer and why

  • AGive scripts/ its own higher bar, such as severe problems only, and keep the normal criteria elsewhere

    Correct

    A path-specific bar keeps the serious script findings while removing the noise, and leaves the service review unchanged.

  • BLeave scripts/ out of the review entirely so that the service findings stand out

    Incorrect

    Skipping the folder also drops the serious problems the team still wants reported there.

  • CAdd "be less strict" to the instructions so that the reviewer reports fewer findings overall

    Incorrect

    A vague, repository-wide instruction does not say where or what to drop, and it lowers the bar for the service code too.

  • DKeep every finding in scripts/ but label them all as minor so that developers can skip them

    Incorrect

    The comments still appear in every review and keep burying the service findings.

Explicit, scoped criteria beat general instructions. For paths that deserve some review but not full scrutiny, state a higher bar for that path in the review instructions, and keep the normal criteria where full review matters.

Anthropic documentation

Task 4.1Report a problem with this question

Question 3 · choose 1

Your reviewer prompt says "NEVER flag TODO comments." Claude follows it literally, but it also stops flagging TODOs that hide disabled security checks, which the team wants reported. How should the instruction be written?

  1. AKeep the rule and add a longer list of forbidden comment types
  2. BRemove all guidance about comments from the prompt
  3. CExplain the reason, including the exception for safeguards
  4. DWrite the rule in capital letters three times
Show the answer and why

  • AKeep the rule and add a longer list of forbidden comment types

    Incorrect

    More absolute rules repeat the same problem.

  • BRemove all guidance about comments from the prompt

    Incorrect

    That brings back the noise the rule was meant to remove.

  • CExplain the reason, including the exception for safeguards

    Correct

    Giving the reason lets Claude generalize the intent instead of applying a blanket rule.

  • DWrite the rule in capital letters three times

    Incorrect

    Emphasis makes the literal rule stronger, not smarter.

Adding context or motivation to instructions helps Claude understand the goal and apply it sensibly to cases the rule did not anticipate.

Anthropic documentation

Task 4.1Report a problem with this question

Question 4 · choose 1

Your review summaries keep coming out as dense markdown with nested bullets, and the prompt's "Do not use markdown lists" has not helped. The team wants short prose paragraphs. Which rewrite follows the guidance?

  1. A"Write two or three short paragraphs of plain prose."
  2. B"Do not use markdown, bullets, bold or headings."
  3. C"Never, under any circumstances, use markdown lists."
  4. D"Avoid formatting you think the team would dislike."
Show the answer and why

  • A"Write two or three short paragraphs of plain prose."

    Correct

    Telling Claude what to do steers format better than saying what not to do.

  • B"Do not use markdown, bullets, bold or headings."

    Incorrect

    Listing more things to avoid does not describe the target format.

  • C"Never, under any circumstances, use markdown lists."

    Incorrect

    A stronger prohibition is still only a prohibition.

  • D"Avoid formatting you think the team would dislike."

    Incorrect

    This leaves the target to Claude's guess.

Tell Claude what to do instead of what not to do, and match the prompt's own style to the output you want.

Anthropic documentation

Task 4.1Report a problem with this question

Question 5 · choose 1

You have drafted new review criteria for your CI reviewer and want a quick check of whether they are clear before you try them on pull requests. What simple test does Anthropic's prompting guidance suggest?

  1. AAsk Claude to confirm that the criteria are clear
  2. BMark every rule IMPORTANT so that none of them is overlooked
  3. CShorten the criteria to a single sentence so that there is less to misread
  4. DCheck whether a colleague new to the task could follow them
Show the answer and why

  • AAsk Claude to confirm that the criteria are clear

    Incorrect

    Asking for confirmation invites agreement; it does not show where a reader new to the task would get lost.

  • BMark every rule IMPORTANT so that none of them is overlooked

    Incorrect

    Emphasis signals priority, not meaning; an unclear rule stays unclear in capitals.

  • CShorten the criteria to a single sentence so that there is less to misread

    Incorrect

    Cutting the criteria removes the specifics that make them precise.

  • DCheck whether a colleague new to the task could follow them

    Correct

    If a person with little context would be confused, Claude likely will be too.

The golden rule of clear prompting: show the prompt to a colleague with minimal context on the task and ask them to follow it. If they would be confused, Claude will be too.

Anthropic documentation

Task 4.1Report a problem with this question

Question 6 · choose 1

Your maintainability reviewer is told to "flag functions that are too long." Developers see functions of 25 lines flagged in one pull request and 120-line functions ignored in the next. What change makes the criterion precise?

  1. AAsk the reviewer to use its judgment about length more carefully
  2. BState a concrete threshold, such as more than 60 lines of logic
  3. CAsk for only the most egregious long functions
  4. DDrop the length check, since it is subjective
Show the answer and why

  • AAsk the reviewer to use its judgment about length more carefully

    Incorrect

    Judgment without a definition is what varies today.

  • BState a concrete threshold, such as more than 60 lines of logic

    Correct

    A measurable criterion produces the same decision every run.

  • CAsk for only the most egregious long functions

    Incorrect

    "Most egregious" is just as undefined.

  • DDrop the length check, since it is subjective

    Incorrect

    A defined threshold makes it objective.

Replace vague criteria with specific, measurable ones so classifications are consistent.

Anthropic documentation

Task 4.1Report a problem with this question

Question 7 · choose 1

Your team's documentation repository uses Code Review, and its default branch is protected. Most findings come back marked Important: a reworded sentence, a heading style, a long paragraph. Writers now skim past Important findings, and one about an install command that no longer works went unread. What should you change?

  1. AAsk an Owner to set the repository's review level to Quick so that reviews flag less
  2. BAdd a REVIEW.md with new severity rules to the branch of each pull request the writers open
  3. CMerge a REVIEW.md that limits Important to issues like broken commands and links, with everything else a Nit
  4. DAdd "report only findings you are highly confident about" to the project's CLAUDE.md
Show the answer and why

  • AAsk an Owner to set the repository's review level to Quick so that reviews flag less

    Incorrect

    The review level sets how thorough each review is, not which findings count as Important.

  • BAdd a REVIEW.md with new severity rules to the branch of each pull request the writers open

    Incorrect

    Code Review reads REVIEW.md from the base or default branch, never from the pull request's own changes.

  • CMerge a REVIEW.md that limits Important to issues like broken commands and links, with everything else a Nit

    Correct

    The default calibration targets production code; REVIEW.md can give a documentation repository a much narrower definition of Important, so the findings that matter stand out again.

  • DAdd "report only findings you are highly confident about" to the project's CLAUDE.md

    Incorrect

    Confidence wording does not say what Important means here, so style findings keep their label.

Explicit criteria cover severity as well as what gets reported. Code Review's default idea of Important is set for production code, and a documentation repository may want a much narrower one. State in REVIEW.md, merged to the protected default branch, which classes of finding are Important for this repository and which are only Nits.

Anthropic documentation

Task 4.1Report a problem with this question

Practise domain 4 →Practise all domains →