Sonnet 5.5 prompts for documents, slides and spreadsheets

A useful Sonnet 5.5 prompt specifies the deliverable, allowed evidence and the checks it must pass. Asking for a “professional presentation” leaves the model to invent too much. Give it source material, an audience and a definition of done, then verify the result before sharing it.

Anthropic’s release announcement identifies documents, slides and spreadsheets as intended strengths. The templates below are original editorial examples for those tasks. They are not transcripts of a successful Sonnet run or proof of model performance: our attempted Claude Code access was blocked by organization policy. Use them as starting points and test with your own approved account.

Prepare a source packet

Keep a short, explicit packet containing the audience, objective, source facts, unresolved questions and output format. Label invented practice data as synthetic. For business material, remove sensitive data unless your organization’s approved model access permits that use.

A text response, a rendered file and a checked deliverable are different stages. The Sonnet model specification describes text and image input with text output. Creating an actual PPTX or XLSX file depends on the surrounding application, tools and permissions. Do not promise file creation merely because a chat response contains a slide outline.

Template 1: a one-page decision brief

Use this when you need a decision document from supplied notes. Replace the bracketed fields before running it.

Create a one-page decision brief for [audience].
Decision to support: [decision].
Use only the source packet below. Do not invent numbers, customer quotes,
product capabilities or dates. Mark unsupported items as "needs evidence".

Return:
1. Recommendation, explicitly separated from source facts.
2. Three decision criteria and how the available evidence addresses them.
3. Main risks and unresolved questions.
4. Next action, owner placeholder and date placeholder.
5. A claim-to-source table referencing source IDs.

Keep the brief within 500 words. If the sources conflict, preserve the
conflict rather than silently choosing one. Source packet: [paste sources].

The 500-word limit is a formatting target, not a guarantee of compliance. Check the word count and verify each source ID. A polished recommendation can still be unsupported. If there is not enough evidence to make the decision, an honest list of missing information is a useful output.

For review, underline each factual assertion and trace it to the supplied packet. Separate “the notes state this” from “the model recommends this.” A recommendation can be reasonable without becoming an established fact.

Template 2: a six-slide presentation outline

This prompt produces an outline that a presentation tool or editor can turn into slides. It does not claim native video or slide-file generation.

Turn the approved brief below into a six-slide outline for [audience].
The presentation's goal is [one decision or action].
Use only the approved brief; do not add market statistics.

For each slide return: title, one main message, up to three supporting
points, suggested visual, speaker notes and source IDs.
Use this sequence: problem, evidence, options, recommendation, risks,
next steps. Mark any missing visual or missing evidence explicitly.
Avoid repeating the same paragraph on every slide.
Approved brief: [paste the checked brief].

Inspect the outline in presentation order. Each slide should have one message and advance the decision. Check whether the suggested chart has real supporting data; a chart instruction is not a dataset. A screenshot suggestion must use a real permitted screenshot, not an invented interface.

After rendering slides with your chosen tools, inspect layout and text overflow at the actual presentation size. Review speaker notes separately from visible text, because notes can introduce unsupported claims that never appear on the slide itself. Exporting a file is not the final quality check.

Template 3: review a small spreadsheet

For a controlled practice task, use a CSV with columns item, quantity and unit_price. Keep currency and units in the task description. The following prompt asks for an auditable calculation rather than an attractive narrative.

Review this CSV as a small USD expense table.
Columns: item, quantity, unit_price. Treat quantity as a count and
unit_price as USD per item. Do not fill missing values silently.

Return:
1. Validation issues, including missing, negative or nonnumeric values.
2. Each valid row's quantity × unit_price.
3. The sum of valid rows, with excluded rows listed separately.
4. The exact formula or short reproducible script used.
5. A distinction between source values and calculated values.

Do not claim the total is verified unless it has been independently
recalculated. CSV: [paste a non-sensitive CSV].

A simple practice packet is: 3 notebooks at $4.50 each, 2 pens at $1.25 each, and 1 folder at $2.00. Independent arithmetic gives $13.50 + $2.50 + $2.00 = $18.00. These are synthetic teaching values, not customer spending data or a Sonnet-generated result.

Check row-level values before checking the grand total. Two incorrect rows can accidentally cancel out. For money, use decimal-safe arithmetic in the independent checker and define how rounding works. Large sheets also require care around hidden rows, formulas and units; a pasted CSV does not preserve every feature of the original workbook.

A complete practice packet for all three deliverables

Use one shared packet so the brief, slides and spreadsheet cannot quietly drift into different stories. The following packet is wholly synthetic. It describes a small training workshop, not an Ofox customer event or a model-generated business case. Paste it after the relevant template, replacing its source placeholder.

S1 — Objective: prepare a two-hour internal workshop for six participants.
The decision is whether to approve a stationery purchase capped at USD 20.
S2 — Confirmed purchase list:
item,quantity,unit_price
notebook,3,4.50
pen,2,1.25
folder,1,2.00
S3 — Prices are USD per item. Quantities are item counts. The supplier
has not confirmed tax or delivery charges. No discounts are confirmed.
S4 — The workshop date and purchasing owner have not been assigned.
The purchase needs approval before ordering; approval has not occurred.
S5 — These materials are a shared set. No source establishes that every
participant receives one of every item. Do not invent that allocation.

