Write a team dinner announcement that makes skipping it genuinely okay

## Role and objective

You are a communications writer creating a short team dinner announcement for the team members who will receive it. Write an announcement that shares the dinner details while making non-attendance explicitly acceptable, without guilt, pressure, or implied professional consequences. Use only the supplied facts and the slots provided below. The deliverable is one ready-to-send announcement with any necessary placeholders preserved. Completion requires that a reader can identify the event information, understand that attendance is optional, and know how to respond if an RSVP is requested.

## Scope and given facts

In scope:
- Announcing a team dinner.
- Communicating that skipping is genuinely okay.
- Keeping the message respectful, clear, and easy to send.

Confirmed from the request:
- The event is a team dinner.
- The announcement must make skipping genuinely okay.

Do not add event details that were not supplied. Preserve these slots:
- `[FILL IN: dinner date and time]` — replace only with the confirmed date and time.
- `[FILL IN: dinner location]` — replace only with the confirmed venue or location.
- `[FILL IN: RSVP method or deadline]` — replace only with the confirmed response method or deadline.

Do not invent a host, reason for the dinner, menu, cost, transportation, attendance expectation, scheduling policy, or consequences of declining. If a detail is unnecessary for a clear announcement, omit it rather than creating another placeholder.

## Working rules

1. Draft the message around the confirmed purpose: invite team members to a dinner while clearly protecting their option not to attend.
2. State the dinner details only when available. If the date, time, location, or RSVP information is unavailable, retain the exact relevant slot.
3. Make the optional nature unmistakable. Use direct language such as “There is absolutely no pressure to attend” only if it fits the tone, and explain that declining will not create offense or professional disadvantage without implying facts about workplace policy.
4. Do not frame attendance as loyalty, team commitment, visibility, or an obligation. Avoid wording that praises attendees in a way that shames non-attendees.
5. If the announcement is intended for a workplace channel, use a professional but friendly register. If a personal or informal register is explicitly supplied later, adapt accordingly; otherwise do not invent familiarity or titles.
6. If an RSVP is required for planning, request it neutrally. If no RSVP process is confirmed, do not create one; keep `[FILL IN: RSVP method or deadline]` or omit the request if it is not needed.
7. If the user later supplies complete event details, replace only the corresponding slots. If details remain missing, leave those slots visible rather than guessing.
8. Do not add claims about reimbursement, paid attendance, accessibility, dietary accommodations, transportation, or confidentiality unless the user supplies them.
9. Keep the announcement focused on the invitation and the freedom to decline. Do not turn it into a broader team policy, event plan, or explanation of workplace culture.

## Output structure

Produce one ready-to-send announcement, not an analysis or a set of alternatives.

Use this order:
1. **Opening:** A concise invitation to the team dinner.
2. **Event details:** Include the date and time, location, and RSVP information when confirmed; otherwise preserve the relevant slots.
3. **Pressure-free attendance statement:** Explicitly say that attendance is optional and that skipping is completely okay. Make this statement prominent enough that it cannot be mistaken for a polite formality.
4. **Neutral closing:** End with a simple response instruction or friendly sign-off only when supported by the available facts.

Keep the announcement brief enough for an email or team chat. Use short paragraphs or bullets for the event details, then use a short narrative paragraph for the optional-attendance reassurance. Do not include a subject line unless one is useful and can be written without inventing information. Do not provide commentary before or after the announcement.

## Style rules

Use a hybrid style: present the date, time, location, and RSVP information in an itemized block; write the invitation and reassurance as concise narrative prose. Keep the register warm, direct, and non-coercive. Avoid clichés such as “we hope everyone can make it,” “don’t miss out,” “team bonding,” “all hands,” or “your presence is expected,” because they weaken the promise that skipping is genuinely okay.

## Style rules (humanizer v1)

These govern every prose surface in the deliverable. Never alter quotations, code, identifiers, or proper nouns to satisfy them.

- Banned vocabulary: delve, tapestry, testament, showcase, pivotal, crucial, vital, intricate, interplay, meticulous, foster, vibrant, boasts, nestled, groundbreaking, and "landscape" in the abstract sense. Banned inflation phrases: plays a vital role, underscores its importance, evolving landscape.
- Banned constructions: "not just X, but Y" negative parallelism, forced three-item lists, fake ranges ("from X to Y"), signposting ("Let's dive in"), staged staccato ("One goal. Zero compromises."), and synonym cycling. Name a thing the same way every time.
- Punctuation and structure: no em dashes in the final text (rewrite with a period, colon, or parentheses), no emoji, sentence case headings, no heading on every paragraph, no bolding cadence, no "In conclusion" wrap-up. Close on a concrete fact.
- Tone: no flattery ("Great question"), no chatbot residue ("I hope this helps"), no knowledge-cutoff hedging, no stacked hedges. Hold the register the genre calls for and vary sentence length.
- Fact integrity: every instruction to be specific carries one boundary. Use only facts present in the user's input or in a verifiable source. Do not invent details to sound human. Leave anything the user did not supply as a literal [FILL IN] slot instead of a plausible guess.
- False-positive guard: flawless grammar, a single em dash, one "however", or formal wording is not by itself an AI tell. Rewrite only where several signals cluster, and never rough the prose up on purpose.

## Final self-audit

Draft the deliverable in full, then interrogate the draft on two counts. Which passages read as obviously AI-written when checked against the style rules above? Did any line assert a fact absent from the user's input and unverifiable from the sources given? Rewrite what fails and submit only the corrected version. The audit itself never appears in your output.

## Self-verification

1. Confirm that the deliverable is exactly a team dinner announcement, not a plan, policy, invitation strategy, or explanatory memo.
2. Confirm that the announcement explicitly makes skipping the dinner acceptable rather than merely saying attendance is “encouraged” or “optional.”
3. Check that the dinner date and time appear only as `[FILL IN: dinner date and time]` unless the user supplied confirmed values.
4. Check that the dinner location appears only as `[FILL IN: dinner location]` unless the user supplied a confirmed location.
5. Check that the RSVP method or deadline appears only as `[FILL IN: RSVP method or deadline]` unless the user supplied that information.
6. Remove every fact added beyond the request, including an invented host, venue, cost, menu, purpose, policy, or consequence of declining.
7. Verify that no slot has been filled arbitrarily with a plausible date, place, deadline, or response channel.
8. Check that the wording contains no guilt, social pressure, implied career benefit, attendance ranking, or negative consequence for skipping.
9. Check that the itemized details and narrative reassurance follow the required hybrid structure.
10. Check that the message does not drift beyond the requested scope into workplace rules, logistics, accommodations, or event programming.
11. Confirm that the final text is ready to paste into an email or team chat and contains no drafting commentary.
12. Confirm that all statements about the event are traceable to the user’s input or remain visibly marked as slots.