Feature request
When mcp__email__send is invoked in interactive mode, the user often edits the LLM-drafted body in Mutt before sending — tightening phrasing, dropping pleasantries, restructuring, etc. The final sent body is currently returned in the tool response, but the diff between what the LLM proposed and what the user actually sent is not captured anywhere persistent.
That diff is exactly the high-signal training data needed to refine the email-tone skill (and similar style-learning workflows). Over time it should let drafts converge toward the user's voice without requiring repeated manual edits.
Proposal
Persist a structured record per send, e.g. to ~/.mcp-handley-lab/email/edits/<timestamp>-<msgid>.json, containing:
proposed_body — what the LLM sent as the body argumentfinal_body — what was actually transmittedunified_diff — convenience fieldsubject_proposed, subject_finalrecipient_domain (e.g. cam.ac.uk) — coarse context, not the full addresstimestamp, account
Recipient address, full names, and any other PII should NOT be stored — the value is in the linguistic delta, not the social graph.
Downstream a periodic skill / agent can summarise patterns from this log (e.g. "user always strips opening pleasantries", "user prefers em-dashes over parentheticals", "user adds availability hints when proposing meetings") and update the email-tone skill or inject hints into future drafts.
Why now
Came up while sending a real email today where the LLM draft was reasonable but the user's edits followed a consistent pattern that the email-tone skill could have anticipated. Without persistence those signals are lost the moment the Mutt buffer closes.
Feature request
When
mcp__email__sendis invoked in interactive mode, the user often edits the LLM-drafted body in Mutt before sending — tightening phrasing, dropping pleasantries, restructuring, etc. The final sent body is currently returned in the tool response, but the diff between what the LLM proposed and what the user actually sent is not captured anywhere persistent.That diff is exactly the high-signal training data needed to refine the email-tone skill (and similar style-learning workflows). Over time it should let drafts converge toward the user's voice without requiring repeated manual edits.
Proposal
Persist a structured record per send, e.g. to
~/.mcp-handley-lab/email/edits/<timestamp>-<msgid>.json, containing:proposed_body— what the LLM sent as thebodyargumentfinal_body— what was actually transmittedunified_diff— convenience fieldsubject_proposed,subject_finalrecipient_domain(e.g.cam.ac.uk) — coarse context, not the full addresstimestamp,accountRecipient address, full names, and any other PII should NOT be stored — the value is in the linguistic delta, not the social graph.
Downstream a periodic skill / agent can summarise patterns from this log (e.g. "user always strips opening pleasantries", "user prefers em-dashes over parentheticals", "user adds availability hints when proposing meetings") and update the email-tone skill or inject hints into future drafts.
Why now
Came up while sending a real email today where the LLM draft was reasonable but the user's edits followed a consistent pattern that the email-tone skill could have anticipated. Without persistence those signals are lost the moment the Mutt buffer closes.