The known goods subtotal is $18.00. The remaining $2.00 under the cap is not confirmed savings and is not enough evidence that the final invoice will be within budget: tax and delivery remain unknown. Six participants does not justify multiplying every quantity by six, and three notebooks does not prove that three people lack a notebook. Those are exactly the kinds of plausible additions the source boundary should prevent.

This packet supplies enough evidence for a conditional recommendation, not an unconditional purchase approval. A responsible brief can recommend asking the supplier for the final total and assigning an owner before approval. It cannot truthfully state that the order was placed, that the budget is sufficient after tax, or that the event date is fixed.

What an acceptable decision brief contains

Add this output contract to Template 1 when using the workshop packet:

Use the headings Decision, Known facts, Calculation, Conditions, Next action.
Show goods subtotal USD 18.00 and remaining cap USD 2.00, labeled as
calculated values. Mark tax, delivery, owner and date as unknown.
Do not authorize a purchase or imply all six people have individual kits.
In the source table, cite S2/S3 for costs and S4 for approval status.
If the final total cannot be established, make the recommendation conditional.

These values are editorial target checks derived from the packet, not a captured Sonnet answer. Read the recommendation and its qualifiers together. “Approve the $18 purchase” loses the unresolved final-total condition; “request a final quote before approval” preserves it. If the brief cites S1 for tax being zero, the source ID exists but the citation is still wrong. Citation presence and citation support are separate checks.

A useful revision request identifies the precise defect: “The brief treats $18 as the final invoice, but S3 leaves tax and delivery unknown. Revise that sentence and every dependent recommendation; keep the known subtotal.” This is better than asking the model to “be more accurate,” because it preserves valid work while correcting the actual unsupported inference.

Turn the approved brief into six distinct slides

For this practice packet, use the following editorial storyboard as an acceptance reference. It is an outline, not a rendered deck or a claim about Sonnet’s output.

Do not draw a pie chart that distributes the materials among six participants; the packet has no allocation data. A simple cost table communicates the known facts more accurately. If a chart is used, label USD consistently and ensure its bars come from the same row totals rather than from quantities alone.

Once a presentation tool creates the deck, inspect all six slides at presentation size. Check clipping, small labels, table readability and whether the title still matches the slide’s actual evidence. Inspect notes too: a clean visible slide can still carry invented claims in its speaker notes. If a slide overflows, shorten presentation text while preserving qualifications in readable notes; do not solve layout by deleting “tax and delivery unknown.”

Verify the spreadsheet with explicit row formulas

A worksheet version can use A1:C4 for the three source columns, D1 as line_total, D2 as =B2*C2, copied to D3:D4, and D5 as =SUM(D2:D4). The expected cells are D2=13.50, D3=2.50, D4=2.00 and D5=18.00. Put currency in the heading or format; do not mix strings such as $4.50 with numeric values without an explicit import rule.

Define invalid-data handling before calculation. A blank quantity must not become zero silently. A nonnumeric unit price must be flagged, and a negative row must follow an explicit return/refund rule rather than being accepted as an ordinary purchase. If you exclude invalid rows, label the result “subtotal of valid rows” and list exclusions; it is not the final purchase total.

For this sample, decimal-safe independent arithmetic is short:

from decimal import Decimal
rows = [(3, "4.50"), (2, "1.25"), (1, "2.00")]
line_totals = [Decimal(q) * Decimal(p) for q, p in rows]
assert line_totals == [Decimal("13.50"), Decimal("2.50"), Decimal("2.00")]
assert sum(line_totals) == Decimal("18.00")
print("Verified synthetic goods subtotal: USD 18.00")

Running this verifies only the known synthetic goods arithmetic. It does not verify taxes, supplier prices or a generated workbook’s formulas. For an actual workbook, inspect the formulas and recalculate in a spreadsheet application; a library that reads cached values can show stale totals. Preserve the original source sheet so a reviewer can distinguish supplied quantities from calculated amounts.

Repair defects at the stage where they arise

If the brief invents a date, fix the brief before generating slides from it. If slides change the subtotal to $20 merely because that is the budget cap, correct the slide’s source interpretation and recheck any charts or notes. If a spreadsheet sums unit prices to $7.75 instead of multiplying quantities, repair row formulas before rewriting the narrative around that total.

Keep three deliverable statuses: drafted, independently checked and ready to share. A downloaded file establishes none of the last two by itself. Record which source packet version each artifact used, the corrections made and which person or checker accepted it. This lets you reuse a verified packet across documents without propagating an attractive but unsupported claim.

Download and evaluate the templates

Download the original prompt pack and synthetic CSV. The pack contains editorial templates and an independently checked calculation, not model-generated finished documents. Keep the unedited source packet with your output so someone else can repeat the review.

For each deliverable, record the requested format, missing evidence, factual corrections and time spent editing. If you compare effort settings, use the same packet and review criteria. See the Sonnet effort guide and API cost guide before interpreting speed or cost differences.