A BETTER WAY TO SHARE THE WORK
Turn a recurring task into instructions people can follow
Good instructions say when to start, how to check the result, and when to stop.
New to creating with an agent? The request will guide it through the task. Bring your notes; you don’t need to write HTML.
How can I turn process notes into a useful standard operating procedure?
Give your agent the validated procedure, its trigger, prerequisites and confirmed exception path. Ask for a task-first reading guide with numbered steps, expected checks and clear stop conditions. Have an authorized operator walk the draft before sharing it; the page explains the procedure but does not perform or approve it.
01 / SEE THE DIFFERENCE
A newsletter preflight that cannot silently become a send
A fictional, low-risk administrative procedure. It does not send email.
Newsletter preflight starts only with editor-approved copy and an approved audience label. Noor checks that the draft matches the approved copy, opens each supplied link and compares its destination to the intended destination, then confirms the audience label matches the approved record. If a link fails or copy or audience differs, stop and ask editor Ellis in the existing task thread. Record the findings there. This preflight never sends or publishes; Ellis separately authorizes the existing sending workflow.
- Before starting
- Require editor-approved copy and an approved audience label.
- Check
- Noor compares copy, supplied link destinations and audience label with the approved records.
- Stop condition
- Failed link or mismatched copy or audience: stop and ask Ellis in the existing task thread.
- Finish
- Record findings there. Preflight never sends or publishes; Ellis separately authorizes the sending workflow.
Open a complete fictional HTML example, with its source notes →
Create my standard operating procedure02 / MAKE IT YOURSELF
Start with the evidence. Shape the page around the reader.
Set a clear start and boundary
State when this procedure applies and what must be true before an operator starts. A request, approved input and permission to execute are not interchangeable. Keep tasks outside the scope explicit so a routine checklist does not authorize additional work.
Write steps people can verify
Use one observable action at a time, with the relevant input and expected result nearby. Preserve the validated order and exact technical detail when it matters. Do not let an agent invent tool instructions, settings or access grants to close a gap.
Put exceptions where they occur
For each material failure, explain whether to stop, retry under the approved procedure, or ask a confirmed owner. Avoid vague 'use judgment' advice when the procedure supplies a specific escalation rule. Missing or contradictory instructions should remain review blockers.
Walk the draft before calling it an SOP
Have an authorized operator verify the page against the source process, including a failure case. Show the owner and revision so readers can find the maintained version. Use HTML as a readable companion; keep execution, required records and approval in their existing systems.
03 / TRY THIS PROMPT
Copy this into your agent. Add your source material.
Use the conversation where you already did the work, or start one with your notes. Replace the placeholders and supply any missing context; only attach information you are allowed to share with your agent.
Get the ready-to-copy creation request for guided questions, this task, and a draft review before anything is published.
Create a standard operating procedure from only the validated process and authorized instructions I supply. Ask for missing trigger, prerequisites, steps, expected checks, exceptions and escalation owner. Preserve the approved sequence. Do not invent technical actions, permissions, safe limits, approvals or retry behavior. Put stop conditions beside the relevant step. Include the supplied procedure owner, revision and review date. Use readable static HTML with no scripts or forms and my saved style if available. This task documents the procedure; do not execute it. Keep authoritative records and approvals in the existing system. Show the draft and gaps for an authorized operator to review. Do not publish or change access without separate explicit approval.
04 / BEFORE YOU SEND
A polished page still needs your judgment.
- Are trigger, prerequisites and scope explicit?
- Does each step match the validated source procedure?
- Are failure paths and confirmed escalation owners visible?
- Has an authorized operator walked the draft, including an exception?
When HTML fits
A readable administrative task companion with checks and exception paths available where the operator needs them.
When another format fits better
Do not generate safety-critical, medical, legal or regulated operating instructions without the appropriate qualified process. Keep official controlled documents, execution logs and approvals in their required systems.
FROM DRAFT TO A LINK
Make it clear. Make it yours. Then share it.
Keep creating and revising in the agent you already use. With a compatible connection, share/artifacts publishes the reviewed HTML so you do not have to rebuild it in another editor. Ask your agent to use your saved artifact style for headings, color, and tone; review the result before sending it.
Choose who should be able to open the page and verify the returned link. For corrections to the same deliverable, update the existing artifact without changing its link. Publish a separate artifact when the old edition needs to remain available.
These are static pages, not live apps: no scripts, forms, or automatic data refresh. Source collection and scheduling depend on your agent and its available tools, not on share/artifacts.
Make this with my agentQuestions before you start
Can the agent fill missing steps?
It can identify the gap and ask the process owner. It should not invent operational instructions and present them as approved procedure.
Does the page record completion?
No. Record execution and approvals in the established system. A numbered list is not a tracked checklist.
What makes this different from onboarding?
An SOP describes repeatable execution of a defined task by an authorized operator. Onboarding organizes a newcomer’s learning and first tasks, which may link to several SOPs.