Domain 1 — Prompting and Task Execution

CCA Associate Foundations course · Page 2 of 10 · ← Back to all courses · Weight: 14%. Mark this page complete at the bottom to advance your course progress.

1.1 — The Four-Part Prompt · Core

Every reliable prompt has four parts, always in this order: role → criteria → boundaries → output format.

• Role first — gives the model context before it reads the rules ("You are a technical editor reviewing API documentation").
• Testable criteria — a criterion is testable only if you could write a pass/fail check for it. "Cite the verbatim clause for each finding" is testable. "Be accurate" is not.
• Boundary statements — two parts, always together: the explicit prohibition, and the exact sentence to say when it's triggered. A boundary without a specified refusal response leaves Claude to improvise one differently every time.
• Output format last — the final shape constraint, once role and rules are already established.

Why order matters: when this order is scrambled — format before role, criteria before boundaries — the model has less context for each later instruction and fills gaps inconsistently.

⚠ Often-missed — Vague Hedges Don't Fix Noisy Categories · Gap

A prompt that over-flags issues gets "fixed" with "be more conservative" or "only flag high-confidence issues." This never works — a confidence hedge defines no categorical boundary, so the model still has no rule for what to skip. The real fix: explicit report/skip categories ("Report: logic bugs and security vulnerabilities. Skip: style preferences and formatting."). If a category is still noisy after that, temporarily disable it, rewrite its criteria with concrete examples, then re-enable it — don't stack more hedges on top.

1.2 — Task Decomposition · Core

Break a complex request into sub-tasks when: steps are sequential and an error early on propagates forward, different parts need different handling, or consistent depth is needed across many items (files, sections, records).

Each sub-task needs three things defined explicitly — input, output, and scope. Leave any one implicit and the model fills the gap differently on every run. A 40-page audit run as one instruction ("be thorough") gets uneven coverage; the fix is explicit per-section sub-tasks, not a longer or more emphatic instruction.

Multi-pass decomposition for large batches (e.g., reviewing 12+ files): a per-item local pass for consistent depth, then a separate integration pass for cross-item issues, and optionally a verification pass where the model self-reports confidence per finding to enable calibrated routing to human review.

1.3 — Chain-of-Thought: When It's Actually Justified · Core

Chain-of-thought (CoT) means asking Claude to reason step by step before its final answer. The trigger is sequential dependency and error propagation — never complexity alone. A financial calculation where step 2's output feeds step 3 needs CoT. A single-step classification into five categories, however nuanced, does not — each item is independent, so there's no error to propagate, and CoT only adds tokens and latency.

An explicit instruction beats a vague one every time: "First list your assumptions. Then evaluate each. Then conclude." is more reliable than "think carefully" — the vague version still leaves the model deciding what "careful" means.

1.4 — Iterating on a Prompt · Core

The progression is always zero-shot → few-shot → chain-of-thought, adding complexity only when evaluation results actually require it:

Every few-shot set needs a rejection example — a case that looks like it should trigger the behavior but shouldn't — or the examples silently bias the model toward the one pattern they show (four travel-expense examples teach the model to over-classify everything as travel).

Retrying a failed structured output: include the original input, the failed output, and the specific validation error — never just "try again." And know the limit: retries fix format and structural errors; they cannot conjure a value that's simply absent from the source document. If a field genuinely isn't in the document, stop retrying.

1.5 — Adapting Strategy to Task Type · Core

Leading phrasing narrows the answer before reasoning starts. "What's wrong with this plan?" presumes flaws exist. "Given that remote work reduces collaboration, what challenges does it create?" bakes the conclusion into the question. Both produce one-sided output on a task that was supposed to discover the answer, not assume it.

Attention placement: Claude attends most reliably to the beginning and end of a prompt; a constraint buried in the middle — between the role definition and a long document — gets applied inconsistently. Put critical instructions at the top, and reinforce them at the end.

Exam reflexes for Domain 1

• "Over-flagging, fix suggested is 'be more conservative'" → wrong; needs explicit report/skip categories.
• "Complex subject, but each item judged independently" → zero-shot, not CoT — no sequential dependency.
• "Errors compound step to step" → CoT is justified.
• "Format inconsistent, content is correct" → few-shot with the exact target format, not CoT.
• "Field is genuinely absent from the source, retries keep failing" → stop retrying; absence isn't fixable by retry.
• "Question presumes an answer before reasoning" → leading phrasing; rephrase neutrally.
• "Instruction buried in the middle of a long prompt" → move it to the top or reinforce at the end.