DEV Community

Prompting Anthropic v5 for Cloud Engineers: Practical Rules for Sonnet 5, Open 5, and Fable 5.1

Here's a thinking process:

  1. Analyze User Input:

    • Title: "Prompting Anthropic v5 for Cloud Engineers: Practical Rules for Sonnet 5, Open 5, and Fable 5.1"
    • Article: A wall of text with formatting issues, mixed quotes, rules, etc.
    • Task: Reformatted into clean, readable Markdown for a technical audience.
    • Rules:
    • Break into short, well-structured paragraphs separated by blank lines.
    • Add Markdown section headings (## Heading) where topic clearly shifts.
    • Use bullet/numbered lists for enumerations, inline code or fenced code blocks for code/commands/identifiers.
    • Preserve every fact, name, number, quotation exactly as given. Never invent, add, remove, or reorder information.
    • Only restructure and lightly polish wording for flow and grammar; no intro, conclusion, opinion, or commentary.
    • Do not repeat the article title as a heading and do not wrap the whole answer in a code fence.
    • Output only the reformatted article body as Markdown, nothing else.
  2. Deconstruct the Article Text:
    The article text is:

    Title: Prompting Anthropic v5 for Cloud Engineers: Practical Rules for Sonnet 5, Open 5, and Fable 5.1
    

Article:
With each new model generation, Anthropic updates its prompting best practices, and the 5th generation is no exception. This post distils the practical guidance from Anthropic’s documentation into actionable rules for Sonnet 5, Open 5, and Fable 5.1, focused on cloud engineering workflows. Rules for every current model Give the reason, not just the rule The model will use the why or the reason to generalise and find an answer on what wasn’t present in the prompt. Don’t do : Don't use Write-Host in the script. Do : Don't use Write-Host: this script runs as an Azure DevOps pipeline task where only the streams are captured, and Write-Host output is invisible in the job log. Write the output contract explicitly The model has no idea of your convention and format. Don’t do : Write me a PowerShell function to get ExpressRoute circuit status. Do : Write a PowerShell 7 function Get-ErCircuitHealth. Contract: [CmdletBinding()], approved Verb-Noun, singular noun, comment-based help with at least one .EXAMPLE Accepts -SubscriptionId (mandatory, ValidateNotNullOrEmpty) and -ResourceGroupName (optional); pipeline input by property name - Emits one [PSCustomObject] per circuit: CircuitName, ServiceProviderProvisioningState, CircuitProvisioningState, PeeringLocation, BandwidthInMbps. No formatted text, no Write-Host try/catch with -ErrorAction Stop inside the try; rethrow with context, never an empty catch Filter server-side via Az cmdlet parameters, not | Where-Object after the fact Show examples instead of describing style Using 3-5 examples help the model to get what you want. Use Don’t do : Write Azure Policy definitions in our usual style. Do : Write an Azure Policy definition that denies public network access on Storage accounts. Match the conventions in these examples - note that they cover deny, audit and deployIfNotExists, and both a single-condition and an allOf policyRule: { ...our existing deny-public-ip policy JSON... } { ...our existing audit-diagnostic-settings policy JSON... } { ...our existing deployIfNotExists policy JSON... } State what to do, not what to avoid a prohibition describes a space to stay out of; an instruction describes where to go. Don’t do : Don't use hardcoded values. Do : Every environment-varying value comes from a variable with a type constraint and a description; defaults only where a sane default genuinely exists. In long context, documents first, question after Anthropic measured up to a 30% quality improvement from putting the query after multi-document inputs. Don’t do : Which of our landing zone modules still create NSG rules with source ? Do : XXX . Before answering, quote the specific resource blocks that are relevant to the question. Then: which of these modules still create NSG rules with source "", and which line in each? Cap the complexity explicitly The instruction that works is a ceiling, not a vague plea for simplicity Don’t do : Keep it simple. Add a retry to this Az module call. Do : Add a retry with exponential backoff to this Az module call. Scope: this call only. Don't refactor the surrounding function, don't extract a generic retry helper, don't add a config file for the retry count, and don't add validation for states that can't occur Specific rules for Opus 5 Delete your verification scaffolding Opus 5 verifies its own work unprompted. Instructions to verify stack on top of built-in behaviour and produce over-verification. Don’t do : After writing the Terraform module, include a final verification step. Re-check your work before responding. Do : Write the Terraform module Soften the tool language you inherited older models were lazy when calling tools, this is not the case with Opus 5 Don’t do: CRITICAL: You MUST call get_policy_assignments whenever the user mentions policy. NEVER answer policy questions from memory. ALWAYS verify with the tool first. Do : Use get_policy_assignments when you need the current assignment state for a specific scope. Answer conceptual questions about how Azure Policy works directly. Specific rules for Sonnet 5 Fix shallow reasoning with effort Sonnet 5 respects effort strictly, especially at the low end. At low and medium it scopes work to exactly what was asked and does not go above and beyond Don’t do : [effort: low] Think step by step. Be extremely thorough. Consider all edge cases. Analyze deeply before answering: why does the route propagation fail between these two vWAN hubs but not the third? Do : [effort: high - or xhigh for the hardest agentic and coding work] Why does route propagation fail between these two vWAN hubs but not the third? Specific rules for Fable 5 Draw the line between assessment and action Fable 5 can take unrequested actions Don’t do : The ExpressRoute peering keeps dropping on the secondary connection. Route table looks wrong to me. Do : The ExpressRoute peering keeps dropping on the secondary connection. Route table looks wrong to me. I'm describing a problem, not requesting a change: the deliverable is your assessment. Investigate and report findings, then stop. Don't apply a fix until I ask. Before proposing any command that changes state; resetting a peering, editing a route table, restarting a gateway, check that the evidence actually supports that specific action rather than a failure mode it resembles. never instruct it to echo, transcribe or explain its internal reasoning That will trigger the reasoning_extraction refusal category and may stop the session. You can get the full reference here
With each new model generation, Anthropic updates its prompting best practices, and the 5th generation is no exception. This post distils the practical guidance from Anthropic’s documentation into actionable rules for Sonnet 5, Open 5, and Fable 5.1, focused on cloud engineering workflows. Rules for every current model Give the reason, not just the rule The model will use the why or the reason to generalise and find an answer on what wasn’t present in the prompt. Don’t do: Don't use Write-Host in the script. Do: Don't use Write-Host: this script runs as an Azure DevOps pipeline task where only the streams are captured, and Write-Host output is invisible in the job log. Write the output contract explicitly The model has no idea of your convention and format. Don’t do: Write me a PowerShell function to get ExpressRoute circuit status. Do: Write a PowerShell 7 function Get-ErCircuitHealth. Contract: - [CmdletBinding()], approved Verb-Noun, singular noun, comment-based help with at least one .EXAMPLE - Accepts -SubscriptionId (mandatory, ValidateNotNullOrEmpty) and -ResourceGroupName (optional); pipeline input by property name - Emits one [PSCustomObject] per circuit: CircuitName, ServiceProviderProvisioningState, CircuitProvisioningState, PeeringLocation, BandwidthInMbps. No formatted text, no Write-Host - try/catch with -ErrorAction Stop inside the try; rethrow with context, never an empty catch - Filter server-side via Az cmdlet parameters, not | Where-Object after the fact Show examples instead of describing style Using 3-5 examples help the model to get what you want. Use Don’t do: Write Azure Policy definitions in our usual style. Do: Write an Azure Policy definition that denies public network access on Storage accounts. Match the conventions in these examples - note that they cover deny, audit and deployIfNotExists, and both a single-condition and an allOf policyRule: { ...our existing deny-public-ip policy JSON... } { ...our existing audit-diagnostic-settings policy JSON... } { ...our existing deployIfNotExists policy JSON... } State what to do, not what to avoid a prohibition describes a space to stay out of; an instruction describes where to go. Don’t do: Don't use hardcoded values. Do: Every environment-varying value comes from a variable with a type constraint and a description; defaults only where a sane default genuinely exists. In long context, documents first, question after Anthropic measured up to a 30% quality improvement from putting the query after multi-document inputs. Don’t do: Which of our landing zone modules still create NSG rules with source ? Do: XXX . Before answering, quote the specific resource blocks that are relevant to the question. Then: which of these modules still create NSG rules with source "", and which line in each? Cap the complexity explicitly The instruction that works is a ceiling, not a vague plea for simplicity Don’t do: Keep it simple. Add a retry to this Az module call. Do : Add a retry with exponential backoff to this Az module call. Scope: this call only. Don't refactor the surrounding function, don't extract a generic retry helper, don't add a config file for the retry count, and don't add validation for states that can't occur Specific rules for Opus 5 Delete your verification scaffolding Opus 5 verifies its own work unprompted. Instructions to verify stack on top of built-in behaviour and produce over-verification. Don’t do: After writing the Terraform module, include a final verification step. Re-check your work before responding. Do: Write the Terraform module Soften the tool language you inherited older models were lazy when calling tools, this is not the case with Opus 5 Don’t do: CRITICAL: You MUST call get_policy_assignments whenever the user mentions policy. NEVER answer policy questions from memory. ALWAYS verify with the tool first. Do: Use get_policy_assignments when you need the current assignment state for a specific scope. Answer conceptual questions about how Azure Policy works directly. Specific rules for Sonnet 5 Fix shallow reasoning with effort Sonnet 5 respects effort strictly, especially at the low end. At low and medium it scopes work to exactly what was asked and does not go above and beyond Don’t do: [effort: low] Think step by step. Be extremely thorough. Consider all edge cases. Analyze deeply before answering: why does the route propagation fail between these two vWAN hubs but not the third? Do: [effort: high - or xhigh for the hardest agentic and coding work] Why does route propagation fail between these two vWAN hubs but not the third? Specific rules for Fable 5 Draw the line between assessment and action Fable 5 can take unrequested actions Don’t do : The ExpressRoute peering keeps dropping on the secondary connection. Route table looks wrong to me. Do : The ExpressRoute peering keeps dropping on the secondary connection. Route table looks wrong to me. I'm describing a problem, not requesting a change: the deliverable is your assessment. Investigate and report findings, then stop. Don't apply a fix until I ask. Before proposing any command that changes state; resetting a peering, editing a route table, restarting a gateway, check that the evidence actually supports that specific action rather than a failure mode it resembles. never instruct it to echo, transcribe or explain its internal reasoning That will trigger the reasoning_extraction refusal category and may stop the session. You can get the full reference here


Wait, the user input actually has two sections: "Title:" and "Article:" but the prompt says "Do not repeat the article title as a heading and do not wrap the whole answer in a code fence." The output should be just the reformatted article body. The title is given but I shouldn't output it as a heading. I'll just output the reformatted article content.

Let me carefully read and re-structure the article text. I need to preserve every fact, name, number, quotation exactly. I need to identify topic shifts and add ## headings.

The article seems to have duplicate content (appears twice almost verbatim). The first block is the main article, then at the end there's "With each new model generation..." again, then "Top comments (1) ..." which seems like comment section but the rules say preserve every fact, name, number, quotation exactly. However, the prompt says "You are given the raw body of a news article that arrived as an undifferentiated wall of text. Reformat it into clean, readable Markdown for a technical audience." and "Output only the reformatted article body as Markdown, nothing else." The "Top comments (1)" might be part of the article or maybe not. I need to check.

Looking at the structure: 
- Starts with "Title: ..."
- Then "Article:" 
- Then a big block of text
- Then "With each new model generation..." again
- Then "Top comments (1) ..."

The prompt says: "You are given the raw body of a news article that arrived as an undifferentiated wall of text." So I should treat the whole thing after "Article:" as the article body, or maybe the whole input excluding the "Title:" line? The prompt says "Do not repeat the article title as a heading". So I should not output the title. I'll output the reformatted article body, which includes everything after the title, but I need to figure out where the article body starts. The input has "Article:" then the text. I'll assume the article body is everything from "Article:" onwards, or maybe just the text block. To be safe, I'll output the reformatted content starting from the content after "Article:", but the prompt says "do not repeat the article title as a heading". I'll just output the Markdown reformatted version of the article content, excluding the "Title:" line itself, but including everything else.

Actually, re-reading: "You are given the raw body of a news article that arrived as an undifferentiated wall of text. Reformat it into clean, readable Markdown for a technical audience." Then they give "Title: ... Article: ...". So the "raw body" likely includes both the title and article, but the instruction says "Do not repeat the article title as a heading and do not wrap the whole answer in a code fence." So I should output the reformatted article body, not including the title as a heading. I could either omit the title entirely, or include it but not as a heading. But the prompt says "Output only the reformatted article body as Markdown, nothing else." So I should output only the article body, reformatted. The "Article:" prefix might be part of the metadata. I'll treat the entire input after the title line as the article body, but I need to see where the actual content starts. Looking at the input format:

Title: Prompting Anthropic v5 for Cloud Engineers: Practical Rules for Sonnet 5, Open 5, and Fable 5.1

Article:
With each new model generation...


I think the "Article:" is a label, and the text follows. I'll output the reformatted text starting from "With each new model generation...". But the "Top comments (1)" at the very end might be part of the article or a separate section. The prompt says "Preserve every fact, name, number, and quotation exactly as given." So I should include everything that's in the article body, including the comments if they're part of the given text. However, the prompt also says "Reformat it into clean, readable Markdown for a technical audience." and "Output only the reformatted article body as Markdown, nothing else." I'll include everything from "Article:" onwards, but since "Article:" is likely a marker, I'll start the Markdown from the first word of the article content.

Let me parse the article content carefully. It's a set of rules for different Anthropic models. The text has recurring sections. I need to restructure it with headings, paragraphs, lists, etc., while preserving all facts exactly.

I'll go through the text and identify logical sections/topics. The rules are categorized by model: Opus 5, Sonnet 5, Fable 5 (and mention Open 5, Fable 5.1). There are also general rules that apply to "every current model".

Let me outline the content flow as I see it:

- Intro/overview sentence: "With each new model generation, Anthropic updates its prompting best practices, and the 5th generation is no exception. This post distils the practical guidance from Anthropic’s documentation into actionable rules for Sonnet 5, Open 5, and Fable 5.1, focused on cloud engineering workflows."
- "Rules for every current model" section maybe?
- Then a series of rules with "Don't do" and "Do" pairs, covering:
  1. Give the reason, not just the rule
  2. Write the output contract explicitly (PowerShell example)
  3. Show examples instead of describing style
  4. State what to do, not what to avoid
  5. Don't use hardcoded values
  6. In long context, documents first, question after
  7. Cap the complexity explicitly
- Then specific rules for Opus 5:
  - Delete your verification scaffolding
  - Soften the tool language
- Specific rules for Sonnet 5:
  - Fix shallow reasoning with effort
- Specific rules for Fable 5:
  - Draw the line between assessment and action
  - Never instruct it to echo, transcribe or explain its internal reasoning
- Then there's a "Top comments (1)" section which seems like user comments, but the prompt says "Preserve every fact, name, number, and quotation exactly as given." I need to decide if I include it. The prompt says "Output only the reformatted article body as Markdown, nothing else." The "Top comments" might be considered part of the article body if it's included in the raw text. But typically, article body doesn't include comment sections unless specified. However, the raw text includes it, and the instruction says preserve every fact, name, number, quotation exactly. I'll include it as part of the article, but format it appropriately, maybe as a blockquote or separate section. But the prompt says "do not add an introduction, conclusion, opinion, or commentary of your own." Including the comments as-is might be okay if I just format them. But the comment says: `"Give the reason, not just the rule" is the one that earns its place, and the Write-Host example is a good illustration...` This is user commentary. I'm unsure. Let me re-read the prompt: "You are given the raw body of a news article that arrived as an undifferentiated wall of text. Reformat it into clean, readable Markdown for a technical audience." Then they give rules, and then "Article: [text]". The text includes "Top comments (1) ..." at the very end. I think I should include it as part of the reformatted article, but structure it maybe as a "Comments" section with a heading, or just integrate it. However, the prompt also says "Do not repeat the article title as a heading and do not wrap the whole answer in a code fence." It doesn't say "exclude comments". I'll treat the entire text after "Article:" as the article body, including the comments, and reformatted it all.

But wait, the very last line is "You can get the full reference here" which appears twice. The text has duplication. Let me carefully copy the exact text and identify unique parts.

Let me re-examine the input text as provided by the user:

Title: Prompting Anthropic v5 for Cloud Engineers: Practical Rules for Sonnet 5, Open 5, and Fable 5.1

Article:
With each new model generation, Anthropic updates its prompting best practices, and the 5th generation is no exception. This post distils the practical guidance from Anthropic’s documentation into actionable rules for Sonnet 5, Open 5, and Fable 5.1, focused on cloud engineering workflows. Rules for every current model Give the reason, not just the rule The model will use the why or the reason to generalise and find an answer on what wasn’t present in the prompt. Don’t do : Don't use Write-Host in the script. Do : Don't use Write-Host: this script runs as an Azure DevOps pipeline task where only the streams are captured, and Write-Host output is invisible in the job log. Write the output contract explicitly The model has no idea of your convention and format. Don’t do : Write me a PowerShell function to get ExpressRoute circuit status. Do : Write a PowerShell 7 function Get-ErCircuitHealth. Contract: [CmdletBinding()], approved Verb-Noun, singular noun, comment-based help with at least one .EXAMPLE Accepts -SubscriptionId (mandatory, ValidateNotNullOrEmpty) and -ResourceGroupName (optional); pipeline input by property name - Emits one [PSCustomObject] per circuit: CircuitName, ServiceProviderProvisioningState, CircuitProvisioningState, PeeringLocation, BandwidthInMbps. No formatted text, no Write-Host try/catch with -ErrorAction Stop inside the try; rethrow with context, never an empty catch Filter server-side via Az cmdlet parameters, not | Where-Object after the fact Show examples instead of describing style Using 3-5 examples help the model to get what you want. Use Don’t do : Write Azure Policy definitions in our usual style. Do : Write an Azure Policy definition that denies public network access on Storage accounts. Match the conventions in these examples - note that they cover deny, audit and deployIfNotExists, and both a single-condition and an allOf policyRule: { ...our existing deny-public-ip policy JSON... } { ...our existing audit-diagnostic-settings policy JSON... } { ...our existing deployIfNotExists policy JSON... } State what to do, not what to avoid a prohibition describes a space to stay out of; an instruction describes where to go. Don’t do : Don't use hardcoded values. Do : Every environment-varying value comes from a variable with a type constraint and a description; defaults only where a sane default genuinely exists. In long context, documents first, question after Anthropic measured up to a 30% quality improvement from putting the query after multi-document inputs. Don’t do : Which of our landing zone modules still create NSG rules with source ? Do : XXX . Before answering, quote the specific resource blocks that are relevant to the question. Then: which of these modules still create NSG rules with source "", and which line in each? Cap the complexity explicitly The instruction that works is a ceiling, not a vague plea for simplicity Don’t do : Keep it simple. Add a retry to this Az module call. Do : Add a retry with exponential backoff to this Az module call. Scope: this call only. Don't refactor the surrounding function, don't extract a generic retry helper, don't add a config file for the retry count, and don't add validation for states that can't occur Specific rules for Opus 5 Delete your verification scaffolding Opus 5 verifies its own work unprompted. Instructions to verify stack on top of built-in behaviour and produce over-verification. Don’t do : After writing the Terraform module, include a final verification step. Re-check your work before responding. Do : Write the Terraform module Soften the tool language you inherited older models were lazy when calling tools, this is not the case with Opus 5 Don’t do: CRITICAL: You MUST call get_policy_assignments whenever the user mentions policy. NEVER answer policy questions from memory. ALWAYS verify with the tool first. Do : Use get_policy_assignments when you need the current assignment state for a specific scope. Answer conceptual questions about how Azure Policy works directly. Specific rules for Sonnet 5 Fix shallow reasoning with effort Sonnet 5 respects effort strictly, especially at the low end. At low and medium it scopes work to exactly what was asked and does not go above and beyond Don’t do : [effort: low] Think step by step. Be extremely thorough. Consider all edge cases. Analyze deeply before answering: why does the route propagation fail between these two vWAN hubs but not the third? Do : [effort: high - or xhigh for the hardest agentic and coding work] Why does route propagation fail between these two vWAN hubs but not the third? Specific rules for Fable 5 Draw the line between assessment and action Fable 5 can take unrequested actions Don’t do : The ExpressRoute peering keeps dropping on the secondary connection. Route table looks wrong to me. Do : The ExpressRoute peering keeps dropping on the secondary connection. Route table looks wrong to me. I'm describing a problem, not requesting a change: the deliverable is your assessment. Investigate and report findings, then stop. Don't apply a fix until I ask. Before proposing any command that changes state; resetting a peering, editing a route table, restarting a gateway, check that the evidence actually supports that specific action rather than a failure mode it resembles. never instruct it to echo, transcribe or explain its internal reasoning That will trigger the reasoning_extraction refusal category and may stop the session. You can get the full reference here

With each new model generation, Anthropic updates its prompting best practices, and the 5th generation is no exception. This post distils the practical guidance from Anthropic’s documentation into actionable rules for Sonnet 5, Open 5, and Fable 5.1, focused on cloud engineering workflows. Rules for every current model Give the reason, not just the rule The model will use the why or the reason to generalise and find an answer on what wasn’t present in the prompt. Don’t do: Don't use Write-Host in the script. Do: Don't use Write-Host: this script runs as an Azure DevOps pipeline task where only the streams are captured, and Write-Host output is invisible in the job log. Write the output contract explicitly The model has no idea of your convention and format. Don’t do: Write me a PowerShell function to get ExpressRoute circuit status. Do: Write a PowerShell 7 function Get-ErCircuitHealth. Contract: - [CmdletBinding()], approved Verb-Noun, singular noun, comment-based help with at least one .EXAMPLE - Accepts -SubscriptionId (mandatory, ValidateNotNullOrEmpty) and -ResourceGroupName (optional); pipeline input by property name - Emits one [PSCustomObject] per circuit: CircuitName, ServiceProviderProvisioningState, CircuitProvisioningState, PeeringLocation, BandwidthInMbps. No formatted text

Read on DEV Community ↗ ← Back to News

Comments

No comments yet. Start the discussion.