skills/marketing/professional-communication/SKILL.md
Guide technical communication for software developers. Covers email structure, team messaging etiquette, meeting agendas, and adapting messages for technical vs non-technical audiences. Use when drafting professional messages, preparing meeting communications, or improving written communication.
npx skillsauth add pedronauck/skills professional-communicationInstall 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.
This skill provides frameworks and guidance for effective professional communication in software development contexts. Whether you're writing an email to stakeholders, crafting a team chat message, or preparing meeting agendas, these principles help you communicate clearly and build professional credibility.
Core principle: Effective communication isn't about proving how much you know - it's about ensuring your message is received and understood.
Use this skill when:
Keywords: email, chat, teams, slack, discord, message, writing, communication, meeting, agenda, status update, report
Use this universal framework to organize any professional message:
| 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" |
Apply to: Emails, status updates, meeting talking points, technical explanations
Before communicating, ask yourself:
| Instead of | Try | | --- | --- | | "Project updates" | "Project X: Status Update and Next Steps" | | "Question" | "Quick question: API rate limiting approach" | | "FYI" | "FYI: Deployment scheduled for Tuesday 3pm" |
**Subject:** [Project/Topic]: [Specific Purpose]
Hi [Name],
[1-2 sentences stating the key point or request upfront]
**Context/Background:**
- [Bullet point 1]
- [Bullet point 2]
**What I need from you:**
- [Specific action or decision needed]
- [Timeline if applicable]
[Optional: Brief next steps or follow-up plan]
Best,
[Your name]
| Type | Key Elements | | --- | --- | | Status Update | Progress summary, blockers, next steps, timeline | | Request | Clear ask, context, deadline, why it matters | | Escalation | Issue summary, impact, attempted solutions, needed decision | | FYI/Announcement | What changed, who's affected, any required action |
For templates: See references/email-templates.md
Note: Examples use Slack terminology, but these principles apply equally to Microsoft Teams, Discord, or any team messaging platform.
| Use Chat | Use Email | | --- | --- | | Quick questions with short answers | Detailed documentation needing records | | Real-time coordination | Formal communications to stakeholders | | Informal team discussions | Messages requiring careful review | | Time-sensitive updates | Complex explanations with multiple parts |
Instead of:
You: Hi
You: Are you there?
You: Can I ask you something?
[waiting...]
Try:
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]
| Audience | Approach | | --- | --- | | Engineering peers | Technical details, code examples, architecture specifics | | Technical managers | Balance of detail and high-level impact | | Non-technical stakeholders | Business impact, analogies, outcomes over implementation | | Customers | Plain language, what it means for them, avoid jargon |
| Technical | Plain Language | | --- | --- | | "Microservices architecture" | "Our system is split into smaller, independent pieces that can scale separately" | | "Asynchronous message processing" | "Tasks are queued and processed in the background" | | "CI/CD pipeline" | "Automated process that tests and deploys our code" | | "Database migration" | "Updating how our data is organized and stored" |
For more examples: See references/jargon-simplification.md
Active voice is clearer, more direct, and conveys authority:
| Passive (avoid) | Active (prefer) | | --- | --- | | "A bug was identified by the team" | "The team identified a bug" | | "The feature will be implemented" | "We will implement the feature" | | "Errors were found during testing" | "Testing revealed errors" |
| Instead of | Use | | --- | --- | | "At this point in time" | "Now" | | "In the event that" | "If" | | "Due to the fact that" | "Because" | | "In order to" | "To" | | "I just wanted to check if" | "Can you" |
After writing, ask: "So what? Why does this matter to the reader?"
If you can't answer clearly, restructure your message to lead with the value/impact.
Every meeting invite should include:
**Meeting: [Topic] - [Date]**
**Attendees:** [Names]
**Key Decisions:**
- [Decision 1]
- [Decision 2]
**Action Items:**
- [ ] [Person]: [Task] - Due [Date]
- [ ] [Person]: [Task] - Due [Date]
**Next Steps:**
- [Follow-up meeting if needed]
- [Documents to share]
For structures by meeting type: See references/meeting-structures.md
Before sending any professional communication:
references/email-templates.md - Ready-to-use email templates by typereferences/meeting-structures.md - Structures for standups, retros, reviewsreferences/jargon-simplification.md - Technical-to-plain-language translationsfeedback-mastery - For difficult conversations and feedback delivery/draft-email - Generate emails using these frameworksLast Updated: 2025-12-22
tools
Plans real-user QA deliverables: personas, journey maps, exploratory charters, persona/journey/tour/CFR test cases, regression suites, Figma validation checks, automation intent, and user-impact bug reports. Writes artifacts under <qa-output-path>/qa/ for qa-execution to consume. Use when planning QA before execution, documenting journey-driven test strategy, marking flows that need E2E follow-up, or filing structured bug reports. Do not use for live execution, AI implementation audits, CI gate ownership, or technical integration/security/performance suites; use qa-execution or agent-output-audit instead.
development
Executes real-user QA sessions through public interfaces using personas, journeys, exploratory charters, test tours, edge-case probes, CFR checks, and browser evidence. Reads qa-report artifacts from <qa-output-path>/qa/ when present, captures issues/screenshots/reports under the same output tree, and classifies bugs by user impact. Use when validating a release candidate, migration, refactor, or user-facing change against production-like behavior. Do not use for AI implementation audits, task-status reconciliation, CI gate runs, integration/security/performance templates, or flaky-test triage; use agent-output-audit for those.
development
Transform outside-of-diff review files into properly formatted issue files for a given PR. Use when converting review files from ai-docs/reviews-pr-<PR>/outside/ into issue format in ai-docs/reviews-pr-<PR>/issues/. Automatically determines starting issue number and preserves all metadata (file path, date, status) from original review files. Don't use for inline-diff review files, non-PR review artifacts, or creating GitHub issues directly.
development
Enforce root-cause fixes over workarounds, hacks, and symptom patches in all software engineering tasks. Use when debugging issues, fixing bugs, resolving test failures, planning solutions, making architectural decisions, or reviewing code changes. Activates gate functions that detect and reject common workaround patterns such as type assertions, lint suppressions, error swallowing, timing hacks, and monkey patches. Don't use for trivial formatting changes or documentation-only edits.