# Hodios paste pack: Policies and terms

Everything in Policies and terms from Hodios, the open prompt library by Hermes IDE: 15 entries, catalog 2026.1004.3.

Every entry is dedicated to the public domain under CC0 1.0. Copy, change and share them freely, no attribution needed.

Browse and search the library at https://hermes-ide.com/prompts

## How to use

Find an entry below and copy the text inside its block into ChatGPT, claude.ai or any chat. Replace each [PLACEHOLDER] with your own material. Personas, rules and styles work best as custom instructions or project instructions.

## Contents

- Policies and terms
  - [Write a conflict of interest policy](#write-conflict-of-interest-policy) (prompt)
  - [Write a cookie notice and banner](#write-cookie-notice) (prompt)
  - [Write a photo and video consent form](#write-photo-consent-form) (prompt)
  - [Write a privacy policy](#write-privacy-policy) (prompt)
  - [Write a refund and returns policy](#write-refund-policy) (prompt)
  - [Write a safeguarding policy](#write-safeguarding-policy) (prompt)
  - [Write a supplier code of conduct](#write-supplier-code-of-conduct) (prompt)
  - [Write a volunteer policy](#write-volunteer-policy) (prompt)
  - [Write a whistleblowing policy](#write-whistleblowing-policy) (prompt)
  - [Write a workplace AI use policy](#write-ai-use-policy) (prompt)
  - [Write a workplace policy](#write-workplace-policy) (prompt)
  - [Write an accessibility statement](#write-accessibility-statement) (prompt)
  - [Write an employee handbook](#write-employee-handbook) (prompt)
  - [Write an end user licence agreement](#write-eula) (prompt)
  - [Write terms of service](#write-terms-of-service) (prompt)

---

<a id="write-conflict-of-interest-policy"></a>

## Write a conflict of interest policy

`write-conflict-of-interest-policy` · prompt · Policies and terms · https://hermes-ide.com/prompts/write-conflict-of-interest-policy

Drafts a conflict of interest policy for a nonprofit board or small company, with definitions and examples, annual and ad hoc declarations, how conflicts are managed in meetings, and a register.

````markdown
<context>
You draft conflict of interest policies for boards of nonprofits and small companies. Conflicts are normal; the harm comes from undisclosed or badly managed ones: a trustee voting on a contract for a relative's business, a director steering a deal to a company they own shares in, a staff member hiring a friend. A workable policy defines conflicts with concrete examples (financial, family, other roles and loyalties, gifts), makes declaring easy and routine, tells the chair exactly what to do when a conflict is declared in a meeting, and records it all. Rules on related-party transactions, directors' duties, charity regulator guidance and tax-exempt status differ by jurisdiction and organisation type, so you flag the legal specifics for confirmation.

</context>

<task>
Organisation:
<organisation>
[ORGANISATION]
</organisation>

1. Key choices: decisions the board must make (who the policy covers, the gifts and hospitality threshold, whether conflicted people leave the room or only abstain, who decides whether a conflict exists, whether to publish the register), with a recommendation for each suited to the organisation's size.
2. Draft the policy in plain language:
   - Purpose and scope.
   - What counts as a conflict: actual, potential and perceived; direct and indirect; with six to ten concrete examples relevant to this organisation, including loyalty conflicts (serving on another board) as well as financial ones.
   - Who counts as connected persons (family, household, businesses they control or work for), defined clearly.
   - Declaring interests: on joining, annually, and whenever a new interest arises; declaring at the start of each meeting and when an item comes up.
   - Managing a declared conflict: the chair's options in order (record only, no vote, leave the discussion and vote, remove from the matter entirely, or not proceed), how the decision is minuted, and what happens when the chair is conflicted.
   - Transactions with connected persons: extra steps such as comparable quotes and approval by unconflicted members, marked to confirm against legal requirements.
   - Gifts and hospitality: threshold [AMOUNT] and a gifts register.
   - Confidential information and use of position.
   - Breaches: how they are handled, and that an honest late declaration is better than none.
   - Review date and acknowledgement.
3. Declaration form: a short annual declaration with the categories of interest and a "none" option.
4. Register template: the columns for a register of interests and of conflicts declared in meetings.
5. Points to confirm: legal requirements for related-party transactions, approvals or disclosures, and any regulator guidance to check.
</task>

<constraints>
- You give general information, not professional advice. You are not a doctor, therapist, lawyer, accountant or financial adviser, and you do not replace one.
- Say so once, briefly, near the start: what you can help with here and what needs a qualified professional.
- Do not diagnose, prescribe, give dosages, predict a legal outcome, or recommend a specific investment, tax position or legal action for this person.
- When the situation is serious, urgent, high-stakes or specific to their circumstances, say which kind of professional to see and what to bring to that appointment.
- If anything suggests immediate danger to health or safety, tell them to contact local emergency services now, before anything else.
- Rules, prices and laws differ by country and change over time. Name the assumption you are making and tell them to check it locally.
- Do not cite statutes, regulator guidance or tax rules as fact unless the user supplied them; describe the issue and mark it "confirm for [jurisdiction]".
- Make the policy usable in a meeting: the steps for the chair must fit on half a page.
- Use [BRACKETS] for thresholds and names; never invent a monetary limit.
- If the input describes a live conflict (for example a trustee's company bidding now), add a short note on handling it under the new policy, framed as a process, not a ruling on whether the transaction may go ahead.
- If asked to write the policy so a specific person's conflict is exempted or hidden, decline and explain why.
- Separate what you verified from what you inferred. Mark inferences as such.
- When you do not know, say "I don't know" once and state what would settle it.
</constraints>

<output_format>
## Key choices
Table: choice | recommendation | why.

## Conflict of interest policy
The full policy with headings.

## Declaration form
The form with tick boxes and fields.

## Register template
Table with column headings and one example row.

## Points to confirm
Numbered.
</output_format>
````

---

<a id="write-cookie-notice"></a>

## Write a cookie notice and banner

`write-cookie-notice` · prompt · Policies and terms · https://hermes-ide.com/prompts/write-cookie-notice

Drafts a cookie notice, a cookie table and consent banner text from the cookies and tools a site actually uses, with categories, purposes, durations and consent choices for the stated jurisdictions.

````markdown
<context>
You draft cookie notices and consent text that describe what a site actually does. Regulators have repeatedly acted against banners that nudge visitors (a bright "Accept all" next to a hidden "Reject"), set non-essential cookies before consent, label advertising cookies "strictly necessary", or describe cookies the site no longer uses. In consent-based regimes such as the EU and UK, non-essential cookies generally need opt-in consent, and rejecting should be as easy as accepting; in many US state laws the focus is on notice and a right to opt out of "sale" or "sharing" for targeted advertising, sometimes signalled through browser opt-out preference signals. These regimes differ and change, so you name the model you are applying and mark it for confirmation.

Visitors in: [JURISDICTIONS]
</context>

<task>
Cookies and tools in use:
<cookies>
[COOKIES_AND_TOOLS]
</cookies>

1. Cookie inventory: classify every item into strictly necessary, functional or preferences, analytics or performance, and advertising or targeting, with provider, purpose, first or third party, and duration. Explain any classification that could be disputed (for example analytics, embedded video, chat widgets). Mark unknown durations or purposes as unknown; do not guess.
2. Consent model: for each stated jurisdiction, the approach you are drafting for (prior opt-in by category, notice with opt-out, honouring opt-out preference signals), marked "confirm with counsel".
3. Banner text: a short first layer in plain language (under about 60 words) with buttons of equal prominence, such as "Accept all", "Reject all" and "Choose cookies", and a link to the notice. Where an opt-out model applies, provide the opt-out link text (for example "Do not sell or share my personal information") as a separate variant.
4. Preferences panel text: one toggle per category with a one-sentence description of what it does for the visitor, the necessary category shown as always on with a reason.
5. Cookie notice: what cookies are, which categories the site uses and why, the cookie table, how to change or withdraw consent at any time (and where the link is), third parties and their own policies, how long consent is remembered, and contact details as [BRACKETS].
6. Gaps and questions: items needing classification decisions, tools that should not fire before consent, vendors needing contracts, and anything that contradicts the privacy policy.
</task>

<constraints>
- You give general information, not professional advice. You are not a doctor, therapist, lawyer, accountant or financial adviser, and you do not replace one.
- Say so once, briefly, near the start: what you can help with here and what needs a qualified professional.
- Do not diagnose, prescribe, give dosages, predict a legal outcome, or recommend a specific investment, tax position or legal action for this person.
- When the situation is serious, urgent, high-stakes or specific to their circumstances, say which kind of professional to see and what to bring to that appointment.
- If anything suggests immediate danger to health or safety, tell them to contact local emergency services now, before anything else.
- Rules, prices and laws differ by country and change over time. Name the assumption you are making and tell them to check it locally.
- Describe only the cookies and tools listed. Do not add cookies, and do not omit one because it is inconvenient.
- Never label an advertising, cross-site tracking or analytics cookie as strictly necessary to avoid consent. If the input does so, reclassify it and explain.
- No dark patterns: no pre-ticked boxes, no "by continuing to browse you accept", reject as easy as accept, no guilt-tripping copy.
- Do not claim the banner or notice is compliant with any law; mark the consent model and any legal wording for review.
- Plain language: "we", "you", short sentences, no technical jargon without a one-line explanation.
- If the tools list is too thin to classify (for example "Google stuff"), ask for a scan or the specific tools first, and give only a template.
- Separate what you verified from what you inferred. Mark inferences as such.
- When you do not know, say "I don't know" once and state what would settle it.
</constraints>

<output_format>
## Cookie inventory
Table: name or tool | provider | category | purpose | party | duration | note.

## Consent model
Bullets per jurisdiction, each marked "confirm with counsel".

## Banner text
The first-layer text and button labels; opt-out variant if needed.

## Preferences panel text
Category | description | default.

## Cookie notice
The full notice with headings and the cookie table.

## Gaps and questions
Numbered.
</output_format>
````

---

<a id="write-photo-consent-form"></a>

## Write a photo and video consent form

`write-photo-consent-form` · prompt · Policies and terms · https://hermes-ide.com/prompts/write-photo-consent-form

Drafts a photo and video consent form with a short policy for a school, club or event - specific uses, opt-outs, children's images, withdrawal and how long images are kept.

````markdown
<context>
You draft photo and video consent forms and short image policies for schools, clubs and events. Photos of identifiable people are usually personal data, and children's images carry extra safeguarding risk: a name next to a face, a school logo and a location can help someone find a child, and some children must never appear publicly for court, adoption, fostering or protection reasons. Good consent is specific (each use opted into separately, not one blanket tick), freely given, easy to withdraw, and recorded. It explains how long images are kept and what happens to images already published when consent is withdrawn. In some places the organisation may rely on a legal basis other than consent for some uses, so the form should not claim more than it does. Your job is a clear, plain-language form and policy tailored to the actual uses, with the legal points left for the organisation to confirm.

Organisation: [ORGANISATION_TYPE]
Country: [COUNTRY]
</context>

<task>
Uses of images:

<uses>
[USES]
</uses>

1. If it is unclear whether children are photographed, ask and stop, because the form and safeguards change.
2. Write a "Before you use this" note: who should review it (the data protection lead, headteacher or committee, and a data protection adviser for anything unusual), and that the legal basis and retention period must be confirmed for [COUNTRY].
3. Draft a short policy: why images are taken, who may take them, the safeguards (no full names with children's images in public channels, no images of children in swimwear or changing areas, consent checked before publication, organisation devices or approved photographers, secure storage), how consent is recorded and checked, how long images are kept and how they are deleted, how withdrawal works, and parents or attendees taking their own photos at events.
4. Draft the consent form: a plain explanation, then a separate yes or no tick box for each use listed (never a single blanket consent), who is giving consent (the person themselves, or a parent or guardian for a child, with a note to involve older children in the decision), how long consent lasts and when it is renewed, how to withdraw, and a signature and date block. Use placeholders for the organisation's name and contact.
5. Draft a short notice for events where photography happens, telling attendees how to opt out (for example a coloured lanyard or a no-photo area) and who to speak to.
6. List the gaps to fill: retention period, data protection contact, legal basis for each use, and storage location.
7. Write questions to check with a data protection adviser, the regulator's guidance or the organisation's safeguarding lead.
8. Before answering, check that every use in the input has its own tick box, children's names are never paired with images publicly unless the organisation explicitly decides otherwise with separate consent, and withdrawal is explained honestly (images already printed or shared by third parties may not be retrievable).
</task>

<constraints>
- You give general information, not professional advice. You are not a doctor, therapist, lawyer, accountant or financial adviser, and you do not replace one.
- Say so once, briefly, near the start: what you can help with here and what needs a qualified professional.
- Do not diagnose, prescribe, give dosages, predict a legal outcome, or recommend a specific investment, tax position or legal action for this person.
- When the situation is serious, urgent, high-stakes or specific to their circumstances, say which kind of professional to see and what to bring to that appointment.
- If anything suggests immediate danger to health or safety, tell them to contact local emergency services now, before anything else.
- Rules, prices and laws differ by country and change over time. Name the assumption you are making and tell them to check it locally.
- Do not state a legal basis, retention period or age of consent for data as fact. Put them in [BRACKETS] to confirm for the country.
- Never draft wording that makes consent a condition of joining or participating, unless the image is essential to the activity and the organisation confirms it; say why.
- Do not promise that published images can always be removed everywhere; say what the organisation will do (remove from its own channels and stop future use).
- Include a line that the organisation will not publish images of any child where a parent or carer has flagged a safety reason, regardless of other consents.
- Keep the form to one page of plain language.
</constraints>

<output_format>
## Before you use this
Three sentences.

## Short policy
The policy text with sub-headings.

## Consent form
The form with tick boxes as "[ ] Yes  [ ] No" per use, and placeholders.

## Notice for events
A short notice.

## Gaps to fill
Checklist.

## Questions to check
Numbered.
</output_format>
````

---

<a id="write-privacy-policy"></a>

## Write a privacy policy

`write-privacy-policy` · prompt · Policies and terms · https://hermes-ide.com/prompts/write-privacy-policy

Drafts a plain-language privacy policy strictly from a product's actual data practices, structured for the stated jurisdictions, and flags every gap or risky practice for legal review.

````markdown
<context>
You draft privacy policies that are honest descriptions of what a product really does, written so a user can understand them. The two common failures are copying a generic template (which then promises things the company does not do, or omits what it does) and burying practices in legalese. Regulators increasingly treat an inaccurate privacy notice as a violation in itself, so accuracy beats completeness: every statement must trace back to a stated practice, and anything unknown becomes a question, not a guess.



</context>

<task>
Actual data practices:

<practices>
[DATA_PRACTICES]
</practices>

1. Inventory the practices: data collected (provided by the user, collected automatically, from third parties), purposes, vendors and recipients, cookies and trackers, transfers, retention, user controls. Note anything missing that a privacy policy normally must cover.
2. Draft the policy in plain language with a layered structure: a short summary at the top, then sections for who we are and how to contact us; what we collect; how we use it (and, where relevant, the legal basis, marked for confirmation); who we share it with; cookies and similar technologies; international transfers; how long we keep it; your rights and how to use them; children; security; changes to this policy; contact and complaints.
3. Add jurisdiction-specific sections only for the stated jurisdictions, describing them in general terms (for example rights of access, deletion and objection; opt-out of sale or sharing; the right to complain to a supervisory authority) and marking each "confirm requirements with counsel".
4. Use [BRACKETS] for company name, address, contact email, data protection officer or representative, effective date, and any fact not given.
5. After the draft, list gaps and risks: practices that may need consent or opt-outs (advertising trackers, sensitive data, children), statements you could not make because facts were missing, and vendors needing data processing agreements.
6. List practices the company may want to change before publishing, where the honest description would be uncomfortable (indefinite retention, no deletion process, unclear sharing).
</task>

<constraints>
- You give general information, not professional advice. You are not a doctor, therapist, lawyer, accountant or financial adviser, and you do not replace one.
- Say so once, briefly, near the start: what you can help with here and what needs a qualified professional.
- Do not diagnose, prescribe, give dosages, predict a legal outcome, or recommend a specific investment, tax position or legal action for this person.
- When the situation is serious, urgent, high-stakes or specific to their circumstances, say which kind of professional to see and what to bring to that appointment.
- If anything suggests immediate danger to health or safety, tell them to contact local emergency services now, before anything else.
- Rules, prices and laws differ by country and change over time. Name the assumption you are making and tell them to check it locally.
- Never describe a practice, right, safeguard or certification that is not in the input. Do not write "we never sell your data" or "we use industry-standard encryption" unless the input says so.
- Mark legal bases, jurisdiction-specific obligations and required wording "confirm with counsel". Do not cite article numbers unless you are certain of them.
- Write at roughly a secondary-school reading level: short sentences, "we" and "you", examples where they help.
- Do not claim the policy is compliant with any law.
- If the practices are too thin to write an honest policy (for example only "we collect emails"), ask focused questions first and give a skeleton only.
- Separate what you verified from what you inferred. Mark inferences as such.
- When you do not know, say "I don't know" once and state what would settle it.
</constraints>

<output_format>
## Before you publish
Three to five bullets: review needed, placeholders to fill, practices to confirm.

## Privacy policy
The complete draft, with a summary box at the top and headings for each section.

## Gaps and risks for legal review
Numbered: issue - why it matters - question for counsel.

## Practices to align
Bullets: practice - suggested change to consider.
</output_format>
````

---

<a id="write-refund-policy"></a>

## Write a refund and returns policy

`write-refund-policy` · prompt · Policies and terms · https://hermes-ide.com/prompts/write-refund-policy

Drafts a plain-language refund and returns policy that fits how the business sells, separates legal rights from goodwill, covers edge cases and lists the local consumer rules to verify.

````markdown
<context>
You write refund and returns policies for small businesses. A good policy is short, honest and operational: customers know exactly what they can do and how, support staff can apply it without escalation, and it does not promise less than the law gives. Two things are often confused. Statutory rights are set by consumer law and cannot be removed by a policy: for example, in the EU and UK, consumers buying at a distance generally have a cancellation (withdrawal) period, commonly 14 days, with listed exceptions such as personalised or perishable goods and digital content once supply begins with the consumer's consent, and separately they have rights when goods are faulty or not as described. Goodwill policies are what the business chooses to offer on top, such as a longer return window. In the US, return policies are mostly at the seller's discretion, but some states require the policy to be displayed and warranty rules still apply. You treat these as the general shape to verify, not legal advice.


</context>

<task>
Business:

<business>
[BUSINESS]
</business>

1. Identify the product types and sales channels, and which rules are likely to matter for each (distance selling, faulty goods, digital content, services, made-to-order). If the jurisdiction is missing, ask for it, and draft in a way that clearly separates statutory rights from goodwill so it can be adapted.
2. Draft the policy in plain language, structured for customers:
   - A two-line summary at the top (for example "Changed your mind? Return within X days. Faulty? We will fix, replace or refund.").
   - Change-of-mind returns: window, condition of items, exceptions, how to start a return, who pays return shipping, refund method and timing.
   - Faulty, damaged or wrong items: how to report, what evidence helps, options, and who pays shipping.
   - Digital products, subscriptions, services, events or made-to-order items, as relevant.
   - Exchanges and store credit, if offered.
   - Marketplace or third-party sales, if relevant.
   - How the policy relates to legal rights: a clear sentence that it does not affect the customer's statutory rights.
   - Contact details.
3. List edge cases with the recommended handling: item used once, missing packaging, sale items, gifts, late returns, partial returns of bundles, international returns, chargebacks in progress, refunds after a price drop, and anything specific to this business.
4. List the consumer rules to verify locally, as questions, naming a law only when you are confident it applies.
5. Give the practical steps to put the policy live: where it must appear (product pages, checkout, order confirmation emails), any pre-contract information to add, internal steps for support, and how to record returns.
</task>

<constraints>
- You give general information, not professional advice. You are not a doctor, therapist, lawyer, accountant or financial adviser, and you do not replace one.
- Say so once, briefly, near the start: what you can help with here and what needs a qualified professional.
- Do not diagnose, prescribe, give dosages, predict a legal outcome, or recommend a specific investment, tax position or legal action for this person.
- When the situation is serious, urgent, high-stakes or specific to their circumstances, say which kind of professional to see and what to bring to that appointment.
- If anything suggests immediate danger to health or safety, tell them to contact local emergency services now, before anything else.
- Rules, prices and laws differ by country and change over time. Name the assumption you are making and tell them to check it locally.
- Never draft a policy that removes or contradicts statutory rights the business likely cannot exclude (for example "no refunds for faulty items" or "all sales final" for distance sales where withdrawal rights apply); explain why if the description asks for it.
- Do not invent laws, periods or exceptions; mark everything that depends on local law as "to verify".
- Keep the policy short, scannable and free of legalese. Use the business's own processes; do not invent ones it does not have.
- Recommend a lawyer or a local business support service check the policy if the business sells across borders, sells services or digital content, or sells high-value goods.
- Separate what you verified from what you inferred. Mark inferences as such.
- When you do not know, say "I don't know" once and state what would settle it.
</constraints>

<output_format>
## Policy
The full customer-facing policy, ready to publish after checks, with [BRACKETS] for missing details.

## Edge cases
Table: case | how to handle | note.

## Rules to verify
Numbered questions.

## Putting it live
Checklist.
</output_format>
````

---

<a id="write-safeguarding-policy"></a>

## Write a safeguarding policy

`write-safeguarding-policy` · prompt · Policies and terms · https://hermes-ide.com/prompts/write-safeguarding-policy

Drafts a safeguarding policy for an organisation working with children or adults at risk, covering roles, safe recruitment, a code of behaviour, reporting concerns, records and training.

````markdown
<context>
You draft safeguarding policies for organisations that work with children or adults at risk, the way an experienced safeguarding consultant does. The policy exists so that every adult in the organisation knows how to prevent harm, recognise signs of abuse or neglect, respond to a disclosure, and report a concern quickly to the right person, and so that the organisation recruits safely and handles allegations against its own staff properly. The common failures are generic policies nobody reads, no named lead, unclear routes when the concern is about a leader, and staff who promise children confidentiality or investigate themselves. Statutory guidance, background-check schemes, mandatory reporting duties and the authorities to contact differ by jurisdiction, so you name them as placeholders and mark them for confirmation against official local guidance.

Jurisdiction: [JURISDICTION]
</context>

<task>
Organisation:
<organisation>
[ORGANISATION]
</organisation>

1. Before adopting: the decisions the organisation must make (a named designated safeguarding lead and deputy, a board or trustee lead, the external authorities' contact details), and what to check in local statutory guidance.
2. Draft the policy in plain language:
   - Policy statement: the organisation's commitment, who the policy covers (staff, volunteers, trustees, contractors), and the principle that the welfare of the child or adult at risk is paramount.
   - Roles and responsibilities: designated lead and deputy (with [BRACKETS] for names and contacts), board lead, everyone's duty to report.
   - Safe recruitment: role descriptions, references, background checks under the local scheme (named as a placeholder to confirm), induction and supervision.
   - Code of behaviour tailored to the activities: one-to-one contact, physical contact, transport, overnight stays, online contact and social media, photography, gifts, and what to do if a rule must be broken in an emergency.
   - Recognising concerns: the main categories of abuse and neglect, with brief signs, and newer risks relevant to the activities (online harm, exploitation).
   - Responding to a disclosure: listen, stay calm, do not promise to keep it secret, do not ask leading questions or investigate, record the person's own words, and report the same day.
   - Reporting: to the designated lead, and directly to emergency services or the local authority when someone is in immediate danger or the lead is unavailable or implicated.
   - Allegations against staff or volunteers: separate route, who to tell, and suspension or referral steps marked to confirm.
   - Records, confidentiality and information sharing: what is recorded, where it is stored, and the principle that safeguarding can justify sharing information.
   - Training, review date and related policies (whistleblowing, anti-bullying, online safety, photography).
3. Reporting flowchart: a short text flowchart from "I have a concern" to the outcomes, including the immediate-danger route.
4. Points to confirm: each legal or guidance point assumed for the jurisdiction.
</task>

<constraints>
- You give general information, not professional advice. You are not a doctor, therapist, lawyer, accountant or financial adviser, and you do not replace one.
- Say so once, briefly, near the start: what you can help with here and what needs a qualified professional.
- Do not diagnose, prescribe, give dosages, predict a legal outcome, or recommend a specific investment, tax position or legal action for this person.
- When the situation is serious, urgent, high-stakes or specific to their circumstances, say which kind of professional to see and what to bring to that appointment.
- If anything suggests immediate danger to health or safety, tell them to contact local emergency services now, before anything else.
- Rules, prices and laws differ by country and change over time. Name the assumption you are making and tell them to check it locally.
- If the user describes a current concern about a specific child or adult, stop drafting and tell them first to act on it now: contact emergency services if anyone is in immediate danger, or the local child or adult protection authority, then return to the policy.
- Do not name statutes, guidance documents, check schemes, agencies or phone numbers as fact unless the user supplied them; use [BRACKETS] and mark them "confirm locally".
- Never tell staff to investigate, to confront an alleged abuser, or to promise confidentiality to the person disclosing.
- Keep the code of behaviour concrete and tailored to the stated activities; no generic filler.
- Write so a volunteer can follow it: short sentences, plain words, and the reporting steps easy to find.
- Separate what you verified from what you inferred. Mark inferences as such.
- When you do not know, say "I don't know" once and state what would settle it.
</constraints>

<output_format>
## Before adopting
Checklist.

## Safeguarding policy
The full policy with headings.

## Reporting flowchart
Numbered text flowchart with the immediate-danger branch first.

## Points to confirm
Numbered.
</output_format>
````

---

<a id="write-supplier-code-of-conduct"></a>

## Write a supplier code of conduct

`write-supplier-code-of-conduct` · prompt · Policies and terms · https://hermes-ide.com/prompts/write-supplier-code-of-conduct

Writes a supplier code of conduct sized for a small or mid-sized buyer, covering labour and human rights, health and safety, environment, ethics, data, subcontracting, audit rights and remediation.

````markdown
<context>
You write supplier codes of conduct for small and mid-sized buyers. Large-company codes copied wholesale do not work for them: they promise audit programmes the buyer cannot run, demand certifications small suppliers cannot afford, and so become paperwork nobody enforces. A useful code is short, states clear minimum standards drawn from widely recognised international frameworks (such as the ILO core labour standards and the UN Guiding Principles on Business and Human Rights), sets proportionate expectations for verification, and treats remediation as the first response to problems rather than instant termination, which can harm the very workers the code is meant to protect. Laws on supply chain due diligence, modern slavery reporting and forced-labour import bans vary by country and size threshold, so you flag which may apply rather than asserting it.
</context>

<task>
Buying organisation:
<organisation>
[ORGANISATION]
</organisation>

1. Approach: three to five sentences on the scope (which suppliers it applies to), the tone (partnership with minimum standards), and how strict verification will be given the buyer's size and leverage. If the organisation input is missing size, sector or supplier countries, ask for them and draft a general version meanwhile.
2. Draft the code in plain language, each section with short "must" statements:
   - Purpose and scope, including the expectation that suppliers pass the standards down to their own subcontractors.
   - Compliance with law, and the principle that where the code is stricter than local law the code applies, and where local law is stricter the law applies.
   - Labour and human rights: no forced, bonded or prison labour; no recruitment fees charged to workers; no retention of identity documents; no child labour, with protections for young workers; freedom of association; non-discrimination and no harassment; working hours and wages that at least meet legal requirements; written terms in a language workers understand.
   - Health and safety: safe workplaces, training, emergency preparedness, accommodation standards where provided.
   - Environment: permits, waste and pollution, and data on energy or emissions only if the buyer needs it.
   - Business ethics: anti-bribery, gifts and hospitality, conflicts of interest, fair competition, accurate records.
   - Data protection and confidentiality.
   - Grievance mechanisms for workers, and a channel to report breaches to the buyer, with protection from retaliation.
   - Verification: self-assessment questionnaires, documentation requests, and audits proportionate to risk, with reasonable notice except where serious concerns arise.
   - Breaches and remediation: a corrective action plan with timelines, support, and termination as a last resort or for zero-tolerance breaches named in the code.
   - Acknowledgement block.
3. Rollout and verification: a practical plan for this buyer (risk-rank suppliers by country and category, start with the top tier, how to collect acknowledgements, a one-page self-assessment, what to do with red flags).
4. Points to confirm: laws that may require due diligence or reporting for this buyer, and contract changes needed to make the code enforceable.
</task>

<constraints>
- You give general information, not professional advice. You are not a doctor, therapist, lawyer, accountant or financial adviser, and you do not replace one.
- Say so once, briefly, near the start: what you can help with here and what needs a qualified professional.
- Do not diagnose, prescribe, give dosages, predict a legal outcome, or recommend a specific investment, tax position or legal action for this person.
- When the situation is serious, urgent, high-stakes or specific to their circumstances, say which kind of professional to see and what to bring to that appointment.
- If anything suggests immediate danger to health or safety, tell them to contact local emergency services now, before anything else.
- Rules, prices and laws differ by country and change over time. Name the assumption you are making and tell them to check it locally.
- Keep the code proportionate to the buyer. Do not promise audit programmes, certifications or reporting the input does not support; offer them as optional upgrades.
- Use recognised standards by name only in general terms; do not quote conventions or cite statute sections unless the user supplied them.
- Do not state that a law applies to the buyer as fact; flag it with the size or sector trigger to check.
- Do not write requirements designed to shift all cost or liability onto small suppliers without support; note where the buyer's own purchasing practices (prices, lead times) affect compliance.
- Use [BRACKETS] for company names and contacts.
- Separate what you verified from what you inferred. Mark inferences as such.
- When you do not know, say "I don't know" once and state what would settle it.
</constraints>

<output_format>
## Approach
Short paragraph.

## Supplier code of conduct
The full code with numbered sections.

## Rollout and verification
Numbered plan.

## Points to confirm
Numbered.
</output_format>
````

---

<a id="write-volunteer-policy"></a>

## Write a volunteer policy

`write-volunteer-policy` · prompt · Policies and terms · https://hermes-ide.com/prompts/write-volunteer-policy

Drafts a plain-language volunteer policy for a charity, club or community group covering recruitment, roles, expenses, safeguarding, data, problems and ending volunteering.

````markdown
<context>
You draft volunteer policies for small charities, clubs and community groups. A good policy tells volunteers what to expect and what is expected of them, protects the people the group serves, and keeps the organisation on the right side of employment, data protection, insurance and safeguarding rules. One trap matters more than most in many countries: if volunteers are paid more than genuine out-of-pocket expenses, given rewards that look like pay, or bound by contract-like obligations, they can be treated as workers or employees with employment rights. So the policy uses the language of mutual expectations and goodwill, not contractual duties, and expenses are reimbursed against receipts. Your job is a practical, readable draft fitted to the group's real activities, with gaps clearly marked for the group's trustees or committee to settle.

Organisation:

<organisation>
[ORGANISATION]
</organisation>

Volunteer activities:

<activities>
[ACTIVITIES]
</activities>

Any role works with children or adults at risk: false
</context>

<task>
1. If the country is not stated in the organisation description, ask for it and stop, since expenses, background checks and data rules depend on it.
2. Write a short "Before you adopt this" note: who should review it (trustees or committee, and a solicitor or a local volunteer centre or charity support body for anything unusual), and which sections depend on local law.
3. Draft the policy with these sections, adapted to the activities and written in plain language with "we" for the organisation and "you" for volunteers:
   - Why we involve volunteers, and what volunteering here is and is not (not employment; no contract; either side can end it).
   - Recruitment and selection: fair and open recruitment, role descriptions, an informal conversation, references where the role needs them.
   - Induction, training and supervision: what every volunteer gets, and a named contact.
   - Roles and boundaries for each activity listed, including tasks volunteers must not do.
   - Expenses: what is reimbursed (travel, specific costs agreed in advance), how to claim against receipts, and a statement that no flat payments or rewards are made beyond genuine expenses unless the committee has checked the rules.
   - Health and safety, insurance cover for volunteers (to confirm with the insurer), and driving volunteers' own vehicles if relevant (licence, insurance and roadworthiness checks).
   - Confidentiality and personal data: what volunteers may see, how to handle it, and what to do if data is lost.
   - Safeguarding, only when the flag above is true or any activity involves children or adults at risk: background or criminal record checks for eligible roles under local rules, safeguarding training, the named safeguarding lead, how to raise a concern, and a reference to the separate safeguarding policy, which this policy does not replace. Otherwise leave this section out.
   - Equality, inclusion and reasonable adjustments.
   - Recognition and feedback.
   - Problem solving: how a volunteer raises a concern or complaint, and how the organisation handles concerns about a volunteer, fairly and proportionately, in steps rather than as a disciplinary procedure.
   - Ending volunteering: by either side, an exit conversation, return of keys, equipment and data.
   - Review date and who owns the policy.
4. List the gaps the group must fill (named contacts, expense rates, insurer, any check levels) as [BRACKETS] in the policy and in a "Gaps to fill" list.
5. Write questions to check with a local volunteer centre, charity regulator guidance, insurer or a solicitor.
6. Before answering, check that the policy contains no contract-like language ("must work", "notice period", "disciplinary"), no promise of payment beyond expenses, and that every activity listed is covered in roles and boundaries.
</task>

<constraints>
- You give general information, not professional advice. You are not a doctor, therapist, lawyer, accountant or financial adviser, and you do not replace one.
- Say so once, briefly, near the start: what you can help with here and what needs a qualified professional.
- Do not diagnose, prescribe, give dosages, predict a legal outcome, or recommend a specific investment, tax position or legal action for this person.
- When the situation is serious, urgent, high-stakes or specific to their circumstances, say which kind of professional to see and what to bring to that appointment.
- If anything suggests immediate danger to health or safety, tell them to contact local emergency services now, before anything else.
- Rules, prices and laws differ by country and change over time. Name the assumption you are making and tell them to check it locally.
- Do not state specific legal thresholds, check levels or tax-free expense rates as fact. Put them in [BRACKETS] to confirm locally.
- If the safeguarding flag is false but any activity described involves children or adults at risk, say so at the top and recommend adding safeguarding provisions and a separate safeguarding policy.
- Avoid wording that could create an employment relationship: use "we hope", "we ask", "we will" rather than obligations on the volunteer with penalties.
- Keep the policy readable for volunteers: short paragraphs, plain words, no legal citations unless the user provides them.
</constraints>

<output_format>
## Before you adopt this
Three or four sentences.

## Volunteer policy
The full draft with sub-headings for each section and [BRACKETS] for gaps.

## Gaps to fill
Checklist.

## Questions to check
Numbered, with who to ask.
</output_format>
````

---

<a id="write-whistleblowing-policy"></a>

## Write a whistleblowing policy

`write-whistleblowing-policy` · prompt · Policies and terms · https://hermes-ide.com/prompts/write-whistleblowing-policy

Drafts a speak-up or whistleblowing policy scaled to the organisation, covering what to report, internal and external channels, anonymity, protection from retaliation and investigations.

````markdown
<context>
You draft speak-up and whistleblowing policies that people will actually trust and use. Most wrongdoing is first reported internally, and whether people report at all depends on three things: knowing what to report and where, believing they will be protected from retaliation, and seeing that reports are handled. A policy fails when its only channel is the line manager who may be involved, when it promises confidentiality it cannot keep, or when it implies people must report internally before going to a regulator. Many jurisdictions now set specific requirements, for example the EU Whistleblowing Directive as transposed nationally (internal channels for organisations above a size threshold, acknowledgement and feedback deadlines, protection for a broad group of reporters), the UK's protected disclosure rules, and US securities and sector rules; these differ and change, so you draft the structure and mark every legal specific for confirmation.

Jurisdiction: [JURISDICTION]
</context>

<task>
Organisation:
<organisation>
[ORGANISATION]
</organisation>

1. Design decisions: the choices the policy must make for this organisation (who receives reports, whether anonymous reports are accepted and how, an external hotline or not, who investigates reports about senior leaders), with a recommendation for each based on size and structure, and the legal points to confirm.
2. Draft the policy in plain language:
   - Why it matters and a clear statement that reporting in good faith is welcomed.
   - Who can report (scope of people), including former staff, applicants, contractors and volunteers where relevant.
   - What to report: concrete examples (fraud, bribery, safety risks, environmental harm, data breaches, harassment where handled here, cover-ups) and what goes through other routes (personal grievances), explained without discouraging reports.
   - How to report: at least two internal channels, one of which bypasses management, written and oral options, and how to report anonymously if accepted.
   - External reporting: that people may report to regulators or other competent authorities, with [BRACKETS] for those to be named, and that nothing in the policy prevents this.
   - Confidentiality: what the organisation will do to protect identity, and its honest limits.
   - Protection: no retaliation, examples of retaliation, how to raise it, and consequences for those who retaliate.
   - What happens next: acknowledgement, assessment, investigation by someone independent of the matter, feedback to the reporter within stated time frames marked to confirm, and outcome.
   - Rights of people named in a report.
   - False reports: only knowingly false reports are a disciplinary matter; honest mistakes are protected.
   - Records and data protection, and policy owner, review date and training.
3. Process summary for recipients: a one-page procedure for whoever receives reports (log, acknowledge, assess, conflict check, investigate, feed back, close, report to the board).
4. Points to confirm: every legal requirement assumed, with what to check.
</task>

<constraints>
- You give general information, not professional advice. You are not a doctor, therapist, lawyer, accountant or financial adviser, and you do not replace one.
- Say so once, briefly, near the start: what you can help with here and what needs a qualified professional.
- Do not diagnose, prescribe, give dosages, predict a legal outcome, or recommend a specific investment, tax position or legal action for this person.
- When the situation is serious, urgent, high-stakes or specific to their circumstances, say which kind of professional to see and what to bring to that appointment.
- If anything suggests immediate danger to health or safety, tell them to contact local emergency services now, before anything else.
- Rules, prices and laws differ by country and change over time. Name the assumption you are making and tell them to check it locally.
- Never require internal reporting before external reporting, and never include confidentiality or non-disparagement wording that could deter reporting to authorities.
- Do not promise absolute confidentiality or anonymity the organisation cannot guarantee; describe the protections honestly.
- Do not cite article numbers, deadlines or thresholds as fact unless the user supplied them; describe them and mark "confirm for [jurisdiction]".
- Scale it: a 20-person company gets a short policy with an external option for reports about the founders; a 2,000-person group gets more process.
- Use [BRACKETS] for names, contacts and hotline details; never invent them.
- If the user asks for wording that discourages reports, identifies anonymous reporters, or penalises reporters, decline and explain the legal and trust risk.
- Separate what you verified from what you inferred. Mark inferences as such.
- When you do not know, say "I don't know" once and state what would settle it.
</constraints>

<output_format>
## Design decisions
Table: decision | recommendation | why | confirm.

## Policy
The full policy with headings.

## Process summary for recipients
Numbered steps with timings marked to confirm.

## Points to confirm
Numbered.
</output_format>
````

---

<a id="write-ai-use-policy"></a>

## Write a workplace AI use policy

`write-ai-use-policy` · prompt · Policies and terms · https://hermes-ide.com/prompts/write-ai-use-policy

Drafts a workplace AI use policy covering approved tools, data rules, disclosure, human review of outputs, prohibited uses, training and ownership, with points flagged for legal and HR review.

````markdown
<context>
You write AI use policies that staff actually follow. Policies that ban everything get ignored and push use onto personal accounts where the organisation has no control; policies that say "use responsibly" give no guidance. What works is a short policy built on three things: which tools are approved and for what (with an easy path to request new ones), which data may go into which tools (tied to the organisation's existing data categories), and who is accountable for outputs (a named human reviews anything that leaves the building or affects a person). Laws and contracts add requirements: data protection law for personal data in prompts, client confidentiality and contract terms about AI, copyright and IP in generated material, employment law where AI touches hiring or monitoring, sector rules, and in the EU the AI Act's AI literacy duty and stricter rules for some uses.
</context>

<task>
Organisation:

<organisation>
[ORGANISATION]
</organisation>

1. List the decisions leadership must make before the policy is final (for example which tools to approve, whether personal accounts are ever allowed, disclosure to clients, use of AI in decisions about people, monitoring of use), each with options and a one-line trade-off.
2. Draft the policy in plain language:
   - Purpose and scope: who it covers (staff, contractors), which tools count (chat assistants, code assistants, AI features inside existing software, meeting transcription, image generation).
   - Principles: a short list, phrased as behaviour.
   - Approved tools: tiers (approved for general use, approved for limited data or uses, not approved) and how to request a new tool.
   - Data rules: a table mapping the organisation's data categories to what is allowed in each tool tier, with concrete examples; never paste secrets, credentials or data you are not allowed to share.
   - Human review and accountability: who checks outputs before use, extra checks for facts, numbers, code, legal or medical content, and published material.
   - Disclosure: when to tell clients, readers or colleagues that AI was used.
   - IP and confidentiality: ownership of outputs, third-party rights, client contract terms.
   - Prohibited uses: specific to this organisation (for example automated decisions about hiring, pay or discipline without human review; impersonation and deepfakes; uploading client data to unapproved tools; covert recording).
   - Incidents: what to do if sensitive data was entered or an AI output caused harm, and who to tell.
   - Training and support, owner of the policy, review cadence, and consequences of breach in proportionate terms.
3. Build a tool register template (tool, tier, approved uses, data allowed, account type, data retention and training settings, owner, review date), pre-filled for tools named in the description with the settings to verify.
4. Give a rollout plan: announcement, training, quick-reference card, and how to bring existing unapproved use into the open without blame.
5. List the points to review with legal and HR, including employee consultation or works council requirements where they may apply, monitoring and privacy rules, and any AI Act duties if the organisation operates in the EU.
</task>

<constraints>
- You give general information, not professional advice. You are not a doctor, therapist, lawyer, accountant or financial adviser, and you do not replace one.
- Say so once, briefly, near the start: what you can help with here and what needs a qualified professional.
- Do not diagnose, prescribe, give dosages, predict a legal outcome, or recommend a specific investment, tax position or legal action for this person.
- When the situation is serious, urgent, high-stakes or specific to their circumstances, say which kind of professional to see and what to bring to that appointment.
- If anything suggests immediate danger to health or safety, tell them to contact local emergency services now, before anything else.
- Rules, prices and laws differ by country and change over time. Name the assumption you are making and tell them to check it locally.
- Tailor to the organisation's size and data. A ten-person agency needs two pages, not a corporate framework.
- Do not state as fact the data retention or training settings of any vendor; mark them "to verify in the vendor's current terms and admin settings".
- Do not invent laws or legal obligations; mark legal points for review.
- Keep consequences proportionate and avoid language that discourages people from reporting mistakes.
- Separate what you verified from what you inferred. Mark inferences as such.
- When you do not know, say "I don't know" once and state what would settle it.
</constraints>

<output_format>
## Decisions to make
Numbered: decision - options - trade-off.

## Policy
The full policy with numbered sections and the data rules table.

## Tool register
Table template, pre-filled where possible.

## Rollout plan
Numbered steps with owners and timing.

## Review with legal and HR
Numbered questions.
</output_format>
````

---

<a id="write-workplace-policy"></a>

## Write a workplace policy

`write-workplace-policy` · prompt · Policies and terms · https://hermes-ide.com/prompts/write-workplace-policy

Drafts an internal workplace policy such as remote work, expenses or leave, with purpose, scope, clear rules, exceptions, approval paths and the points that need HR and employment-law review.

````markdown
<context>
You draft internal policies that employees can actually follow: short, specific, and fair. Good policies say why they exist, who they cover, the rules in concrete terms (numbers, limits, deadlines, who approves), what happens in exceptions, and who to ask. Bad ones are vague ("reasonable expenses"), copy another company's culture, or quietly fall below statutory minimums. Employment law sets floors that policies cannot go below, and they differ widely by country, so anything statutory must be checked rather than assumed.

Topic: [POLICY_TOPIC]

</context>

<task>
Company context:

<company>
[COMPANY_CONTEXT]
</company>

1. List the decisions the policy needs (for example, for remote work: eligibility, core hours, equipment, home-office costs, working from another country, security; for expenses: what is reimbursable, limits, approval, receipts, deadlines, corporate cards; for leave: entitlement, accrual, carry-over, requesting, approval, sickness). Mark each as decided by the company context, proposed by you as a common practice (with options), or requiring a statutory check.
2. Draft the policy with these sections: purpose; scope (who it covers, including contractors or not, and locations); definitions if needed; the rules, written as concrete, numbered statements; how to request or approve; exceptions and how they are decided; responsibilities (employee, manager, HR or operations); related policies; review date and owner.
3. Write in the company's stated tone, in plain language, using "you" for the employee where it fits.
4. Use [BRACKETS] for amounts, limits and dates the company has not decided. Where a statutory minimum may apply (leave days, pay for overtime, expense tax treatment, working-time limits, rights to request flexible work), write "[at least the statutory minimum - confirm]" rather than a number.
5. Add rollout notes: who should review, how to communicate it, whether consultation with employees or their representatives may be required, and how to handle existing arrangements.
6. List points for HR and legal review.
</task>

<constraints>
- You give general information, not professional advice. You are not a doctor, therapist, lawyer, accountant or financial adviser, and you do not replace one.
- Say so once, briefly, near the start: what you can help with here and what needs a qualified professional.
- Do not diagnose, prescribe, give dosages, predict a legal outcome, or recommend a specific investment, tax position or legal action for this person.
- When the situation is serious, urgent, high-stakes or specific to their circumstances, say which kind of professional to see and what to bring to that appointment.
- If anything suggests immediate danger to health or safety, tell them to contact local emergency services now, before anything else.
- Rules, prices and laws differ by country and change over time. Name the assumption you are making and tell them to check it locally.
- Never state a statutory entitlement, tax rule or legal requirement as fact. Mark it "confirm with HR or employment counsel" and name the topic so they know what to check.
- The policy must not discriminate or treat groups differently without a stated, legitimate reason; flag any requested rule that could (for example, remote work only for certain age groups, leave rules that disadvantage parents).
- Keep the policy itself under about 1,200 words; if more detail is needed, move it into an appendix or FAQ.
- Do not invent company facts; when a choice is a proposal, say so in the decisions section.
- If staff are in several countries, say where local variations or addenda may be needed.
- Separate what you verified from what you inferred. Mark inferences as such.
- When you do not know, say "I don't know" once and state what would settle it.
</constraints>

<output_format>
## Decisions this policy makes
Table: decision | source (company, proposed, statutory check) | value or options.

## Policy
The complete draft with title, version, owner and effective date placeholders, and the sections above.

## Rollout notes
Bullets.

## Points for HR and legal review
Numbered.
</output_format>
````

---

<a id="write-accessibility-statement"></a>

## Write an accessibility statement

`write-accessibility-statement` · prompt · Policies and terms · https://hermes-ide.com/prompts/write-accessibility-statement

Writes an honest accessibility statement for a website or app, covering the standard targeted, conformance status, known issues with workarounds, alternatives, feedback contact and review date.

````markdown
<context>
You write accessibility statements that disabled users can rely on. The statement's job is practical: tell people what works, what does not, how to get the content another way, and how to report a problem and get a response. The common failures are overclaiming ("fully accessible", "WCAG compliant" with no testing behind it) and vague known-issues sections. Some regimes prescribe the statement's structure and content (for example public sector bodies in the UK and EU, and organisations within the European Accessibility Act), others do not require one at all; an inaccurate statement can create legal exposure. So every claim traces back to the testing described, and required elements are flagged for confirmation.

</context>

<task>
Product: [PRODUCT]

What is known about accessibility:
<status>
[CONFORMANCE_STATUS]
</status>

1. Decide the honest conformance wording from the evidence: fully conformant, partially conformant, or not conformant to the stated standard and level. "Fully" is only possible if testing covered the whole scope and found no failures. If there is no testing, say so and use "we have not yet assessed" wording.
2. Draft the statement in plain language:
   - Commitment and scope: who runs the service, which parts the statement covers.
   - How accessible it is: a short list of what users can do (for example zoom to 400% without loss, navigate by keyboard, use a screen reader) only where the input supports it, and a short list of what does not work yet.
   - Conformance status with the standard, level and wording from step 1.
   - Known issues: each in user terms (what fails, where, who is affected), with the success criterion if known, a workaround, and the planned fix date if given.
   - Content out of scope and why, only where the input states it.
   - Alternatives: how to get information in another format and how long it takes.
   - Feedback and contact: how to report a problem, the response time the organisation commits to, and [BRACKETS] for contact details.
   - Enforcement or escalation route, only where the jurisdiction requires or provides one, marked to confirm.
   - How it was tested: method, date, who tested.
   - Date prepared and next review date.
3. Gaps and questions: claims you could not make, required elements for the jurisdiction to confirm, and testing that would make the statement stronger.
</task>

<constraints>
- You give general information, not professional advice. You are not a doctor, therapist, lawyer, accountant or financial adviser, and you do not replace one.
- Say so once, briefly, near the start: what you can help with here and what needs a qualified professional.
- Do not diagnose, prescribe, give dosages, predict a legal outcome, or recommend a specific investment, tax position or legal action for this person.
- When the situation is serious, urgent, high-stakes or specific to their circumstances, say which kind of professional to see and what to bring to that appointment.
- If anything suggests immediate danger to health or safety, tell them to contact local emergency services now, before anything else.
- Rules, prices and laws differ by country and change over time. Name the assumption you are making and tell them to check it locally.
- Never write "fully accessible", "fully compliant" or "WCAG compliant" unless the input describes testing that supports it. Overclaiming is worse than admitting issues.
- Do not invent known issues, testing dates, auditors or response times; use [BRACKETS] for missing facts.
- Describe issues in terms of what a user experiences, not only success-criterion numbers.
- Do not state legal requirements as fact; mark required sections and wording "confirm for your jurisdiction".
- Write the statement itself accessibly: short sentences, descriptive headings and link text, no tables for content that reads better as a list.
- Separate what you verified from what you inferred. Mark inferences as such.
- When you do not know, say "I don't know" once and state what would settle it.
</constraints>

<output_format>
## Before you publish
Three to five bullets.

## Accessibility statement
The full statement with headings.

## Gaps and questions
Numbered.
</output_format>
````

---

<a id="write-employee-handbook"></a>

## Write an employee handbook

`write-employee-handbook` · prompt · Policies and terms · https://hermes-ide.com/prompts/write-employee-handbook

Drafts a small company's first employee handbook covering culture, hours, leave, conduct, IT, complaints and discipline, with every point that depends on local employment law flagged to verify.

````markdown
<context>
You write first employee handbooks for founders hiring their first employees. A good handbook does two jobs: it tells people how things work here (culture, expectations, practical how-tos) and it sets fair, consistent processes for the moments that go wrong (sickness, complaints, discipline). The legal risk lies in the details: statutory minimums for leave, sick pay, working time and notice that a handbook cannot reduce; policies some places require in writing (for example on harassment, whistleblowing or data protection); whether the handbook is part of the employment contract or not; and, in some US states, at-will employment statements. A handbook that promises more than the company does, or contradicts employment contracts, creates obligations it did not intend.


</context>

<task>
Company:

<company>
[COMPANY]
</company>

1. List the decisions the founder must make first (for example whether the handbook is contractual, leave above the statutory minimum, sick pay, remote work rules, equipment ownership, probation), each with options and a one-line trade-off.
2. Draft the handbook in a warm, plain voice that matches the company's values, with numbered sections:
   - Welcome, who we are and how we work (values as behaviours).
   - About this handbook: status (non-contractual unless decided otherwise), how it relates to contracts, and how it is updated.
   - Working hours, flexibility, remote and hybrid work, time recording if required.
   - Pay day, expenses and benefits.
   - Holidays and leave: annual leave and booking, public holidays, sickness reporting and pay, family leave (parental, maternity, paternity, adoption), bereavement, other leave, each with statutory points marked [VERIFY LOCAL LAW].
   - Conduct: respect, equal opportunity, anti-harassment and bullying with how to report, conflicts of interest, gifts, social media, confidentiality.
   - Health, safety and wellbeing.
   - IT, equipment, security and data protection (including how employee data is handled).
   - Raising concerns: informal route, formal grievance steps, and whistleblowing.
   - Performance and discipline: expectations, support first, then a fair, staged disciplinary process with the right to be heard and to appeal.
   - Leaving: notice, return of equipment, references.
3. Mark every point that depends on local law with [VERIFY LOCAL LAW: what to check], and every missing fact with [BRACKETS].
4. Give a local-law checklist: the topics to confirm for this jurisdiction (statutory leave and pay, working time and breaks, policies required in writing, mandatory training or notices, at-will or notice rules, data protection notice for employees, record-keeping), naming a law only where you are confident it applies.
5. Give a short "before you issue it" checklist: legal review, consistency with contracts, employee acknowledgement, where it lives, and a review date.
</task>

<constraints>
- You give general information, not professional advice. You are not a doctor, therapist, lawyer, accountant or financial adviser, and you do not replace one.
- Say so once, briefly, near the start: what you can help with here and what needs a qualified professional.
- Do not diagnose, prescribe, give dosages, predict a legal outcome, or recommend a specific investment, tax position or legal action for this person.
- When the situation is serious, urgent, high-stakes or specific to their circumstances, say which kind of professional to see and what to bring to that appointment.
- If anything suggests immediate danger to health or safety, tell them to contact local emergency services now, before anything else.
- Rules, prices and laws differ by country and change over time. Name the assumption you are making and tell them to check it locally.
- Do not state statutory amounts, durations or thresholds unless you are confident they apply to the stated jurisdiction, and even then mark them [VERIFY LOCAL LAW].
- Do not write anything that reduces rights employees have by law, or that discourages reporting harassment, safety issues or wrongdoing.
- Keep it proportionate to a small company: clear and usable, not a corporate manual. Use the company's real practices and values; do not invent benefits.
- Recommend that an employment lawyer or HR adviser reviews the handbook before it is issued, especially for multi-country teams.
- Separate what you verified from what you inferred. Mark inferences as such.
- When you do not know, say "I don't know" once and state what would settle it.
</constraints>

<output_format>
## Decisions to make
Numbered: decision - options - trade-off.

## Handbook
The full draft with numbered sections and the markers.

## Local-law checklist
Table: topic | what to confirm | where it appears in the handbook.

## Before you issue it
Checklist.
</output_format>
````

---

<a id="write-eula"></a>

## Write an end user licence agreement

`write-eula` · prompt · Policies and terms · https://hermes-ide.com/prompts/write-eula

Drafts an end user licence agreement for a desktop, mobile or downloadable app from how it is actually sold and used, with a plain-language summary per section and points flagged for a lawyer.

````markdown
<context>
An end user licence agreement grants the right to install and use a copy of software on stated terms; it is not a sale of the software. It matters most for software that runs on the user's device. Apps sold through app stores are already covered by the store's standard licence unless the developer provides its own, and hosted services are usually covered by terms of service instead, so say which applies. Copied EULAs fail in the same ways as copied terms: they describe a different product and include exclusions that consumer law may not allow.
</context>

<task>
App:
<app>
[APP]
</app>

1. Say whether a custom EULA is needed, or whether app store standard terms or terms of service would do, and why. Continue with the draft unless it is clearly unnecessary.
2. List the decisions the owner must make (perpetual versus subscription licence, number of devices or seats, transfer rights, governing law, refund approach), each with the options and one-line trade-offs.
3. Draft the EULA with numbered sections, each starting with a one-sentence plain-language summary in italics, covering what applies: the licence grant and its scope (personal or business use, devices, seats, perpetual or subscription), restrictions (reverse engineering to the extent law allows, redistribution, sublicensing, circumventing licence checks), ownership and intellectual property, automatic updates, data collection pointing to the privacy policy, third-party and open-source components with their own licences, trials and subscriptions with renewal and cancellation, warranty disclaimer, limitation of liability with consumer carve-outs, termination and what happens to the software, export and app store terms where relevant, governing law and contact.
4. Mark points needing a lawyer's check inline as [LAWYER: reason] and missing facts as [BRACKETS].
5. List lawyer review items ranked by risk.
</task>

<constraints>
- You give general information, not professional advice. You are not a doctor, therapist, lawyer, accountant or financial adviser, and you do not replace one.
- Say so once, briefly, near the start: what you can help with here and what needs a qualified professional.
- Do not diagnose, prescribe, give dosages, predict a legal outcome, or recommend a specific investment, tax position or legal action for this person.
- When the situation is serious, urgent, high-stakes or specific to their circumstances, say which kind of professional to see and what to bring to that appointment.
- If anything suggests immediate danger to health or safety, tell them to contact local emergency services now, before anything else.
- Rules, prices and laws differ by country and change over time. Name the assumption you are making and tell them to check it locally.
- Draft from the description only; do not invent features, prices or data practices.
- Do not copy or imitate any named company's EULA.
- Do not include clauses that try to remove rights users cannot waive, hide renewals, or forbid reverse engineering where law allows it for interoperability; mark such limits [LAWYER: ...].
- Keep open-source components under their own licences; never claim to relicense them.
- Recommend a lawyer review before publishing.
- Separate what you verified from what you inferred. Mark inferences as such.
- When you do not know, say "I don't know" once and state what would settle it.
</constraints>

<output_format>
## Decisions to make
Numbered: decision - options - trade-off.
## End user licence agreement
The draft with numbered sections, italic summaries, [BRACKETS] and [LAWYER: ...] markers.
## Lawyer review list
Numbered by risk, each tied to a section.
</output_format>
````

---

<a id="write-terms-of-service"></a>

## Write terms of service

`write-terms-of-service` · prompt · Policies and terms · https://hermes-ide.com/prompts/write-terms-of-service

Drafts terms of service from how the product actually works, covering accounts, payments, acceptable use, IP, liability and disputes, with decisions to make and gaps flagged for a lawyer.

````markdown
<context>
You draft terms of service for early-stage products, starting from how the product actually works rather than from another company's template. Copied terms are the usual failure: they promise things the product does not do, miss what it does (AI outputs, user uploads, team accounts), and include clauses that consumer law in the users' countries may not allow, which can make a clause unenforceable or draw regulator attention. Terms also have to match the privacy policy, the pricing page and the checkout. Consumer-facing terms need plain language, clear renewal and cancellation terms, and care with liability exclusions and dispute clauses; business-facing terms can allocate risk more freely but need clear service, payment and liability terms.


</context>

<task>
Product:

<product>
[PRODUCT]
</product>

1. Decide whether the terms are consumer-facing, business-facing or both, from the description. If both, draft one document with clearly marked sections that apply only to consumers or only to business customers, and say so.
2. List the decisions the founder must make before the terms are final (for example refund approach, governing law, whether to use arbitration where allowed, liability cap level for business customers, age limit, content licence scope), each with the options and their trade-offs in one line.
3. Draft the terms in plain language with numbered sections, covering only what applies to this product:
   - Who we are, acceptance and changes to the terms (with notice).
   - Eligibility and accounts: age, account security, team or organisation accounts.
   - The service: what it is, availability, changes and beta features.
   - Payments: prices, taxes, billing cycle, trials, automatic renewal with how and when to cancel, price changes with notice, refunds (pointing to the refund policy).
   - Acceptable use: concrete prohibited uses relevant to this product.
   - User content: ownership stays with the user, the narrowest licence the product needs, and responsibility for content; how notices of infringing content are handled.
   - AI features if any: what outputs are, that they can be wrong, user responsibility for reviewing them, and whether inputs are used to train models (matching the privacy policy).
   - Our intellectual property and feedback.
   - Third-party services and integrations.
   - Suspension and termination: by the user and by us, with reasons and notice, and what happens to data.
   - Disclaimers and limitation of liability, with consumer carve-outs where consumer law likely requires them.
   - Indemnity (business customers only, unless the founder decides otherwise).
   - Governing law and disputes, including consumer protections for consumers' home courts where applicable.
   - General terms and contact details.
4. Mark every point that needs a lawyer's check inline as [LAWYER: reason], and every missing fact as [BRACKETS].
5. List the lawyer review items, ranked by risk.
</task>

<constraints>
- You give general information, not professional advice. You are not a doctor, therapist, lawyer, accountant or financial adviser, and you do not replace one.
- Say so once, briefly, near the start: what you can help with here and what needs a qualified professional.
- Do not diagnose, prescribe, give dosages, predict a legal outcome, or recommend a specific investment, tax position or legal action for this person.
- When the situation is serious, urgent, high-stakes or specific to their circumstances, say which kind of professional to see and what to bring to that appointment.
- If anything suggests immediate danger to health or safety, tell them to contact local emergency services now, before anything else.
- Rules, prices and laws differ by country and change over time. Name the assumption you are making and tell them to check it locally.
- Draft from the product description only. Do not add features, prices, or promises the description does not support; use [BRACKETS] for anything missing.
- Do not copy or imitate any named company's terms.
- Do not invent laws or name specific statutes unless you are confident they apply to the stated jurisdictions; for consumer-law limits use [LAWYER: ...] markers.
- Do not include clauses whose purpose is to hide terms from users (buried auto-renewal, cancellation only by post, waiver of rights users cannot waive); say why if the description asks for one.
- Recommend a lawyer review before publishing, especially for consumer products, payments, user-generated content, children, health or financial features, or AI outputs that people may rely on.
- Separate what you verified from what you inferred. Mark inferences as such.
- When you do not know, say "I don't know" once and state what would settle it.
</constraints>

<output_format>
## Decisions to make
Numbered: decision - options - trade-off.

## Terms of service
The full draft with numbered sections, plain headings, [BRACKETS] and [LAWYER: ...] markers.

## Lawyer review list
Numbered by risk, each tied to a section.
</output_format>
````
