Lesson 2 of 5 in Prompt Engineering & Structured Output

3.2 · Few-shot, chain-of-thought, extended thinking

Three high-value prompt techniques with distinct use cases. Few-shot examples are the highest-leverage intervention for classification and format. CoT prompts a step-by-step reasoning trace. Extended thinking is a first-class model capability, not a prompt technique. This lesson covers when each fits.

Few-shot examples: show, don't tell

Two to five input/output examples wrapped in <example> tags consistently outperform paragraphs of instructions for format, tone, and edge-case handling. Cover the variation you expect in real inputs, especially the boundary cases.

<example>
  <input>Order #123 arrived damaged</input>
  <output>{'category': 'return', 'urgency': 'medium'}</output>
</example>

Chain of thought (CoT) via prompting

Ask the model to reason step by step inside <thinking> tags before producing the answer. Improves accuracy on complex reasoning at the cost of tokens and latency. Works because the model conditions its final answer on its own reasoning trace.

Extended thinking as a capability

Extended thinking is a built-in feature where the model reasons in a dedicated internal channel before responding. Different from your own <thinking> tags: it's a first-class API capability with its own token budget. Use for genuinely complex problems.

Good to know — Don't confuse extended thinking (a capability) with CoT prompting (a technique). Both work, but they're different levers.

When each is worth it

Few-shot: format, tone, edge cases — cheap and high-leverage. CoT: reasoning tasks where you want the model to slow down. Extended thinking: complex analysis where deeper internal reasoning improves quality. Combine as needed.

Takeaways

  • Examples beat instructions for format and edge cases
  • CoT is a prompt technique; extended thinking is a capability
  • Both cost tokens and latency — use where accuracy matters more
  • Cover boundary cases in your examples

Exam traps

Putting team standards in user-level CLAUDE.md
User-level is personal and lives on your machine only. Team standards go in project-level (./CLAUDE.md), checked into git.
Using directory-level CLAUDE.md when the rule spans many directories
Directory-level CLAUDE.md applies only when working IN that directory. For rules that span directories, use .claude/rules/ with glob frontmatter.
Bloating CLAUDE.md with encyclopedic reference material
It's read every turn. Every extra token costs money and dilutes attention. Write it as instructions to a senior engineer, not documentation.

Practice scenario

A monorepo has ./CLAUDE.md saying 'use 4-space indent' and ./services/api/CLAUDE.md saying 'use 2-space indent'. Inside ./services/api, which rule wins?

← PreviousNext →