skills/email-composer/SKILL.md
Draft professional emails for various contexts including business, technical, and customer communication. Use when the user needs help writing emails or composing professional messages.
npx skillsauth add curiositech/windags-skills email-composerInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Provide context and purpose, and I'll draft an appropriate email using structured decision-making to match tone, length, and formality to your recipient and situation.
IF recipient is C-level/executive:
└── Use bullet points, <150 words, subject = "Action Required:" + specific ask
└── Structure: Context (1 sentence) → Ask → Timeline → Next steps
IF recipient is peer/colleague:
└── Use conversational tone, 150-250 words, subject = descriptive + purpose
└── Structure: Greeting → Context → Details → Clear CTA → Thank you
IF recipient is external customer:
└── Use formal language, 200-300 words, subject = specific issue/order reference
└── Structure: Acknowledgment → Problem statement → Solution → Follow-up
IF recipient is team/group:
└── Use structured format, numbered lists, subject = "Update:" + topic
└── Structure: Summary → Details with headers → Action items → Timeline
IF purpose = urgent request:
└── Lead with deadline, use [URGENT] tag, bold key dates
└── Maximum 3 sentences before the ask
IF purpose = status update:
└── Use "What/So What/Now What" structure
└── Include metrics, next milestones, blockers
IF purpose = problem resolution:
└── Acknowledge → Explain → Apologize (if needed) → Fix → Prevent
└── Lead with resolution timeline
IF purpose = information sharing:
└── Use inverted pyramid: key info first, supporting details after
└── Include "Why this matters" section
IF need response today:
└── Subject: [ACTION REQUIRED] + specific task + deadline
└── First line: "I need X by Y time because Z"
IF need response this week:
└── Subject: Clear ask + "by [date]"
└── Include specific deadline in closing
IF FYI/no response needed:
└── Subject: "[FYI]" or "Update:" prefix
└── State "No response needed" in opening
Symptom: Recipient doesn't respond or asks "What do you need?" Root Cause: Request hidden in paragraph 3+ or implied rather than explicit Fix:
Symptom: Response feels cold/distant or inappropriately casual Root Cause: Tone doesn't match recipient relationship or company culture Fix:
Symptom: No response, or "Can you summarize?" reply Root Cause: Too much background before getting to the point Fix:
Symptom: Email gets lost in inbox, delayed responses Root Cause: Subject like "Question" or "Following up" gives no priority signal Fix:
Symptom: Recipient responds with questions about what they should do Root Cause: Multiple possible actions or unclear next steps Fix:
Scenario: Need project status for board meeting from busy VP
Decision Process:
Draft:
Subject: [ACTION REQUIRED] Project Alpha status for board deck by 3pm
Hi Sarah,
I need Project Alpha's current status for tomorrow's board presentation.
Specifically need:
• % complete vs. timeline
• Any blockers requiring board attention
• Budget variance (if >5%)
Please send by 3pm today so I can incorporate into the deck.
Thanks,
Alex
What novice would miss: Would write long context paragraph about board meeting importance, bury the ask in paragraph 2, use vague subject like "Board Meeting Question"
What expert catches: Leads with deadline, uses bullets for scannability, specifies exact information needed, gives reason for timing
Don't use email-composer for:
Delegate when:
tools
Building resilient distributed systems with circuit breakers, retries with full-jitter exponential backoff, retry budgets (per-request 3-attempt + per-client 10% ratio per Google SRE), deadline propagation, and the cascading-failure math (4 layers × 3 retries = 64x amplification). Grounded in Resilience4j, Microsoft Cloud Patterns, AWS Architecture Blog (Marc Brooker), and Google SRE Book.
testing
Designing HTTP cache headers that work correctly across browsers, CDNs, and shared proxies — `Cache-Control` directives per RFC 9111, `stale-while-revalidate` and `stale-if-error` per RFC 5861, the Vary header for varying responses, and surrogate keys for tag-based purging. Grounded in IETF RFCs and Cloudflare/Fastly docs.
development
Use when designing or fixing a Content Security Policy on a real site, choosing between nonce-based and hash-based CSP, adding strict-dynamic, debugging "Refused to execute inline script" errors, deploying CSP in report-only mode first, configuring report-to / report-uri, or auditing an existing policy for unsafe-inline / unsafe-eval / wildcards. Triggers: "CSP blocks legitimate inline script", strict-dynamic, nonce-{RANDOM}, sha256-{HASH}, object-src none, base-uri none, frame-ancestors, Trusted Types, X-Content-Security-Policy obsolete, report-only vs enforced. NOT for general HTTP security headers (HSTS, COOP/COEP), Trusted Types deep dive, CORS configuration, or building a WAF.
tools
Choosing and operating an HTTP API versioning strategy that doesn't break clients — Stripe's date-based pinned versions, the Deprecation/Sunset header pair (RFC 9745 + RFC 8594), URI vs header vs media-type approaches, and the version-transformer pattern. Grounded in Stripe's published architecture and IETF RFCs.