Professional communication
Skill Dannykkh/skill-olympus/skills/professional-communication
Twelve Greek gods. One command. A working SaaS. 98 skills + 49 agents + 13 hooks for Claude Code + Codex CLI + Gemini CLI. Cross-CLI persistent memory, zero-interaction full pipeline (design → build → inspect → test → ship).
npx -y skills add Dannykkh/skill-olympus --skill professional-communicationAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 3 stars3 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Guide technical communication for software developers. Use when user asks to "draft an email", "write a message to stakeholders", "prepare meeting notes", "review my message", or needs help adapting technical content for non-technical audiences. Triggers on "이메일 작성", "메일 초안", "회의록", "stakeholder update".
SKILL.md
4.1 KB, as published. Nobody here has run it
Professional Communication
Core principle: Communication succeeds when the recipient understands and can act — not when the sender has expressed themselves.
The What-Why-How Structure
Use for any professional message: email, status update, Slack, meeting talking point.
| Component | Purpose | Example |
|---|---|---|
| What | State the topic/request clearly | "We need to delay the release by one week" |
| Why | Explain the reasoning | "Critical bug found in payment processing" |
| How | Outline next steps/action items | "QA will retest by Thursday; I'll update stakeholders Friday" |
Lead with What. Busy readers stop after the first sentence — make it count.
Audience Calibration
The same information needs different framing depending on who receives it:
| Audience | Approach |
|---|---|
| Engineering peers | Technical details, code examples, architecture specifics |
| Technical managers | Impact and tradeoffs, brief technical context |
| Non-technical stakeholders | Business impact and outcomes; no acronyms without explanation |
| Customers | What it means for them; avoid all implementation language |
Three-question test before writing:
- Who is reading this?
- What decision or action does this enable for them?
- What's the minimum they need to understand to act?
The No-Hello Anti-Pattern
Direct messages get faster responses. Asking "are you there?" before your actual question forces two round-trips.
Instead of:
You: Hi
You: Are you there?
You: Can I ask you something?
[waiting...]
Write the complete message immediately:
You: Hi Sarah — quick question about the deployment script.
Getting a permission error on line 42. Have you seen this before?
Here's the error: [paste error]
This applies to all async communication: state the full request, not a preamble.
Email Structure
Subject: [Project/Topic]: [Specific Purpose]
Hi [Name],
[1-2 sentences: key point or request, upfront]
Context:
- [Bullet 1]
- [Bullet 2]
What I need from you:
- [Specific action]
- [Deadline]
[Optional: next steps]
Subject line matters: "Project X: Status Update and Next Steps" is findable and actionable. "Project updates" is neither.
Pre-Send Check (required before sending)
Do not assert facts without a source check. Before sending, confirm every factual detail against the actual source, not memory:
- Names and titles — check the directory, thread, or org chart.
- Dates and deadlines — check the calendar or ticket, not recall.
- Ticket/PR/issue status — open it and confirm it is actually in the state you claim.
If any item cannot be confirmed, flag it as [unverified] rather than stating it as fact.
Jargon Translation
When writing for non-technical audiences, replace implementation terms with outcomes:
| Technical | Plain Language |
|---|---|
| "Microservices architecture" | "System split into independent pieces that scale separately" |
| "Asynchronous message processing" | "Tasks queued and processed in background" |
| "CI/CD pipeline" | "Automated process that tests and deploys code" |
| "Database migration" | "Updating how data is organized and stored" |
For more examples: references/jargon-simplification.md
Reference Files
references/email-templates.md— Ready-to-use templates by type (status update, request, escalation, FYI)references/meeting-structures.md— Structures for standups, retros, planning, reviewsreferences/jargon-simplification.md— Technical-to-plain-language translations
Companion Skills
writing-clearly-and-concisely— Prose editing, active voice, omitting needless wordsfeedback-mastery— Difficult conversations and feedback delivery
Gives 0 of the 12 instructions most note taking skills give
Counted across 686 of the 876 authors here whose files we hold, read 2026-08-06
- include a visual element on every slidein 44 of 686, across 13 files
- use wikilinks for internal vault linksin 35 of 686, across 11 files
- commit to a single visual motif across every slidein 34 of 686, across 9 files
- read pptxgenjs guide before creating presentations from scratchin 30 of 686, across 6 files
- keep 0.5 inch minimum marginsin 30 of 686, across 7 files
- use subagents to visually inspect rendered slidesin 30 of 686, across 6 files
- re-verify affected slides after every fixin 27 of 686, across 5 files
- run content QA checks before declaring successin 26 of 686, across 3 files
- Use Markdown links for external URLs onlyin 26 of 686, across 10 files
- pick a bold topic specific color palettein 24 of 686, across 2 files
- read editing guide before editing existing presentationsin 23 of 686, across 1 file
- use one dominant color across all slidesin 23 of 686, across 1 file
Said here and by no other author read
- Lead with the primary point or request
- Structure messages using the what-why-how format
- Answer the three audience calibration questions before writing
- Send the complete request without a preamble
- Use findable and actionable subject lines
- Confirm every factual detail against the source before sending
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once.