// Use when writing a client-facing email summarizing project work. Reads git history + code, drafts a tiered outline by client impact, outputs markdown with optional HTML/screenshots.
[HINT] Download the complete skill directory including SKILL.md and all related files
| name | client-update-email |
| description | Use when writing a client-facing email summarizing project work. Reads git history + code, drafts a tiered outline by client impact, outputs markdown with optional HTML/screenshots. |
| disable-model-invocation | true |
Generate a client-facing email summarizing project work. Five phases: gather → outline → draft → screenshots → output.
Ask the user for these if not already provided in conversation context:
deploy/prod..deploy/stage. Alternatives: date range, specific PRs, specific commits, or any two git refs.Run these commands, adapting refs to the user's scope:
git log deploy/prod..deploy/stage --oneline --no-merges 2>/dev/null || echo "SCOPE_ERROR: adjust refs"git diff deploy/prod..deploy/stage --stat 2>/dev/null || truegh pr list --state merged --limit 50 --json number,title,body,url 2>/dev/null || trueIf the default refs don't exist, ask the user which branches or refs to compare.
For each PR or logical group of commits:
git diff <commit-range> -- <files>).gh issue view <N>) if available.Spend time here. Read the code. Understand what was built, not just what files changed.
Show the synthesized list to the user:
Found N changes:
1. [Short name] — [What it does for the client]. Touches [area]. Route: /path
2. [Short name] ��� [What it does for the client]. Touches [area]. Route: /path
...
Ask: "Anything missing or wrong? You can add changes that aren't in git (design work, config changes, manual deployments)."
Wait for confirmation before proceeding to Phase 2.
Group and tier the confirmed changes by client-perceived impact — not code complexity, not diff size:
Cluster related changes under a single heading. Three commits touching export become one "Export improvements" item.
## Big Changes
- [Feature Name] — 1-line description of what it does for the client
- [Feature Name] — ...
## Medium Changes
- [Feature Name] — ...
## Small Changes
- [Fix/improvement] — ...
Tell the user they can:
Wait for the user to approve the outline before proceeding to Phase 3.
Create the output directory:
mkdir -p client-updates/screenshots
Write the email as markdown to client-updates/<YYYY-MM-DD>-update.md using the approved outline.
Follow this structure exactly. Apply the user's chosen tone and language consistently throughout.
# What's New — [date or period]
[Opening paragraph — friendly summary of the update, 1-2 sentences.]
## Big Changes
### [Feature Name]
[2-3 sentences: what it does and why it matters to the client.]
**Where to find it:** [Navigation path, URL, or description — whatever communicates clearest]
[Screenshot: <descriptive-filename.png> — <what to capture and what state to show>]
---
### [Next Feature]
...
## Medium Changes
### [Feature Name]
[1-2 sentences.]
**Where to find it:** [Navigation path or URL]
[Screenshot: <filename.png> — <description>] ← only if the change is visual
---
## Small Changes
- **[Name]** — one-line description
- **[Name]** — one-line description
[Closing line — tone-appropriate sign-off.]
[Screenshot: filename.png — description of what to capture]After writing the draft, show it to the user. Wait for approval or edits before proceeding to Phase 4.
Check if a local dev server is already running by testing common ports (3000, 3001, 5173, 8080):
lsof -i :3000 -i :3001 -i :5173 -i :8080 -sTCP:LISTEN 2>/dev/null
If not running, figure out how to start it. Check these sources in order:
docker compose up (or the specific service)dev, serve, run targetsdev, start, or serve scriptsPORT or BASE_URL hintsStart the dev server using whatever method the project uses. Wait for it to be ready before proceeding. If unsure which method is correct, ask the user.
For each screenshot placeholder in the draft, propose a capture plan. Use the route and component knowledge from Phase 1:
Screenshot captures:
1. [filename.png] — Navigate to http://localhost:<port>/path → click "Tab Name" → scroll to section
2. [filename.png] — Navigate to http://localhost:<port>/other-path → open modal via "Button Text"
...
The skill already knows which routes and components are involved from the Phase 1 deep-read. Use that knowledge to plan the navigation steps.
Ask user to confirm or adjust the capture plan. Some screenshots may need specific data or login state — the user should flag these.
For each planned screenshot, use browser automation tools:
client-updates/screenshots/<descriptive-filename>.png.Show the user which screenshots were captured and their file paths. The user can:
Wait for approval before proceeding to Phase 5.
Convert the markdown draft to HTML. The HTML must look like a normal composed email — not a newsletter, not a marketing template.
Styling rules:
<style> tags)<b> or <strong> for headings — not styled <h1>/<h2> tags<p> paragraphs<hr> between sections[Screenshot: filename.png] markers stay as plain text — the user drags images into the email client manuallySave to client-updates/<YYYY-MM-DD>-update.html.
Report what was produced:
Done. Files in client-updates/:
Markdown: <date>-update.md (for editing)
HTML: <date>-update.html (open in browser → select all → paste into Mail)
Screenshots: screenshots/<name>.png (drag into Mail at marked positions)
Workflow: open the HTML in a browser, Cmd+A, Cmd+C, paste into macOS Mail. Then drag each screenshot from the screenshots/ folder to replace the [Screenshot: ...] markers.