family-email-formatting

Files (4)

• SKILL.md
• base-template.md · references/
• persona-variants.json · references/
• reply-template.md · references/

SKILL.md (first lines)

# Family Email Formatting (`brief` + `reply`)

Use this skill whenever composing outbound HTML email for family-office personas.

## Workflow

1. Determine composition mode from the caller instruction:
   - `brief` for scheduled briefs, recurring reports, and other report-style outbound emails.
   - `reply` for inbound family-email responses sent with `reply_gmail_message`.
2. Determine persona alias (`cos`, `estate`, `hc`, `hd`, `io`, `wellness`).
3. Load persona variant from `references/persona-variants.json`.
4. Render the mode-appropriate layout:
   - `brief` -> `references/base-template.md`
   - `reply` -> `references/reply-template.md`
5. Compose the email using the mandatory style rules for the selected mode.

## `brief` mode

Use `brief` mode for scheduled or report-style outbound emails.

### Brief-mode structure

1. Build a two-layer response in this order:
   - Executive Summary (2-minute scan): KPI cards, action table, and an agent-chosen primary visual when warranted.
   - Deep Dive and Provenance: narrative analysis, assumptions, caveats, and source attribution.
2. Keep the executive layer compact, but make the deep dive complete enough for auditability.

### Mandatory brief-mode style rules

- Keep one shared layout for all personas.
- Apply nuance only through accent color, role label, and signature/footer copy.
- Inline styles only.
- No markdown in final body.
- Executive Summary must come before Deep Dive.
- Keep KPI cards and action-oriented summary elements for fast scanning.
- Replace the old fixed "Signal Graph" concept with one optional primary visual that best explains the key monitoring point or decision in the brief.
- The primary visual may be a spark trend, bar chart, line chart, scatter plot, progress bars, or another compact honest graphic.
- Omit the primary visual entirely when the data is too sparse or prose is clearer.
- Deep Dive must include where information came from:
  - MCP-backed facts: cite MCP server/tool names.
  - Web research: include links actually consulted.
- Do not omit narrative context when decisions or tradeoffs are involved.

### Recommended brief-mode visual hierarchy

1. Header band (role + subject + date context).
2. Executive Summary heading + one short narrative paragraph.
3. KPI strip (2 to 4 cards).
4. Action table.
5. Agent-chosen primary visual when warranted.
6. Deep Dive narrative.
7. Provenance table (claim, source system/tool, link/reference).
8. Closing and signature.

## `reply` mode

Use `reply` mode for inbound family-email responses that should read like a natural email instead of a report.

### Mandatory reply-mode style rules

- Keep the body prose-first and human-sounding.
- Make the reply read like a real human-drafted email, not a memo or artifact.
- Render the reply as actual HTML email content, not plain text pasted into an HTML body.
- Start with a natural salutation.
- When the recipient names are clear from the thread, address them naturally by name; otherwise use a warm neutral greeting.
- Open with the direct answer or key response in the first paragraph.
- Preserve the family's preference for first-principles, detailed, explanatory reasoning when the question is substantive.
- Weave reasoning into natural paragraphs instead of forcing an Executive Summary / Deep Dive split.
- Use headings only when they materially improve readability.
- Use lists, tables, or compact charts only when they communicate more clearly than prose.
- Do not force KPI cards, action boards, dashboard framing, or provenance tables into normal replies.
- End with a natural closing and persona sign-off on every reply.
- Keep provenance inline by default when material:
  - mention the MCP server/tool in the prose, ideally parenthetically or in a short supporting clause, when it materially supports the answer
  - mention web sources in the prose when they materially support the answer, using clean clickable HTML links when helpful
  - use a final "Sources consulted" note only when the reply is research-heavy or cites enough sources that inline attribution would hurt readability
- Inline styles only.
- No markdown in final body.
- Use real HTML structure for the body (`<p>`, `<div>`, `<table>`, `<a>`, etc.) so tables, charts, and clean clickable source links can be added when valuable.

### Recommended reply-mode visual hierarchy

1. Salutation.
2. Direct answer paragraph.
3. Supporting reasoning in natural prose.
4. Optional next steps or recommendation paragraph.
5. Natural closing and persona sign-off.
6. Optional compact table, chart, or short sources note when warranted.

## Provenance guidance

- Prefer concrete attribution, e.g. `MCP: paperless.search_documents` or `MCP: google-workspace-personal-ro.get_events`.
- For web lookups, include direct URLs.
- In `brief` mode, include explicit provenance in the deep dive or provenance section.
- In `reply` mode, default to inline attribution. Use a short final source note only for research-heavy or many-source replies.

## Automation reply contract

- For inbound replies, use `google-workspace-agent-rw.reply_gmail_message` with the triggering Gmail `message_id`. Do not rebuild `thread_id`, `in_reply_to`, or `references` manually.
- For new outbound conversations or scheduled reports, use `google-workspace-agent-rw.send_gmail_message`.
- After the Gmail tool call, return JSON only:

```json
{"status":"sent","sent_message_id":"<id>","thread_id":"<thread_id>","from_email":"<alias_email>","to":"<recipient_or_list>"}
```

From hvkshetry/StewardOS, MIT.

More from hvkshetry/StewardOS