Ask for the result, not just a nicer summary
Give Claude the permitted notes, audience and required output. Ask for an artifact with a chronological shift sequence and a visible exception rule. An instruction such as “make this professional” does not specify which decision the helper must be able to make.
The Riverbend example below is an original, prepared HTML result for a fictional tool-library shift. It was authored for this guide, not generated in a live Claude session. It demonstrates the content to request and inspect, rather than reproducing Claude’s interface or a real library’s operating rules.
Keep the exception beside the step it changes. The guide says to isolate a returned item with a visible defect and ask the shift lead to inspect it. It does not invent a repair method or let an attractive checklist imply the item is ready to lend.
Choose an artifact that fits the deliverable
Claude’s current artifact help describes artifacts as work that opens beside the conversation. You can ask for one in a chat or start from a template. For a written guide, Docs provides a document workflow; Design supports a designed one-page result. Cloud code execution and file creation must be enabled for artifacts to work.
Ask for a specific revision after reading the result: “Move the damaged-return rule into the return step; preserve the instruction to contact the shift lead.” Check that the edit preserved the rule instead of replacing it with a plausible new policy.
Decide how the reader will receive it
The same help page distinguishes template exports from legacy artifact controls. Docs can export to formats including Word and PDF; Design can export standalone HTML. Export options depend on the artifact type. If the team needs a formal document, use that format rather than assuming every artifact is an HTML file.
Inspect the actual sharing settings and recipient access before sending a link. This guide has not tested a Claude publishing flow or recipient access. A local HTML result also does not inherit Claude-backed AI calls, connectors or storage. Request an independent page if it needs to work without those services.
A prompt for an independent review guide
Create an artifact containing a self-contained HTML shift guide.
Organization and reader: [PASTE]
Permitted notes and approved rules: [PASTE]
Opening, routine steps and closing handoff: [PASTE]
Exceptions and who handles each one: [PASTE]
Required final format: [PASTE]
Use only supplied facts. Show missing rules or responsible roles as [TO CONFIRM]. Do not invent repair instructions, eligibility rules, contacts, hours or approvals. Put the action sequence first and each exception beside the affected step. Distinguish a guide from a live record of completed work.
For the HTML review copy use one h1, ordered steps, a captioned action table with scoped headers and a visible exception note. At least 16px body text; labeled stacked rows at 360px without horizontal overflow. Keep CSS local. No external assets, scripts, Claude calls, connectors, network, storage or fake contact/save controls. Return HTML and unresolved facts; preserve the required final document format.
Let the helper find the missing instruction
Show the guide to the shift lead and ask where a new helper should look for a damaged-return decision. Revise that step in Claude or the maintained source, then send the approved guide in the team’s chosen format.
Name the changed rule when you send the revision. If you already have an independent HTML review copy, you can read that page in NOS to inspect the instruction and exception together. Keep the operational guide and approvals in the team’s actual workflow.