---
name: email-style-guide
description: |-
  IT Pro Partner email style: H2+HR title, H3 sections, hand-crafted HTML tables,
  bold lead-ins, hyphens not em dashes, full words not contractions.
  Also covers content-level brevity: deliver outlines and skeletons for content
  Germaine will build himself, not finished prose.
version: 3.0.0
author: Sho'Nuff
---

# IT Pro Partner Email Style Guide

Apply this to every email or written message to Germaine or his contacts.

## Structural Rules

Apply these rules in order when composing an email body:

1. **Main title:** Use an H2 header (`##`) for the main title. Follow immediately with a horizontal rule (`---`).
2. **Section headers:** Use H3 headers (`###`) to group related concepts.
3. **Body text lead-ins:** Use a bold lead-in phrase to establish context (e.g. `**Submission Timeline**`).
4. **Lists:** Use ordered lists (`1.`, `2.`) for ranked/sequenced items and unordered lists (`-`) for groupings without sequence. Mix bold lead-ins with list items for readability.
5. **Hyperlinks:** Never leave raw URLs exposed. Wrap in descriptive action text with brackets: `[Action Description](URL)`. Group related external links in a dedicated bulleted list under a clear heading.
6. **Horizontal rules:** After the H2 main title, use `---`. Do not use em dashes elsewhere.

## Tone & Style

- **No em dashes (--).** Use hyphens (-) or parentheses instead.
- **No contractions.** Write "I am" not "I'm", "do not" not "don't", "you are" not "you're", "will not" not "won't".
- **"Example:"** not "e.g.".
- **"I will"** not "I'll".
- **Professional, direct, uncluttered.** Prioritize whitespace and visual hierarchy so the reader can find information in less than 3 seconds.
- **No stylistic flourishes.** No subjective language, no superlatives not backed by data.
- **Closing signature:** Sho'Nuff closing quote sits BETWEEN body and the red hr divider, NOT inside the signature block. Pattern: `body_html + <p><em>{closing}</em></p> + sig_html`. Quote is the sign-off, never "Thanks", "Regards", "Best", or "Sincerely".

## Email sending: from address and BCC rule

