Verified against ChatGPT · 2026-08-08
Draft a first-pass internal policy a reviewer can redline instead of rewrite from scratch
Produces a structured first-draft internal operating policy — scope, rules, exceptions, enforcement — built to move a review conversation forward, not to be treated as a finished or authoritative document.
The prompt
Ready to copy — highlighted parts are example details you can swap.
Draft a first-pass internal operating policy on the topic below. Treat this explicitly as a working draft meant to give a reviewer something concrete to redline, not a finished or authoritative policy — state that plainly in the draft's own header so nobody mistakes it for final. POLICY TOPIC Remote work eligibility and expectations for customer-facing support staff. WHAT PROMPTED THIS (GAP OR INCIDENT) Three different managers have approved remote work under three different informal rules, and one team lead is now getting pushback for being stricter than the others. WHO THIS POLICY APPLIES TO All customer support staff below director level; does not apply to on-site facilities or IT staff who need physical presence. EXCEPTIONS THAT SHOULD BE ALLOWED Temporary remote work for a documented medical reason, approved case-by-case by the department director. HOW THIS GETS ENFORCED Manager sign-off logged in the HR system; unclear yet who audits it after the fact. Open the draft with a header stating clearly: 'DRAFT — for internal review, not yet approved; requires sign-off from [the appropriate reviewer, e.g. HR/Legal/relevant department owner] before distribution or enforcement.' Then write the policy body in four short sections: Purpose (tied directly to the gap or incident that prompted it, stated factually, not dramatized), Scope (exactly who it applies to and, just as important, who it explicitly does not), Rules (stated as specific, checkable requirements — 'requests must be submitted 5 business days in advance' rather than 'requests should be submitted with reasonable notice'), and Exceptions (the named exceptions, plus who has authority to grant an exception not explicitly listed, since a policy with zero exception path invites people to just ignore it). Add a brief Enforcement section stating the mechanism given, and where it's unclear who actually enforces it, flag that as an open question for the reviewer rather than inventing an enforcement authority that wasn't stated. Do not invent specific legal requirements, regulations, or compliance obligations to justify the policy — where the input doesn't specify a compliance basis, note that the compliance basis, if any, still needs confirming by the appropriate reviewer rather than asserting one. OUTPUT FORMAT A short, ready-to-review draft with the draft-status header, then Purpose / Scope / Rules / Exceptions / Enforcement sections, ending with a short 'Open Questions for Reviewer' list naming anything the draft had to guess at or leave unresolved.
Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
The single biggest risk of AI-drafted internal policy is that a fluent, confidently-formatted document gets treated as final and distributed before the right person has actually reviewed it, so the explicit draft-status header instruction addresses that risk structurally rather than relying on the reader to remember it's a draft — putting the caveat inside the artifact itself means it travels with the document even if it gets forwarded or copied into another tool. GPT-5.1 tends to write policy rules in soft, non-checkable language ('with reasonable notice', 'as appropriate') when not explicitly constrained, because that phrasing sounds professional in isolation — but a rule that can't be checked against an actual case is unenforceable and just relocates the ambiguity from before the policy existed to after it exists, so requiring specific, checkable requirements is what makes the draft actually useful rather than cosmetically official. The instruction against inventing a specific compliance or legal basis is a direct guard against a common and risky failure mode: a model asked to justify a policy will sometimes reach for a plausible-sounding regulatory reason to make the writing sound more authoritative, and presenting a fabricated compliance basis as fact inside a document that might get treated as settled is exactly the kind of error that compounds if nobody catches it before distribution. Ending with an explicit open-questions list converts the draft from something that looks finished into something that visibly still needs a specific person's judgment, which is the entire point of treating this as a redline starting point rather than a shortcut around the actual review the topic requires.
What you get back
DRAFT — for internal review, not yet approved; requires sign-off from HR before distribution or enforcement. Purpose: to resolve inconsistent remote-work approvals across support teams following manager disagreement over informal rules. Scope: applies to all customer support staff below director level; does not apply to on-site facilities or IT roles. Open Questions for Reviewer: who audits manager sign-offs after the fact is not yet defined and needs a named owner before this can be enforced consistently.
Verified against
ChatGPT GPT-5.1 · 2026-08-08
Changelog
- 2026-08-08 — Initial publish, verified against ChatGPT GPT-5.1.
Need this built into your business?
If a prompt isn't enough — custom software, built and maintained for you — that's Scult's day job.
EXPLORE CUSTOM SOFTWARE
