👁️ Fable 5 sees the screen, not just the text
🧠 Imagine it this way: you ask a conversion designer to look at your screenshot and just say "make it prettier." They’ll change the button color and stop there. Now imagine you say, "tell me where the eye goes first, what’s confusing, and what’s costing us sales"—and the same designer gives you a real diagnosis. The difference isn’t in the tool; it’s in the request.
Models with good capabilities visual can analyze screenshots, interface photos, proposal PDFs, and creative assets just as they analyze text: identifying hierarchy, focal points, noise, and omissions. That changes the kinds of tasks worth delegating—it's not just “generate text about the image,” it's evaluate the image as a trained reviewer would.
The most common mistake is asking for too little: “make it prettier,” “improve this design,” “take a look at this.” These are vague requests that get vague responses — the model doesn’t know what criteria to evaluate against, so it guesses at generic aesthetic tweaks (color, spacing) instead of focusing on what really matters for your goal: the person to understand and act.
Tip 9 of this track addresses this by replacing the vague request with an audit checklist: where the eye lands first, what causes confusion, what creates desire, what raises questions, what to cut, and what to change to increase conversions. Six objective questions—the ready-to-use prompt comes in the next topic.
Diagram reading: when the same screenshot goes through the 5 right questions instead of "make it prettier," the result is a report with 6 actionable points.
In one sentence: Fable 5 reads the screen like a trained reviewer, but only delivers that if you ask the way a trained reviewer would.
🔍 The visual audit prompt, ready to paste
🧠 Imagine it this way: this isn't an excerpt from Anthropic's official docs — it's a template tested in practice, designed for reviewing interfaces, screenshots, and creative assets. Attach the image and paste the text below with it.
The idea is simple: instead of describing what you want with adjectives (“cleaner,” “more modern”), you describe the business objective of the piece — “help someone quickly understand the value of the proposal” — and asks for a fixed list of six observations. This works for a landing page, app screen, business proposal PDF, ad post, dashboard screenshot.
Analise este print ou imagem. Compare com o objetivo: fazer uma pessoa entender rapidamente o valor da proposta. Diga: 1. onde o olho para primeiro; 2. o que está confuso; 3. o que gera desejo; 4. o que gera dúvida; 5. o que cortar; 6. o que mudar para aumentar conversão.
✗ "Make it prettier"
- ✗Generic aesthetic response (color, spacing)
- ✗Doesn’t say where the eye should go or what’s confusing
- ✗No connection to conversion or a real objective
✓ 6-question guide
- ✓Points to a specific element in the image for each item
- ✓Separates “confusing” from “raises a question”—they’re different things
- ✓End with an action: what to cut, what to change
In one sentence: replace “make it look nicer” with six objective questions, and you turn a vague opinion into an actionable audit.
🛡️ Asking for an exploit blocks the response; asking for a defensive review doesn’t
🧠 Imagine it this way: "teach me how to hack this system" and "review this code for security vulnerabilities" basically ask you to look at the same problem—but one sounds like a request to attack, and the other sounds like a request to defend. Fable 5 responds very differently to each.
When the request is framed as exploration or attack — “how do I exploit this vulnerability,” “give me step-by-step instructions to break in” — the model may classify this as a request for cyber damage and refuse outright, even when your real intention is to protect the system itself.
When the same subject is framed as defensive review — “look for bugs, missing validations, data exposure” — the model understands that the goal is to protect, not attack, and provides a complete analysis: risk, affected file, likely cause, fix. It’s literally the same technical subject, framed differently in the input.
This isn't a trick to "fool" the model—it's the right framing for someone who is actually securing their own system or a client's. Legitimate cybersecurity work (authorized pentesting, auditing, code review) is different from asking for a generic attack recipe, and the way you write the request is what makes that clear to the model.
Diagram reading: the same technical subject, framed as an attack, is blocked; framed as a defensive review, it becomes a useful diagnosis—without an exploit or attack steps.
⚠️ What to avoid in the framing
Asking for a “step-by-step attack guide,” “how to write an exploit,” or “how to break into X”—even with good intentions—falls directly into the refusal category that protects against cyber harm. The goal (protecting your system) takes a back seat if the wording of the request sounds like a request to attack.
In one sentence: same subject, different framing—the attack stalls; the defense delivers a diagnosis.
🔐 The defensive review prompt, ready to paste
🧠 Imagine it this way: again, a template tested in practice — not an official quote. Paste it alongside the server code you want reviewed.
The prompt below explicitly asks for a defensive review: bugs, missing validations, authorization issues, accidental data exposure, configuration failures, operational risks. And it closes with two clear denials—no exploit, no attack walkthrough—that reinforce the framing of the previous topic.
Review my server code defensively. Look for bugs, missing validations, authorization issues, accidental data exposure, configuration errors, and operational risks. Do not create exploits. Do not show attack steps. Only identify the risk, affected file, likely cause, and defensive fix.
🔗 Cross-reference with track 1
This tip directly connects with the module 1.6 of Track 1, which technically explains the refusal category cyber with official backing from the Anthropic docs refusals-and-fallback:
"The request could enable cyber harm, such as malware or exploit development. Benign cybersecurity work can also trigger this category."
In other words: even legitimate cybersecurity work can trigger this category if the request sounds like an attack. The defensive review prompt above is literally the practical strategy for not trigger that refusal — it describes the same module 1.6 from a technical/API perspective; this is the applied version, ready to paste.
In one sentence: asking for a defensive review, with both denials stated explicitly, is the practical way to get a real security analysis without running into a refusal cyber.
🧭 Both tips together: visual audit of an admin dashboard
🧠 Imagine it this way: an internal dashboard mixes both worlds—and an interface (tip 9) that may be leaking sensitive information right on the screen, with server code behind it that decides what appears there (tip 10). Auditing only the interface or only the code leaves half the risk unaddressed.
A realistic case: you have an internal admin panel/dashboard and want to know if it is exposing sensitive data on the screen itself — a customer's full email, token, API key, internal ID, debug field accidentally left in production. This is both a interface (what the eye sees) and a problem with security (what the server decided to send to the browser).
Take a screenshot of the panel
Capture the screen as a real user would see it—tables, modals, open debug panels
Include screens with real data (or a masked copy if you’re sharing outside the team)—not just the empty screen, and show the states that actually appear in day-to-day use.
Run the visual audit prompt (tip 9)
Same text as topic 2, but with an addendum
Beyond the 6 standard questions, explicitly ask: "also point out any data that seems sensitive and shouldn't be visible on this screen (token, full email, key, internal ID)."
Find the code behind what appeared
Every on-screen display originates from a route or query on the server
If the visual audit flagged sensitive data on the screen, locate the route/endpoint that returns that field — usually it's a SELECT * too generous or an API response with no permission filter.
Run the defensive review prompt (tip 10) on this file
Same text as topic 4, applied only to the suspicious file
The result combines both sides: “screen X exposes field Y (visual finding) because route Z returns the entire object without filtering by permission (code finding)—fix it by projecting the response DTO.”
Notice that at no point did you ask “how would an attacker exploit this dashboard?”—you asked for interface clarity and a defensive code review. That exact combination avoids the refusal while still covering the risk end to end: from the screen to the line of code that powers it.
In one sentence: a visual audit finds what’s exposed on screen; a defensive review finds why the code allowed it to be exposed — together, the two tips cover the whole panel.
✅ Common mistakes and quick checklist
🧠 Imagine it this way: the two tips in this lesson almost always fail for the same reason — the request was vague or too offensive. This checklist is the quick antidote to both cases.
Before pasting either prompt, check these points—they’re the mistakes most likely to make tip 9 return vague opinions or tip 10 trigger a refusal.
✗ Avoid
- ✗"Make it prettier" without stating the piece’s goal
- ✗Ask for the screenshot without actually attaching the image
- ✗"Teach me to exploit/break into X"
- ✗Ask for a “step-by-step guide” to anything related to an attack
- ✗Review only the screen or only the code, never both together
✓ Do
- ✓State the piece’s goal + attach the actual image
- ✓Use the same 6 questions from tip 9, always in this order
- ✓Frame security as a “defensive review,” never as an attack
- ✓Close the prompt with both negations: no exploit, no step-by-step instructions
- ✓On data screens, cross-check visuals (tip 9) with code (tip 10)
In one sentence: A clear objective + a real image (tip 9) and defensive framing + two denials (tip 10) solve almost every common mistake in this lesson.
🧾 Module Summary
refusal category cyber; asking for a defensive review of the same topic provides a complete diagnosis.Next module:
2.6 — Loops with verification + external memory: how to turn one-off review into a continuous cycle, with criteria, tests, and recorded lessons.