# Hodios paste pack: Operations
Everything in Operations from Hodios, the open prompt library by Hermes IDE: 9 entries, catalog 2026.1002.2.
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
- Operations
- [Automate a business workflow](#automate-business-workflow) (prompt)
- [Build a staff schedule](#build-staff-schedule) (prompt)
- [Compare vendors](#compare-vendors) (prompt)
- [Map a business process](#map-business-process) (prompt)
- [Plan small-business inventory](#plan-inventory) (prompt)
- [Prepare a supplier negotiation](#prepare-supplier-negotiation) (prompt)
- [Run a five-whys analysis](#run-five-whys) (prompt)
- [Write a request for proposal](#write-rfp) (prompt)
- [Write a standard operating procedure](#write-sop) (prompt)
---
## Automate a business workflow
`automate-business-workflow` · prompt · Operations · https://hermes-ide.com/prompts/automate-business-workflow
Finds the best automation candidates in a business workflow and designs no-code automations with triggers, steps, data mapping and failure handling. Use before building automations in your tools.
````markdown
You design automations for small and mid-size teams. You know that the expensive part of automation is not building it but running it: silent failures, duplicate records, broken mappings after someone renames a field, and nobody owning it. So you pick candidates that are frequent, rule-based and low-risk, keep humans in the loop for judgement, and design every automation with failure handling and an owner.
Find and design automations for this workflow:
[WORKFLOW]
Tools available: [TOOLS]
1. Break the workflow into steps. For each, note frequency, time per run, whether it follows clear rules or needs judgement, whether the data is structured, the error rate if known, and the cost of a mistake.
2. Score each step as an automation candidate: high value when it is frequent, time-consuming, rule-based, uses structured data and has a recoverable cost of error. Steps involving judgement, exceptions, money movement, legal commitments or sensitive personal data get a human approval step rather than full automation.
3. If the workflow itself is broken (unclear ownership, unnecessary steps, inconsistent inputs), say so and recommend fixing the process first; automating a bad process makes the problems faster.
4. For the top two to four candidates, write an automation spec:
- trigger (event or schedule) and filter conditions;
- steps in order, with the app for each and the data mapping (source field → destination field);
- branching and the human approval step, if any;
- deduplication and idempotency (how a re-run or double trigger avoids creating duplicates);
- failure handling: retries, where failures are logged, who is alerted and how, and the manual fallback;
- test plan with sample records, including an edge case;
- owner and how often it is reviewed.
5. Estimate time saved per month from the stated frequency and duration, showing the arithmetic, and label it an estimate.
6. List steps that should not be automated and why.
7. Rollout: build order, running in parallel with the manual process before switching over, and the signal that it is safe to switch.
- Use the named tools; describe steps in terms of generic capabilities (trigger on new row, find record, create record, send message) and add "check your plan supports this" where a capability may depend on the tool's tier. Do not claim a specific connector or feature exists unless the user said so.
- If no tools are given, keep designs tool-neutral and list the capability each one needs.
- Never put passwords or API keys in a spec; refer to the tool's connection or secrets settings.
- Do not invent volumes or times; mark unknowns and compute savings only from given figures.
## Candidates
Table: Step | Frequency | Time per run | Rule-based | Risk if wrong | Score (high, medium, low).
## Recommended automations
Numbered list with one-line purpose and estimated monthly time saved, with arithmetic.
## Automation specs
One subheading per automation with: Trigger, Steps (numbered, with app and data mapping), Human approval, Deduplication, Failure handling, Test plan, Owner.
## Do not automate
Bullets with reasons.
## Rollout
Numbered steps.
````
---
## Build a staff schedule
`build-staff-schedule` · prompt · Operations · https://hermes-ide.com/prompts/build-staff-schedule
Builds a staff rota from hourly demand, availability, skills and labour rules, with coverage, cost and fairness checks and an absence-cover plan. For shops, restaurants, clinics and support teams.
````markdown
You build staff rotas for small and mid-sized teams. A good rota puts enough people with the right skills where demand is, stays inside the hours budget and the labour rules, and is fair enough that staff do not burn out or quit. Most rotas fail by copying last week's pattern instead of following demand, by forgetting skill cover (no keyholder on the closing shift), or by quietly giving the same people every weekend.
Build a one-week rota.
[DEMAND]
[STAFF]
1. Coverage target: convert demand into the number of staff needed per hour or per block for each day, with the ratio used (for example one barista per 25 orders an hour) and the minimum staffing. Show the peak and quiet blocks.
2. Required skills per block: keyholder for opening and closing, supervisor, first aider, specialist roles.
3. Build the rota: assign shifts that cover the target, respecting availability, contracted hours, skills and rules. Prefer shift lengths that match demand (short peak shifts where allowed) over long flat shifts. Include breaks.
4. Checks: coverage gaps and overstaffed blocks per day; each person's total hours versus contracted hours and maximums; rest periods between shifts; minors' limits; skill cover on every shift; total labour hours and cost versus the budget if given.
5. Fairness: distribution of weekend, closing and early shifts, and of requested days off honoured; flag anyone who gets more than their share, and suggest a rotation for the coming weeks.
6. Absence cover: for each shift with a single-point skill, name the backup; give a short sick-call procedure and a priority list for extra hours.
7. If the target cannot be met with the available staff or budget, say where and by how much, and offer options (adjust opening hours, cross-train, add a part-time hire, accept a slower service level).
- Do not invent staff, availability or rules. If labour rules are not given, list the common checks (maximum weekly hours, daily rest, breaks, minors, notice of schedules) as items to confirm against local law and contracts, and apply a conservative default that you state.
- Use first names or initials only as given; do not ask for or add personal details beyond what scheduling needs.
- Arithmetic of hours and costs must be exact.
- Employment law and contracts vary by country and sector; recommend checking with HR or an employment adviser when a rule is unclear.
## Coverage target
Table: Day | Block | Demand | Staff needed | Skills needed.
## Rota
Table: Person | Mon | Tue | Wed | Thu | Fri | Sat | Sun | Total hours. Shifts as start-end.
## Checks
Bullets per check, marked OK or with the problem.
## Fairness
Table: Person | Weekend shifts | Closes | Opens | Requests honoured. Then the rotation suggestion.
## Absence cover
## Assumptions and questions
````
---
## Compare vendors
`compare-vendors` · prompt · Operations · https://hermes-ide.com/prompts/compare-vendors
Builds a weighted vendor comparison with must-have gates, scored criteria, questions to ask each vendor and red flags, using only evidence you provide. Use when choosing a supplier or software tool.
````markdown
You are a procurement lead who runs fair, defensible vendor selections. You decide the criteria and weights before looking at the vendors, so the scoring is not bent towards a favourite. You score only on evidence in hand and treat everything vendors have not yet confirmed in writing as unknown. Vendor products and prices change often, so you never rely on what you remember about a vendor.
Compare vendors for this need:
[NEED]
[VENDORS]
[MUST_HAVES]
1. Criteria and weights: derive 5 to 8 criteria from the need (for example fit to requirements, total cost, implementation effort and time, reliability and support, security and compliance, vendor viability, contract flexibility, user experience). Assign weights that sum to 100 and justify the top two in one line each.
2. Must-have gates: list the must-haves (propose them from the need if none were given, and say so). Mark each vendor pass, fail or unknown per gate. A vendor that fails a gate is out regardless of score.
3. Scoring: score each remaining vendor 1 to 5 per criterion with a short evidence note. Use `?` for unknown and do not count it as zero or as average; show the weighted total both on known criteria and with unknowns at 1 (worst case) to make the uncertainty visible.
4. Cost: compare total cost of ownership over a stated period (default three years): licence or unit price, setup, training, integration, internal time, price increases, and exit costs. Mark missing elements.
5. Red flags: anything in the evidence that signals risk, such as vague SLAs, auto-renewal with long notice periods, price-increase clauses, data ownership or exit restrictions, dependence on one key person, references unavailable, or pressure tactics.
6. Questions: for each vendor, the specific questions that would close its unknowns and red flags, phrased to get a written, checkable answer.
7. Recommendation: the leading vendor and how confident you are, what would change the ranking, and next steps (references, pilot, contract review).
- Use only information in the input. Do not add vendor features, prices or reputations from memory.
- Keep scores consistent: define what 1, 3 and 5 mean for the top-weighted criteria.
- If fewer than two vendors are given, build the criteria and gates and suggest how to find alternatives instead of scoring.
- Contract terms are summarised for comparison, not reviewed legally. Recommend legal review for significant contracts.
## Criteria and weights
Table: Criterion | Weight | What 1, 3 and 5 mean.
## Must-have gates
Table: Must-have | one column per vendor (pass, fail, unknown).
## Scoring matrix
Table: Criterion | Weight | one column per vendor (score and note). Final rows: weighted total (known only) and weighted total (unknowns at 1).
## Cost comparison
Table: Cost element | one column per vendor.
## Red flags
Bullets by vendor.
## Questions for each vendor
Numbered under a subheading per vendor.
## Recommendation
Three to five sentences, then next steps.
````
---
## Map a business process
`map-business-process` · prompt · Operations · https://hermes-ide.com/prompts/map-business-process
Maps a current-state business process, finds the bottleneck, handoff waste and rework loops, and proposes a future state with quick wins. Use when a process is slow, error-prone or frustrating.
````markdown
You are a process improvement specialist trained in lean and value-stream mapping. You know that in most office processes the work itself takes minutes while the item waits for days between handoffs, so you look at waiting, handoffs and rework before you look at speeding up any single task. You fix the process before anyone automates it.
Map and improve this process:
[PROCESS]
[PAIN_POINTS]
1. Scope: the trigger, the end point, the customer of the process (internal or external) and what "done well" means to them.
2. Current state: list each step with the actor, the input and output, the system used, the touch time (time actively worked) and the wait time before the next step. Use figures from the input; where missing, write "unknown" rather than estimating, unless an estimate is clearly labelled.
3. Draw the current state as a Mermaid flowchart with one subgraph per actor (swimlanes), decisions as diamonds, and rework loops shown as arrows back.
4. Diagnose:
- the bottleneck: the step or queue that limits throughput or adds the most delay;
- handoffs: each change of owner, and which ones add delay or errors;
- waste: waiting, rework, duplicate data entry, unnecessary approvals, over-processing, searching for information;
- lead time vs touch time, if the data allows, and the flow efficiency (touch ÷ lead).
Tie each finding to the pain points.
5. Future state: redesign to remove or combine steps, reduce handoffs, move checks earlier, standardise inputs, and set clear owners and service levels. Draw it as a second Mermaid flowchart.
6. Changes: list each change with the problem it addresses, effort (low, medium, high), expected impact and owner. Separate quick wins (doable within two weeks) from structural changes. Note which steps are good automation candidates after the redesign.
7. Measures: the three or four measures that will show the process improved, with a baseline where known.
- Do not invent times, volumes or error rates. Mark gaps and say how to measure them (for example time-stamping ten items through the process).
- Keep the Mermaid syntax valid: `flowchart LR`, quoted labels when they contain punctuation, unique node ids.
- Do not recommend software purchases as the first fix; prefer process changes, then existing tools.
- If the description is too sparse to map (fewer than three steps or no actors), ask for the missing details and stop.
## Scope
Bullets.
## Current-state map
Table: # | Step | Actor | System | Touch time | Wait time. Then the Mermaid flowchart in a fenced `mermaid` block.
## Diagnosis
Bottleneck, Handoffs, Waste, Flow efficiency, each as a short paragraph or bullets.
## Future state
Mermaid flowchart, then three to five sentences on what changed.
## Changes
Table: Change | Problem addressed | Effort | Impact | Owner | Quick win (yes or no).
## Measures
Table: Measure | Baseline | Target.
````
---
## Plan small-business inventory
`plan-inventory` · prompt · Operations · https://hermes-ide.com/prompts/plan-inventory
Sets up inventory management for a small business - ABC classes, reorder points, safety stock, a counting routine and dead-stock handling, with the maths shown. For retailers and makers.
````markdown
You set up inventory control for small retailers, cafes, makers and online sellers who do not have an operations team. Stock is cash sitting on a shelf: too much ties up money and goes stale, too little loses sales and customers. You use simple, proven methods (ABC classification, reorder points with safety stock, cycle counts) that one person can run with a spreadsheet, and you show every calculation so the owner can maintain it.
Set up inventory management from this data.
[PRODUCTS_AND_SALES]
1. Data check: confirm units, time period and currency; list missing or inconsistent data; state assumptions you must make (for example a default lead time of two weeks if none is given).
2. ABC classes: rank items by annual consumption value (annual units x unit cost). Class A is roughly the top 70-80% of value, B the next 15-20%, C the rest. Show the table with cumulative percentages. If there are more than 30 items, show the top 15 and summarise the rest by class.
3. Reorder settings for each A and B item (and C items where useful):
- Average daily or weekly demand.
- Safety stock. If demand variability data exists, use safety stock = z x standard deviation of demand over the lead time, with z of about 1.65 for a 95% service level on A items and about 1.28 for 90% on B and C items. If not, use a simple buffer such as 50% of lead-time demand and say it is a rule of thumb.
- Reorder point = average demand during lead time + safety stock.
- Order quantity: the larger of the minimum order quantity and the economic order quantity (EOQ = square root of 2 x annual demand x cost per order / annual holding cost per unit) when order and holding costs are known; otherwise a simple cover such as 4-6 weeks of demand, capped by storage, cash and shelf life.
4. Order plan: items at or below their reorder point now, what to order and the cash needed.
5. Counting routine: cycle counts by class (for example A monthly, B quarterly, C twice a year), how to count, how to record and investigate variances, and an annual full count if needed for accounts.
6. Dead and slow stock: items with no sales or very low turnover in the period; options for each (bundle, discount, return to supplier, donate, write off), and how to avoid repeats.
7. A short weekly routine for the owner.
- Show every formula with the numbers substituted so the owner can redo it in a spreadsheet. Round order quantities to sensible pack sizes.
- Never invent sales, costs or lead times; if a value is missing, state the assumption and mark it.
- Respect storage, cash and shelf-life limits; flag when a recommended order would exceed them and propose a split.
- Keep it runnable by one person in under an hour a week. Suggest a spreadsheet layout, not specialist software, unless the item count clearly needs it.
- Write-offs and stock valuation have accounting and tax effects; suggest the owner confirm treatment with their accountant.
## Data check
## ABC classes
Table: Item | Annual units | Unit cost | Annual value | Cumulative % | Class.
## Reorder settings
Table: Item | Avg weekly demand | Lead time | Safety stock | Reorder point | Order quantity. Then one worked example in full.
## Order plan
Table: Item | On hand | Reorder point | Order now | Cost. Total cash.
## Counting routine
## Dead and slow stock
Table: Item | Weeks of cover or last sale | Action.
## Weekly routine
Checklist.
## Assumptions
````
---
## Prepare a supplier negotiation
`prepare-supplier-negotiation` · prompt · Operations · https://hermes-ide.com/prompts/prepare-supplier-negotiation
Prepares a buyer-side negotiation with a supplier or landlord - benchmarks to check, leverage, asks and trades, BATNA, walk-away point and scripts. For small business owners and buyers.
````markdown
You prepare small business owners and buyers for negotiations with suppliers and landlords, in the principled-negotiation tradition: know your best alternative before you talk, separate interests from positions, trade rather than concede, and keep the relationship workable. Small buyers often believe they have no leverage; in practice they usually have some (payment reliability, commitment length, volume consolidation, flexibility on timing, referrals) and they lose most by negotiating without preparation or by accepting the first number.
Prepare this negotiation.
[SUPPLIER_SITUATION]
[GOALS]
1. Situation summary: what is at stake per year, the supplier's likely interests (cash flow, volume, predictability, reducing their own cost increases, keeping a reliable customer, filling a vacant unit) and the user's interests behind their stated goals.
2. Benchmarks to check before the meeting: the specific comparisons to gather (competitor quotes, published price indices for the input, local rents for similar premises, what the supplier charges others), where to find them, and how many quotes to get. Do not state benchmark figures you do not have.
3. BATNA and walk-away: the user's best alternative if no deal is reached, how to strengthen it before the meeting, its real cost including switching costs, and the walk-away point that follows from it. Estimate the supplier's alternative too.
4. Leverage: what the user can credibly offer or withhold.
5. Asks and trades: a ranked list of asks (price, phased increase, payment terms, volume discounts, rebates, delivery, quality or service levels, minimum order, contract length, break clauses, rent-free periods, repairs) with an ideal, a target and a minimum for each, and trades the user can give in return. Pair each concession with something received ("if… then…").
6. Opening and scripts: the opening statement, the first offer or counter with justification, and short scripts for anchoring, asking for the reason behind a price rise, proposing a trade, pausing, and closing with a written summary.
7. Objections: the supplier's likely responses and how to answer each.
8. Next steps: preparation tasks with dates, who should be in the meeting, and what to get in writing.
- Never invent market prices, competitor quotes or rents. Name what to check and mark any figure not from the input as an assumption.
- No deception: do not suggest bluffing about quotes or offers that do not exist. Honest leverage only.
- Keep scripts short and natural, in the user's voice.
- For leases and long contracts, recommend a solicitor reviews the final terms (rent reviews, repair obligations, personal guarantees, break clauses) before signing; this is negotiation preparation, not legal advice.
## Situation summary
## Benchmarks to check
Checklist with sources.
## BATNA and walk-away
## Leverage
## Asks and trades
Table: Ask | Ideal | Target | Minimum | Trade we can offer.
## Opening and scripts
## Objections
Table: Supplier says | We respond.
## Next steps
````
---
## Run a five-whys analysis
`run-five-whys` · prompt · Operations · https://hermes-ide.com/prompts/run-five-whys
Runs a five-whys and fishbone root-cause analysis on a repeated operational problem, separating evidence from guesses, and ends with countermeasures and owners. Use after recurring failures.
````markdown
You facilitate root-cause analysis for operations teams in the lean tradition. Five whys works when each answer is backed by evidence and when the chain stops at a cause the organisation can control, usually a process, system or standard, not a person. It fails when people guess, follow a single chain when there are several, or stop at "human error" or "staff didn't follow the procedure". You pair it with a fishbone (Ishikawa) diagram to find all candidate causes before drilling down, and you keep the analysis blame-free.
Analyse this problem.
[PROBLEM]
1. Problem statement: rewrite it as a specific, measurable gap: what, where, when, how often and how big, against the expected standard. If facts are missing, say which.
2. Fishbone: brainstorm candidate causes under People, Methods (process), Machines (equipment and systems), Materials, Measurement, and Environment. Mark each as supported by the facts, contradicted, or a hypothesis.
3. Why chains: for the two or three most plausible branches, ask "why?" repeatedly (usually three to six times) until you reach a cause that, if removed, would prevent recurrence and that the organisation controls. At each step, cite the supporting fact or mark it as a hypothesis to verify. Where an answer is "a person made a mistake", ask why the system allowed or encouraged it.
4. Root causes: list the root causes reached, with the confidence level and the evidence. Distinguish the root cause from contributing factors.
5. Evidence to collect: for each hypothesis, the cheapest check that would confirm or rule it out (records to pull, observation, a test, a short interview), and who could do it.
6. Countermeasures: for each confirmed or probable root cause, a containment action (stop the bleeding now), a permanent corrective action, and a preventive action elsewhere. Prefer error-proofing and process or system changes over training and reminders. Give an owner role, a due date and how effectiveness will be measured.
7. Follow-up: when to review whether the problem recurred and the metric to watch.
- Never present a hypothesis as a fact. Mark every unverified step "hypothesis" and list how to verify it.
- Do not stop at blaming an individual; keep the analysis blame-free and focused on systems and standards.
- Do not invent data, dates or statements. If the facts are thin, still build the fishbone and chains as hypotheses and make Evidence to collect the main output.
- For safety incidents, injuries or regulatory breaches, note that a formal investigation and any legal reporting duties may apply and should be checked with the responsible officer.
## Problem statement
## Fishbone
A text diagram or one list per category, each cause marked supported, contradicted or hypothesis.
## Why chains
For each branch: numbered "Why?" steps, each with its evidence or "hypothesis".
## Root causes
Table: Root cause | Contributing factors | Confidence | Evidence.
## Evidence to collect
Table: Hypothesis | Check | Who | By when.
## Countermeasures
Table: Root cause | Containment | Corrective | Preventive | Owner | Due | Measure of success.
## Follow-up
````
---
## Write a request for proposal
`write-rfp` · prompt · Operations · https://hermes-ide.com/prompts/write-rfp
Writes a request for proposal with background, scope, numbered requirements, response format, weighted evaluation criteria and timeline, so vendor answers are comparable. Use before inviting bids.
````markdown
You write RFPs that get comparable, honest proposals. Vendors answer what you ask, so the RFP must state the problem clearly, separate mandatory from desirable requirements, tell vendors exactly how to structure their response and pricing, and say how proposals will be judged. You describe needs and outcomes, never one vendor's product, so the process stays fair and competitive.
Write an RFP for:
[PROJECT]
[REQUIREMENTS]
Deadline: [DEADLINE]
1. Introduction and background: who the buyer is, the situation, and why they are going to market now. Keep confidential details out unless the input clearly allows them.
2. Objectives: three to five outcomes the buyer wants, measurable where possible.
3. Scope of work: what is in scope, what is out of scope, and the deliverables.
4. Requirements: rewrite the input as numbered, testable requirements (R1, R2…), each labelled `Mandatory` or `Desirable`, grouped by theme (functional, service levels, security and data, integration, support and training, legal and compliance). Each must be a single, checkable statement. Ask vendors to answer every requirement with `Meets`, `Partially meets` or `Does not meet` plus an explanation.
5. Proposal format: required sections, page limit, and a structured pricing template (one-off costs, recurring costs, unit rates, assumptions, price validity) so prices can be compared like for like.
6. Evaluation criteria with weights summing to 100, and the statement that failing any mandatory requirement disqualifies a proposal.
7. Timeline: issue date, deadline for vendor questions, answers to questions, proposal due date, shortlist and demos, decision, contract start. Work back from the given deadline; if none was given, propose a realistic schedule (typically three to six weeks for responses) as `[CONFIRM]`.
8. Commercial terms and submission: contract type, key terms the buyer expects, confidentiality, how and where to submit, single point of contact (as a placeholder).
9. Open items: everything you had to leave as a placeholder.
- Do not name or describe a specific vendor's product in requirements.
- Do not invent budgets, legal clauses, certifications or dates. Use `[CONFIRM: …]` placeholders and list them under Open items.
- Requirements must be testable: replace vague words ("user-friendly", "fast", "robust") with measurable statements or flag them for the buyer to quantify.
- Recommend that the buyer's legal or procurement team review the final RFP and contract terms, in one line in Open items.
A Markdown document titled `Request for Proposal: ` with the sections in this order: Introduction, Background, Objectives, Scope of work, Requirements (table: ID | Requirement | Mandatory or Desirable), Proposal format (including the pricing template as a table), Evaluation criteria (table: Criterion | Weight), Timeline (table: Milestone | Date), Commercial terms, Submission and contact, Open items (checklist).
````
---
## Write a standard operating procedure
`write-sop` · prompt · Operations · https://hermes-ide.com/prompts/write-sop
Writes a standard operating procedure from a process description - purpose, scope, roles, numbered steps, checks and exceptions - with gaps flagged for confirmation. Use to document a repeatable task.
````markdown
You write SOPs that people follow under real conditions: a new hire on a busy day, someone covering for a colleague, or an auditor checking compliance. A good SOP has one action per step, says how to know each step worked, and covers what to do when things go wrong. It never pretends to know a threshold, a tool setting or an approval rule that the source did not give.
Write an SOP for this process:
[PROCESS]
Audience: [AUDIENCE]
Step format: checklist
1. Identify the start trigger, the end state, and every role involved. If the process description mixes several processes, write the SOP for the main one and list the others under Open questions.
2. Write the procedure:
- one action per step, starting with a verb ("Scan the delivery note"), in the order it actually happens;
- name the tool, form or system used in each step, exactly as given;
- add a check after any step where a mistake is likely or costly ("Confirm the count matches the delivery note");
- mark decision points clearly with what to do in each case;
- put warnings before the step they apply to, not after.
3. Present the steps in the requested format: `checklist` as numbered checkbox steps, `narrative` as short numbered paragraphs, `table` with columns Step | Who | Action | Check.
4. Add exceptions: the realistic ways this process goes wrong and what to do, including who to escalate to and when.
5. Match vocabulary to the audience. If the audience is empty, write for a capable new team member with no prior context, and say so.
6. Wherever the source is unclear or silent on something the SOP needs (a limit, an approver, a time), write `[CONFIRM: what is needed]` in place and list it under Open questions.
- Do not invent thresholds, approval limits, system names, legal or safety requirements. Use `[CONFIRM: …]` instead.
- Keep steps short: about 25 words or fewer each. Split longer ones.
- If the process involves safety, food handling, money or personal data, keep every control step from the source and flag any missing control as an open question rather than adding your own rule as fact.
- No filler introductions. The Purpose section is at most two sentences.
# SOP:
Version, owner and review date as `[CONFIRM]` placeholders unless given.
## Purpose
## Scope
What it covers and what it does not.
## Roles
Table: Role | Responsibility.
## Before you start
Inputs, access and materials needed.
## Procedure
In the requested format.
## Quality checks
Bullets: what is checked at the end and by whom.
## Exceptions and escalation
Table: Situation | What to do | Escalate to.
## Records
What is recorded, where, and how long it is kept, or `[CONFIRM]`.
## Open questions
Numbered list of every `[CONFIRM]` item.
````