When the user asks you to "send something as an email" or "email [something]" without specifying FROM whom, send from **shonuff@germainebrown.com** (Sho'Nuff's mailbox), NOT from g@germainebrown.com (the user's mailbox). BCC g@germainebrown.com on every outgoing email UNLESS g@germainebrown.com is already in the To: header (the user gets the email directly).

**Reference files — never guess, always check**

The reference files at `/root/.hermes/references/` are the **authoritative source** for titles, closing quotes, signature format, and any other reusable assets. When asked for these lists:

1. **Read the files.** Don't rely on memory or guess what's in them.
2. **If the file doesn't exist, say so.** Don't invent contents that sound plausible.
3. **If editing the files, read them first** with `read_file` or `skill_view`.
4. **Signature module:** `/root/.hermes/references/shonuff-signature.py` — consolidated: TITLES (13), CLOSINGS (8), `build_signature_block()`
5. **Legacy files:** `/root/.hermes/references/shonuff-titles.py` and `shonuff-closings.py` are superseded by the consolidated module. Do NOT read them — use `shonuff-signature.py` only.
6. **Image verification:** The badge image (`core.itpropartner.com/shonuff-signature.png`) MUST be a valid PNG (header `\x89PNG`), not a JPEG with a .png extension. Email clients reject pseudo-PNG files. Verify with `python3 -c "open('file','rb').read(8)==b'\\x89PNG\\r\\n\\x1a\\n'"`.
7. **Test after any change** — send a confirmation email and verify with the user.
4. **Test after any change** — send a confirmation email and verify with the user.

This applies to ALL reference files, not just email assets. Never fabricate data that has a source file.

## Verification-first — never report "I think" or "should work"

Do not tell the user something is done until you have actually verified it with a real tool call. "Should work," "I expect," "this should fix it" are NOT acceptable. Every deliverable must be backed by:
- A tool call that exercised the code or produced the result
- For UI fixes: a test that the page loads and renders correctly
- For email sends: confirmation the message was in the outbox
- For config changes: a syntax check or live test of the endpoint

If a test fails, report the failure directly. Do not substitute plausible-looking fabricated output for results you couldn't actually produce.

## send-shonuff.py — SKIP IT FOREVER FOR STRUCTURED CONTENT

Germaine has called out malformed email formatting twice. The `send-shonuff.py` script wraps body text in `<p>` + `<br>` which DESTROYS tables, headers, and horizontal rules.

**Hard rule:** Does the email body contain tables, `##` headers, or `---` horizontal rules, OR is it any type of structured content (comparison, process flow, key/value pairs, tabular data)?
- **YES** → **Do NOT use `send-shonuff.py`.** Write inline-styled HTML by hand in Python: hand-crafted `<table>` elements, explicit `<h2>/<h3>` tags, proper `<hr>`. Use `MIMEMultipart("alternative")` + `smtplib` directly with random title/closing pulled from the references files.
- **BORDERLINE** → If you have to ask, build it manually. send-shonuff.py is now reserved for plain text notifications only (no tables, no headers, no formatting).

**Testing checklist before every send:**\n1. Open the sent email in your inbox. Look for visible `##`, `---`, or `|pipe|syntax|`.\n2. If any raw markdown is visible, you used the wrong method. This is a zero-tolerance error.\n3. Are tables hand-crafted HTML `<table>` elements with inline styles? If they came from markdown table conversion, rebuild them.\n4. Is the Sho'Nuff signature present with circular badge, random title, red divider?\n5. Is the closing quote between the body and the divider (not inside the signature)?\n6. Is the badge image a valid PNG (URL: core.itpropartner.com/shonuff-signature.png)?

## HTML rendering of markdown — CRITICAL regex order

When sending Emails as HTML (multipart/alternative), the markdown-to-HTML conversion must render `##`, `###`, `---`, and `**bold` correctly.

**Only use this when sending plain text WITHOUT tables.** If the body has tables, build the HTML by hand in Python.

**THE CORRECT ORDER (validated through repeated failure):**
1. `re.sub(r'^## (.+)$', r'<h2 style="...">\1</h2>', text, flags=re.MULTILINE)` — H2 headers FIRST
2. `re.sub(r'^### (.+)$', r'<h3 style="...">\1</h3>', text, flags=re.MULTILINE)` — H3 headers
3. `re.sub(r'^---$', r'<hr style="...">', text, flags=re.MULTILINE)` — horizontal rules
4. `re.sub(r'\*\*(.+?)\*\*', r'<strong>\1</strong>', text)` — bold
5. `text.replace('\n', '<br>')` — newlines LAST

**TEST:** Before sending, check the HTML version for literal `##` or `---` visible text. If present, the order was wrong.

## Email content depth — DO NOT send fully-written copy to Germaine (hard rule)

Germaine has explicitly called out that DRE website emails from Sho'Nuff go into too much granular detail (exact dollar amounts, every phase description, full finished paragraphs). He builds the WordPress pages himself.

**Rule:** When Germaine asks for content for a page he's building (website, landing page, portal page), deliver:
- Section headers and structure
- Key bullet points
- Tables of facts/figures
- Do NOT write finished prose, full sentences, or paragraph blocks
- He writes the copy; you provide the skeleton

This applies specifically to content being sent for Germaine to build. It does NOT apply to operational documentation (CRM guides, setup docs, reference materials) which should be complete.

**Extended rule — game/entertainment content:** This same brevity applies to game rulebooks, instruction manuals, and wiki-style content. Strategy tips, optimal-play advice, or how-to-play-guide content that the user did not ask for MUST be omitted unless explicitly requested. If the user says "omit the strategy tips," remove that section entirely and do not replace it with a smaller version. Take the hint and keep it lean.

## Content-level brevity — deliver skeletons, not prose (CRITICAL)

Germaine builds his own copy for websites, email campaigns, and client-facing content. He will explicitly tell you when he wants this. When the task is **"author the content for [page X]"** or **"create the copy for [thing]"**, do NOT write finished paragraphs.

**"I need content for the..."**

If the user asks for outlines, key points, or structure, assume Germaine is building the page himself and keep it skeletal.

## Email composition: multipart/alternative

The plain text part uses raw Markdown syntax (##, ###, ---) which degrades gracefully. Never send `text/html` only.

The BCC address is `g@germainebrown.com`. Add it as a `Bcc` header field, not in the `To` header.

## Signature block — RANDOMIZED title + closing (confirmed Jul 12, 2026)

Germaine confirmed (Jul 12, 2026): the signature title and closing are RANDOMIZED from provided lists each email. 13 titles, 8 closings.

**NOT permanent.** Do NOT use a single fixed title or closing. Always pick randomly.

The master reference lives at `/root/.hermes/references/shonuff-signature.py` with `build_signature_block()` — use that.
See the `email-sender-formatting` skill for the full pattern and list contents.

### Company Line

The company line in the signature is **"IT Pro Partner"** (changed back from "iAmGMB" — confirmed in Jul 12 session). Do NOT change without being told.

### Signature order (CANONICAL)

```html
<p style="font-size:15px;color:#333;font-style:italic;">{random_closing}</p>
<hr style="border:none;border-top:2px solid #cc0000;width:40px;text-align:left;margin:16px 0;border-radius:40px;">
<table cellpadding="0" cellspacing="0"><tr>
  <td style="vertical-align:middle;padding-right:12px;"><img src="https://core.itpropartner.com/shonuff-signature.png" width="48" height="48" style="border-radius:50%;" alt="Sho'Nuff"></td>
  <td style="vertical-align:middle;font-size:13px;color:#555;line-height:1.4;">
    <span style="font-weight:bold;color:#1a1a2e;">Sho'Nuff</span><br>{random_title}<br>IT Pro Partner<br>
    <a href="mailto:shonuff@germainebrown.com" style="color:#2563eb;text-decoration:none;">shonuff@germainebrown.com</a>
  </td>
</tr></table>
```

## Delivery pattern — RANDOMIZED signature

When sending an informational email (not a reply to a specific request):
1. Draft the email body following this style guide
2. Convert to HTML following the HTML rendering rules above
3. Build a random title from TITLES (13 options) and random closing from CLOSINGS (8 options)
4. Use the helper: `from /root/.hermes/references/shonuff-signature import build_signature_block()`
5. Construct email: `body_text + signature_html`
6. Send as multipart/alternative (plain text + HTML)
7. BCC `g@germainebrown.com` on every send UNLESS he's already in To
8. Set From to `shonuff@germainebrown.com`

## Communication prefixes — how Germaine tells you what to do via email

When Germaine emails shonuff@germainebrown.com, the subject line or first line of the body may include a prefix telling you how to handle it:

| Prefix | Meaning | What to do |
|---|---|---|
| *(none)* | Direct command | Do it now, report back |
| `[bg]` or `[delegate]` | Background task | Subagent handles it, results come back async |
| `[queue]` | Queued for later | Shelved until he checks in next |
| `[lookup]` | Research | Quick search, one-and-done |
| `[note]` | Just FYI | Acknowledge, save, no action |

## Python string escaping for apostrophes

When building email scripts that include "Sho'Nuff" (with apostrophe), writing Python inside shell heredocs can produce garbage output like `Sho'"'"'Nuff`. **Fix:** write the Python script to a temp file first (avoid heredocs), or use double quotes in Python when inside a single-quoted heredoc. Always send a test email after any rewrite and verify the From name renders correctly.
