Step-by-Step Instructions

Why Order Matters

The order in which you ask a model to analyze information significantly affects results. Just like humans, models reason better when they build understanding progressively.

From Anthropic's workshop:

> "The order in which Claude analyzes information is very important. You would probably not look at the drawing first and try to understand what was going on, right? But if we have the form and can read it first, then we know more about how to understand what might be in the drawing."

The Reasoning Sequence

Bad Order (Context After)

Look at this sketch and tell me what happened.
Then check the accident form.
Determine fault.

Good Order (Context First)

1. First, examine the accident form checkboxes
2. List which boxes are checked for each vehicle
3. Then, look at the sketch
4. Interpret the sketch based on what you learned from the form
5. Finally, determine fault with supporting evidence

Instruction Design Patterns

Pattern 1: Gather → Analyze → Conclude

<instructions>
  <step number="1" phase="gather">
    Read the entire document carefully.
    Identify all key facts and data points.
    List them for reference.
  </step>

  <step number="2" phase="analyze">
    For each fact, consider its relevance.
    Look for patterns and connections.
    Note any inconsistencies or gaps.
  </step>

  <step number="3" phase="conclude">
    Based on your analysis, form a conclusion.
    Support it with specific evidence.
    Address any uncertainties.
  </step>
</instructions>

Pattern 2: Chunk by Data Source

<instructions>
  <step number="1" source="form">
    Examine the accident form carefully.
    For each of the 17 rows, note if checked for Vehicle A or B.
    Create a list of checked items.
  </step>

  <step number="2" source="sketch">
    Now examine the hand-drawn sketch.
    Using your understanding from the form, interpret:
    - Vehicle positions
    - Direction of travel
    - Point of impact
  </step>

  <step number="3" source="synthesis">
    Combine information from both sources.
    Determine fault based on traffic laws.
    Cite specific evidence.
  </step>
</instructions>

Pattern 3: Verify as You Go

<instructions>
  <step number="1">
    Read checkbox row 1-5 for both vehicles.
    List what you find.
  </step>

  <step number="2">
    Verify: Do your findings make sense?
    If unclear, note the uncertainty.
  </step>

  <step number="3">
    Continue with rows 6-10.
    List what you find.
  </step>

  <step number="4">
    Verify: Is this consistent with earlier findings?
  </step>

  <!-- Continue pattern -->
</instructions>

The Car Accident Implementation

Here's how Anthropic structured the accident analysis:

<detailed_instructions>
  <step number="1">
    Carefully examine the accident form image.
    For EACH of the 17 rows:
    - Check if Vehicle A has that box marked
    - Check if Vehicle B has that box marked
    - Note the exact marking (X, checkmark, circle)
    List your findings.
  </step>

  <step number="2">
    Based on the checked boxes, describe what each vehicle
    was doing at the time of the accident.
    Use the row definitions provided earlier.
  </step>

  <step number="3">
    Now examine the hand-drawn sketch.
    With your understanding of vehicle actions:
    - Identify which shape is Vehicle A
    - Identify which shape is Vehicle B
    - Trace the path of each vehicle
    - Identify the collision point
  </step>

  <step number="4">
    Synthesize your findings:
    - Summarize what happened
    - Determine which vehicle is at fault
    - Cite specific checkbox evidence
    - Reference the sketch interpretation
  </step>
</detailed_instructions>

Controlling Verbosity

Step-by-step instructions can make output verbose. Control this:

Show Work (for debugging)

<instructions>
  For each step, show your reasoning.
  This helps verify your analysis is correct.
</instructions>

Concise Output (for production)

<instructions>
  Follow these steps internally.
  Only include the final analysis in your response.
</instructions>

Selective Showing

<instructions>
  <step show_work="false">Examine checkboxes silently</step>
  <step show_work="true">Describe vehicle actions</step>
  <step show_work="false">Analyze sketch silently</step>
  <step show_work="true">Present final conclusion</step>
</instructions>

When to Use Step-by-Step

Common Mistakes

1. Steps Too Vague

❌ "Analyze the document"
✓ "Read each checkbox row and note which are marked"

2. Missing Dependency Order

❌ Steps that could be done in any order
✓ Each step builds on previous findings

3. Too Many Steps

❌ 20 micro-steps that confuse
✓ 3-5 clear phases with sub-tasks

4. No Verification Steps

❌ Just gather and conclude
✓ Include "verify your findings make sense" steps

Step-by-Step for Code Tasks

<instructions>
  <step number="1" name="understand">
    Read the existing code completely.
    Identify the current implementation approach.
    Note any patterns or conventions used.
  </step>

  <step number="2" name="plan">
    Before making changes:
    - List what needs to change
    - Identify potential impacts
    - Consider edge cases
  </step>

  <step number="3" name="implement">
    Make the changes following existing patterns.
    Keep changes minimal and focused.
  </step>

  <step number="4" name="verify">
    Review your changes:
    - Does it compile/run?
    - Are edge cases handled?
    - Is it consistent with the codebase?
  </step>
</instructions>

Key Takeaways

• Order matters - Build understanding progressively
• Context before analysis - Read background first
• Explicit steps - Don't assume the model will figure out order
• Control verbosity - Show work for debugging, hide for production
• Verify along the way - Include sanity check steps

Next Lesson

Next, we'll explore Output Formatting - how to structure model responses for reliable parsing and downstream use.