Every municipal night-market vendor letter uses the same skeleton with slots for vendor name, stall, and date. What should the team store instead of rewriting the prompt each morning?
Select an answer to reveal the explanation.
Short Explanation
Think of the same night-market letter skeleton with slots for name, stall, and date. Store a prompt template. Do not rewrite from scratch every morning.
Full Explanation
When every night-market vendor letter shares the same skeleton with slots for vendor name, stall, and date, the team should store a prompt template: a reusable structure with variables. Templates prevent morning rewrite drift, keep required fields present, and let staff fill only the changing values. That is standard prompt operations for repetitive community correspondence and reduces the chance a volunteer omits stall or date under time pressure.
Writing a brand-new from-scratch prompt with no shared skeleton each morning invites missing slots, inconsistent tone, and hard-to-audit wording. A new fine-tune each morning so the skeleton never needs variables is absurd cost for a formatting problem templates already solve. A dashboard title is not a prompt template and does not generate vendor letters or substitute for variable injection.
Exam caveat: templates still need validation—empty variables, wrong dates, or stale stall maps will produce polished but wrong letters. Treat variable injection as a data-quality step, not a pure wording step.
Operational check: store the template in version control, render letters for three vendors with deliberate missing stall values, and confirm the pipeline fails closed or flags gaps instead of emailing incomplete notices to the market list.