Email Account Awareness & Signature Management

Depends on: none (see Prerequisite below -- a real, hard requirement, just not a catalog dependency)

What this is

Two capabilities layered on top of a working IMAP/SMTP email integration already present on the machine: (1) recording, at the project level, which email account this project sends as when more than one is configured, and (2) a deterministic signature -- and default composition style -- pulled from something the person actually sent, never invented, and written down in two places at once so it's never left to memory or chance. This is a base capability, not itself an email-sending mechanism: nikolausm/imap-mcp-server (the underlying prerequisite) has no signature concept anywhere in its own tool schema -- no signature field on account setup, no per-account default, nothing on the send/reply/forward tools; every outbound email is composed from a full body supplied at call time. This feature exists entirely as a layer built on top of that real, directly-confirmed gap, not as a setting the underlying server exposes.

Prerequisite (hard requirement, not a catalog dependency)

This feature cannot be installed into any project without a working IMAP/SMTP email integration already present and confirmed working on the machine -- verified by a successful "list all my email accounts" test and at least one successful read. This is the same class of assumption FTR-31 (Preferred MCP Instance) and FTR-39 (EML Archiver) already make about their own underlying connectors: real, and worth checking for, but not a structural catalog dependency the way FTR-13 or FTR-07 are -- see index.md's own "Prerequisites (not a feature, not a dependency)" section.

A known, real gotcha worth carrying into any install of this feature: the imap-mcp-server setup wizard's "Claude Desktop integration" prompt performs a blind, destructive full-file config overwrite and must always be declined; account setup itself (View Accounts / Add New Account / Test & Save) is separate and safe. A Windows-specific MSIX config-path fix for Store-installed Claude Desktop is also documented at the connector's own source. That deeper setup detail lives with the prerequisite itself, not this feature's install payload -- see feature_library_site\prerequisites.html for this catalog's equivalent treatment of other MCP-dependent features; whether an IMAP-setup section belongs there too is worth raising with the person maintaining this catalog rather than assumed.

Assess first

• Confirm the IMAP/SMTP integration is actually live: run the standard "list all my email accounts" check and at least one successful read. If it isn't, stop here and point the person at the Prerequisite above -- this feature has nothing to build on without it.
• Check admin\AGENT_INSTRUCTIONS.md for an existing EMAIL CAPABILITY note or a signature section from a prior install; if present, confirm and skip re-asking what's already answered.
• Note how many email accounts are configured on the machine.

Ask, only if needed

• If more than one account is configured: "Which email account should [Project Name] use when sending email? [list configured account identities]" -- never assumed or guessed. If only one account exists, skip this question and just record it.
• Nothing else needs asking before the signature step below -- that step is itself the confirmation mechanism, not a separate question asked in the abstract.

Write

Part 1 -- Project email account

Add or update this section in admin\AGENT_INSTRUCTIONS.md, written as plainly and permanently as any other project fact -- never left sitting only in a separate reference file the agent might forget to check:

◆ EMAIL CAPABILITY

This project can send and read email via [account identity], using the
IMAP/SMTP integration already configured on this machine.

Part 2 -- Signature adoption (the confirmation step)

Once the project's email account is confirmed working, adopt its signature the deliberately simple, grounded way -- anchored to something the person actually sent, never invented or pattern-matched across many historical messages:

1. Go to that account's Sent folder.
2. Pull one actual, previously-sent real email.
3. Show the person the signature/closing text at the bottom of that real email.
4. Ask them to confirm: "Is this the signature to use going forward?"
5. Only once confirmed, save it -- verbatim, not paraphrased or cleaned up.

While reading that same sent email for the signature, also inspect its HTML for the sending client's own styling -- typically a body { font-family: ...; font-size: ...; } rule embedded in the message's own <style> block -- and adopt that as the default font/typeface for anything this feature composes going forward. Same principle as the signature itself: assimilate to the account's existing real look rather than introducing a new one. This is a real, already-observed pattern in actual sent mail, not a hypothetical.

This Sent-folder-and-confirm flow is the only adoption path -- no pattern-matching across historical messages, and no separate, lighter flow reserved for later updates: if the signature (or the detected default style) ever needs to change, the person requests the update directly with the new text and it gets rewritten the same dual way below, with no need to repeat the full Sent-folder pull for a plain text edit -- though re-pulling a fresh sent email is always fine if the person wants to re-anchor it to something current.

Determinism -- the dual-write requirement

Once a signature (and default style) is confirmed, write it down in two places at the same time, not one:

1. admin\EMAIL_SIGNATURE.md (or admin\EMAIL_SIGNATURES.md if this project ever needs more than one -- see "What this doesn't cover" below) -- the durable, human-editable single source of truth. The word "signature(s)" must appear in the filename so it's unambiguous at a glance.
2. Directly in admin\AGENT_INSTRUCTIONS.md -- not referenced or pointed to, the actual signature text itself, written inline, immediately below the ◆ EMAIL CAPABILITY section from Part 1.

Both writes happen together, kept in sync. The reason for the duplication is explicit and important: admin\AGENT_INSTRUCTIONS.md is what reaches every conversation automatically, so baking the signature directly into it guarantees it is always applied when composing an email from this project, in every session, without depending on the agent remembering to go look up a separate file first. admin\EMAIL_SIGNATURE.md alone is not sufficient on its own for that reason -- both writes are required and kept in sync.

Composition defaults

• HTML by default. This feature composes HTML email by default, not plain-text-primary -- resolved deliberately rather than left open. Whoever actually wires up the send call should still decide explicitly whether to also generate a minimal auto-derived text/plain alternative part (standard practice for older clients, accessibility, and spam filtering) or go HTML-only on purpose -- don't default silently either way; that specific sub-decision is a real open implementation detail, not resolved by this spec.
• Tiered HTML generation -- a practical, not-rigid approach: plain prose with no special formatting gets mechanically wrapped into <p> tags per blank-line-separated paragraph, no special authoring syntax needed; light formatting (a bold phrase, a short list, a link) is fine hand-written using a small, fixed, known-safe tag set given how narrow that vocabulary actually is; longer or more structurally complex content -- or content already naturally in Markdown, like the stored signature file itself -- should convert through a real, tested Markdown library rather than being hand-authored, since malformed nested structure is where hand-written HTML is most likely to go wrong and determinism matters most.
• Draft-first by default. Composing an email saves it to the account's Drafts folder, not sent directly, unless the person explicitly confirms they want it sent immediately. This gives a real review step before anything goes out, rather than requiring the person to trust the composition sight-unseen.

What this doesn't cover

• Multiple signatures per project -- explicitly out of scope. A project keeps exactly one signature; if a project genuinely emails on behalf of more than one identity, that's a real extension this feature doesn't attempt (no per-message selection logic).
• The actual send/reply/forward mechanics themselves -- those belong to the underlying IMAP/SMTP integration (the Prerequisite above), not this feature; this feature only supplies the account-selection record and the signature/style fed into whatever call composes the message.
• A finished, tested HTML-generation implementation -- the tiered approach above is real design guidance, not shipped code; whoever wires this up still has to build and test the actual composition path.

Confirm

Confirm: Email Account Awareness & Signature Management is installed -- admin\AGENT_INSTRUCTIONS.md names which account this project sends as (if more than one was configured), the signature (and detected default font/style) is written both into admin\EMAIL_SIGNATURE.md and inline in admin\AGENT_INSTRUCTIONS.md, and composed email defaults to HTML, drafts-first, unless the person says otherwise. Want to install another, or is that everything for now?