Evan
1d32be994c
The `librefang` dashboard's federated catalog UI surfaces every optional SKILL.md frontmatter field — version, author, and tags — but the existing skills only carry `name` + `description`, so the catalog cards render visually empty: ┌────────────────┐ │ ansible │ ← no version, no author, no tags shown │ FangHub │ │ Ansible auto… │ └────────────────┘ Populate the three optional fields across every skill so the catalog fills out as designed: ┌─────────────────────┐ │ ansible │ │ skill · librefang │ │ · v0.1.0 │ │ Ansible auto… │ │ [devops][automation]│ │ [infra] │ └─────────────────────┘ Choices - author = `librefang`. Registry-internal authorship; not the human SME who wrote the prompt body. Per-skill author attribution can come in a follow-up if maintainers want it. - version = `0.1.0` baseline. Future content updates bump per-skill. - tags = curated per skill from the dashboard's category set (`coding/git/web/devops/browser/ai/data/productivity/security/cli`) plus domain-specific follow-ups. First tag is the primary category. The librefang side already tolerated these fields — see PR #4144 (dashboard) and the matching backend parser commit. With this change landed and the daemon's registry cache refreshed, the catalog renders the full card metadata without any further code change. README also documents the optional keys so future skill contributors know they can fill them out.
42 lines
3.6 KiB
Markdown
42 lines
3.6 KiB
Markdown
---
|
|
name: email-writer
|
|
description: "Professional email writing expert for tone, structure, clarity, and business communication"
|
|
version: 0.1.0
|
|
author: librefang
|
|
tags: [productivity, writing]
|
|
---
|
|
# Professional Email Writer
|
|
|
|
A business communication specialist with deep expertise in crafting clear, effective, and appropriately toned emails for professional contexts. This skill provides guidance for structuring emails that get read, understood, and acted upon, whether writing to executives, clients, teammates, or external partners across cultures and communication styles.
|
|
|
|
## Key Principles
|
|
|
|
- Lead with the bottom line up front (BLUF): state the purpose, decision needed, or key information in the first sentence so the reader immediately knows why this email matters
|
|
- Match your tone to the relationship and context; an update to your team reads differently than a request to a VP or a negotiation with a vendor
|
|
- Make the ask explicit and actionable; every email that requires a response should state exactly what is needed and by when
|
|
- Keep emails scannable with short paragraphs, bullet points, and bold key phrases; most recipients scan on mobile before deciding to read in full
|
|
- Respect inbox volume by consolidating related points into one email rather than sending multiple messages in rapid succession
|
|
|
|
## Techniques
|
|
|
|
- Write subject lines that convey both topic and urgency: "Decision needed by Friday: Q3 budget allocation" is actionable, "Quick question" is not
|
|
- Structure longer emails with sections: Context (1-2 sentences of background), Details (bullet points or numbered items), and Ask (clear next steps with deadlines)
|
|
- Calibrate formality based on recipient: "Hi Alex" for peers, "Dear Dr. Chen" for formal external contacts, and match the tone the other party sets in their replies
|
|
- Use CC intentionally: include people who need visibility, use BCC only for large distribution lists, and explain in the body why recipients are included if it is not obvious
|
|
- Handle difficult conversations (delays, rejections, disagreements) with empathy-first framing: acknowledge the situation, explain the reasoning, and offer an alternative or next step
|
|
- Set follow-up expectations: if you need a response, state the deadline; if no response is needed, say "No reply needed, just keeping you informed"
|
|
|
|
## Common Patterns
|
|
|
|
- **Status Update**: Subject with project name and date, BLUF summary of status (on track / at risk / blocked), key accomplishments since last update, upcoming milestones, and blockers with proposed solutions
|
|
- **Request for Decision**: State the decision needed, provide 2-3 options with brief pros and cons, include your recommendation, and specify the deadline for the decision
|
|
- **Introduction Email**: Briefly explain why you are connecting the two parties, provide one sentence of relevant context about each person, and then step back to let them continue the conversation
|
|
- **Escalation**: State what was attempted, why it did not resolve the issue, the impact of continued delay, and the specific help needed from the recipient
|
|
|
|
## Pitfalls to Avoid
|
|
|
|
- Do not bury the request or key information in the third paragraph; recipients who scan will miss it entirely
|
|
- Do not use passive-aggressive language ("per my last email", "as previously mentioned") when a direct restatement is more effective
|
|
- Do not reply-all to large threads unless your response is genuinely relevant to every recipient; use targeted replies to reduce noise
|
|
- Do not send emotionally charged emails immediately; draft them, wait at least an hour, reread with fresh eyes, and then decide whether to send or soften the tone
|