professional-communication

professional-communication 技能總覽

professional-communication 技能可協助 agent 為軟體團隊撰寫更清楚的職場訊息，包括 email、聊天訊息、進度更新、會議議程、摘要，以及面向不同受眾的技術說明。它真正解決的不是「把文字修得更專業」，而是讓訊息更容易被理解、被採取行動、被妥善留存，並減少來回澄清的成本。

哪些人最適合使用這個技能

這個 professional-communication 技能特別適合開發者、tech lead、工程經理，以及經常需要處理以下溝通情境的 AI 使用者：

• 請人審查或做決策
• 回報進度與卡點
• 準備會議相關溝通
• 向非技術利害關係人說明技術問題
• 改寫過於直接、模糊或太技術導向的草稿

對於遠端與 async 團隊來說，它尤其實用，因為這類環境裡，訊息結構的重要性往往不亞於語氣。

professional-communication 和一般寫作提示有什麼不同

一般提示詞可以把文字改得「比較專業」。但當你需要的不只是修飾語氣，而是更好的訊息結構與受眾適配時，professional-communication 會更有價值。這個 repository 內含多份實用參考資料，包括：

• What-Why-How 溝通結構
• 開發者 email 範本
• 會議結構設計
• 面向非技術讀者的術語簡化方法
• 遠端與 async 溝通的 channel 使用指引

也就是說，它提供的是可重複使用的溝通模式，而不只是表層改寫。

professional-communication 最適合的 Workplace Communication 使用情境

當訊息既要清楚、又要能推動實際工作時，就很適合使用 professional-communication for Workplace Communication。常見好例子包括：

• 一封能清楚交代狀態、風險與下一步的 stakeholder 更新
• 一則明確寫出期限與回饋範圍的 review request
• 一份避免會議發散的 agenda
• 一則會後摘要，整理決策與負責人
• 一段改寫給 product、sales 或管理層閱讀的技術說明

這個技能比較不擅長的地方

這不是談判手冊、法務審閱工具，也不是深入的衝突處理框架。它同樣無法取代領域知識：如果你的事實、時程或受眾需求本身就不清楚，輸出看起來即使整齊，仍然可能抓不到重點。

如何使用 professional-communication 技能

安裝 professional-communication 技能

如果你是透過 softaworks/agent-toolkit repository 使用這個技能，可用以下指令安裝：

npx skills add softaworks/agent-toolkit --skill professional-communication

如果你的環境以不同方式載入技能，請依照平台慣用的 skill 匯入流程，並指向 skills/professional-communication 裡的 professional-communication 技能。

先讀這些檔案

如果你想快速而實際地掌握這個技能，建議先依序閱讀：

1. skills/professional-communication/SKILL.md
2. skills/professional-communication/references/email-templates.md
3. skills/professional-communication/references/jargon-simplification.md
4. skills/professional-communication/references/meeting-structures.md
5. skills/professional-communication/references/remote-async-communication.md
6. skills/professional-communication/README.md

這個順序符合多數人採用此技能的實際路徑：先理解框架，再看範本，最後處理受眾與 channel 選擇。

professional-communication 要發揮效果，需要哪些輸入

professional-communication usage 的品質，高度取決於你提供的輸入資訊。最好先把以下內容交給 agent：

• 訊息類型：email、Slack message、meeting agenda、summary、status update
• 受眾：engineer、manager、exec、customer-facing team、mixed audience
• 目的：inform、request、unblock、decide、summarize
• 背景脈絡：發生了什麼、重要的是什麼、哪些地方改變了
• 需要對方採取的行動：review、decision、approval、attendance、awareness
• 緊急程度或截止時間
• 偏好的語氣：concise、direct、warm、neutral
• channel 限制：async、formal、short、documented、high-stakes

少了這些資訊，agent 通常就會退回到很通用的商務語言。

把模糊目標改成高品質提示

弱提示：

Write a professional update about the API issue.

較強的提示：

Use the professional-communication skill to draft a stakeholder update email. Audience: product manager and engineering manager. Goal: explain that the API release will slip by 2 days because integration tests found a data mapping issue. Include what happened, why it matters, what we are doing next, current risk, and whether I need a decision from them. Keep jargon light and make the ask explicit.

這種寫法有效，因為它一次提供了受眾、目的、範圍、事實內容，以及成功條件。

預設先用 What-Why-How 結構

這個 repository 的核心是一套適用於多數職場寫作的簡單框架：

• What: 主題、請求或變更是什麼
• Why: 為什麼重要、背景是什麼、影響在哪裡
• How: 下一步、行動項目、負責人與時程

如果你不確定訊息該怎麼編排，可以先要求 agent 用這個方式組織內容，再調整語氣。

下筆前先選對輸出形式

這份 professional-communication guide 最實用的一點之一，在於它會幫你判斷：這件事到底應不應該寫成一則訊息。你可以根據參考資料選擇：

• Slack/Teams：適合快速協調
• email：適合正式更新、review request，或需要讓更多人看到的情境
• document：適合提案、決策與 async 回饋
• meeting agenda：只有在同步討論真的有必要時才使用

如果你的議題需要可長期留存的背景脈絡，或需要多人審閱，與其發聊天訊息，不如直接請 agent 先產出 doc outline。

把參考範本當作骨架，不要照稿念

當你手上其實已有事實內容，只是缺一個好結構時，references/email-templates.md 會特別有幫助。實務上可用這個流程：

1. 先選最接近的 template
2. 用你的真實情境替換 placeholder
3. 刪掉不重要的段落
4. 把請求寫得具體明確

例如，當你在寫 review request 時，如果能明講時間點與回饋類型，效果通常會好很多，像是「logic correctness」和「copy edits」就是完全不同的請求。

依受眾調整技術深度

當真正的失敗點不是語氣，而是對方看不懂時，references/jargon-simplification.md 就很有價值。你可以要求 agent 在保留原意的前提下，把術語換成受眾聽得懂的說法。

好的指令像這樣：

Explain this to a product stakeholder. Keep technical accuracy, but replace implementation terms with plain-language equivalents where possible.

這會比單純叫它「simplify」更好，因為後者常常把重要的操作性細節一起刪掉。

善用會議參考資料改善議程與會後追蹤

會議參考檔不只在規劃前有用，會前與會後都能派上用場。你可以請 agent：

• 把零散 bullet points 整理成有時間分配的 agenda
• 把凌亂筆記轉成決策、行動項目與負責人
• 找出反模式，例如 standup 塞太多內容，或 planning session 目標模糊

對於會議輸出來說，最關鍵的欄位通常是 decision、owner、deadline，以及尚未解決的問題。

日常使用的建議 workflow

實務上，一個 professional-communication install 值不值得裝，常取決於它能不能融入你可重複執行的工作流程。常見且有效的流程是：

1. 先寫一版粗略但事實正確的草稿
2. 告訴 agent 受眾與目標
3. 請它套用 professional-communication
4. 檢查內容是否準確、是否有隱含假設、是否少了明確請求
5. 在送出前再縮短一次

當你其實已經知道事實，只是需要更好的 framing、排序與受眾適配時，這個技能最有價值。

平常大多有效的實用提示

你可以試試這類提示：

• Use professional-communication to turn these notes into a concise status update for my manager.
• Draft a Slack message asking for PR review. Include deadline, scope, and what feedback I need most.
• Rewrite this engineering explanation for non-technical stakeholders using plain language.
• Create a sprint planning agenda from these goals and constraints.
• Turn these meeting notes into a summary with decisions, owners, and follow-ups.

導入時常見的卡點

在你真正依賴這個技能前，先了解幾個主要阻礙：

• 你提供的事實背景不夠完整
• 你只要求「professional」，卻沒有說明受眾與目標
• 你把它用在敏感的人資、法務或人際衝突情境，而這些情境需要的不只是結構
• 你期待它自己推斷組織政治或缺失的專案資訊

如果這些情況在你的工作中很常見，就不適合把第一版直接送出；你需要保留較仔細的人工審查。

professional-communication 技能 FAQ

如果我本來就能提示 AI 改寫文字，還值得安裝 professional-communication 嗎？

值得，前提是你的問題來自反覆出現的職場溝通需求，而不是偶發的一次性修稿。professional-communication skill 提供的是可重用的結構模式、受眾適配、async 溝通方法，以及常見開發者情境的處理方式。相較於空白提示如「把這段寫得更專業」，它能明顯減少摸索成本。

這個技能對新手友善嗎？

友善。它容易上手，因為核心框架很簡單，參考資料也很具體。初學者通常最能受益於 templates 與會議結構；較有經驗的使用者，則更能從受眾定位與 channel 選擇中獲益。

什麼情況不該用 professional-communication？

以下情況建議跳過 professional-communication：

• 需要法律或政策敏感措辭
• 高衝突人際情境中的協調或 mediation
• 強說服導向的 sales 或 marketing 文案
• 需要很強商業判斷的深度策略 memo

它最擅長的是偏操作型、面向團隊與 stakeholder 的職場溝通。

它對 async 和遠端團隊有幫助嗎？

有。repository 中有一份非常實用的參考資料，專門談 remote 與 async 溝通，包括什麼時候不該開會、以及如何選對 channel。這也讓它不只是單純的「email 寫作助手」。

professional-communication 能幫忙處理非技術受眾嗎？

可以，而且這正是它較強的一類使用情境。術語簡化參考資料能協助你把工程用語轉成白話說法，同時不丟掉核心意思。這對 product、管理層、support、sales，或其他跨職能夥伴都很實用。

它只適合用來寫 email 嗎？

不是。這個 repository 支援 email、chat、status updates、meeting agendas、summaries，以及受眾調整。實務上，只要是短訊息需要同時做到清楚、可執行、好掃讀，它通常都有價值。

如何提升 professional-communication 技能的使用效果

先給事實，再談風格

professional-communication 最大的品質提升，通常來自事實資訊是否完整，而不是你用了多少形容詞式的要求。在你要求「polished」或「executive-friendly」之前，先提供：

• 目前狀態
• 卡點或風險
• 期待對方採取的行動
• 截止時間
• 閱讀對象是誰

先把操作層面的內容說對，風格才有意義。

受眾要講得更精準

只寫「stakeholders」通常太模糊。最好明確指出是：

• engineering peers
• direct manager
• product manager
• executive sponsor
• customer-facing team
• mixed technical and non-technical audience

當技能知道讀者能理解多少背景與術語時，表現會明顯更好。

明確寫出要對方做什麼，以及成功條件

很多職場訊息之所以弱，不是因為寫得不順，而是請求藏得太深。要改善輸出，可以直接告訴 agent 讀者下一步應該做什麼：

• 在週五前核准
• 只 review 這兩個段落
• 參加會議前先準備在 A 與 B 方案之間做選擇
• 確認目前的時程風險是否可接受

這樣訊息就不會只是看似有資訊量，實際上卻很被動。

先丟原始筆記，再要求它整理結構

不要過度先清理輸入。這個技能很擅長把粗糙筆記整理成更好的格式。一個很實用的模式是：

Here are my messy notes. Use professional-communication to turn them into a clear update for a non-technical manager. Preserve the key facts, reduce jargon, and end with the decision I need.

這通常會比你先自己大量修稿、結果把有用細節一起刪掉來得更好。

讓 channel 和溝通任務匹配

一個很常見的失敗模式是：你請這個技能改善一則訊息，但問題其實是這件事本來就不該用那種形式表達。如果需要可留存的背景脈絡，就請它產出 document 或 summary；如果只是要快速協調，就請它寫成短 chat message。很多時候，選對 channel 比把句子寫漂亮更重要。

留意過度柔化或過度正式

AI 產出的職場文字，很容易變得太謹慎、太冗長，或太空泛。拿到第一版後，可以用以下方式收緊內容：

• Make this 30% shorter.
• Keep the tone professional but more direct.
• Replace generic phrases with concrete next steps.
• Keep the request explicit in the first paragraph.

這一點對 Slack、status updates 和 review requests 特別重要。

用能對準真正問題的迭代提示

拿到第一版後，請用具體 follow-up 改進它，例如：

• Make the risk clearer without sounding alarmist.
• Explain the impact in plain language for leadership.
• Add owners and dates to the action items.
• Remove unnecessary background and keep only decision-relevant context.

比起反覆只說「再改善一下」，這種有明確目標的迭代通常有效得多。

建立一套小型內部提示格式

如果你經常使用 professional-communication for Workplace Communication，很值得把自己的提示格式標準化，例如固定包含：

• message type
• audience
• objective
• facts
• constraints
• required action
• tone

這會讓技能用起來更快，也能讓更新、請求與會議材料之間維持一致性。

最後仍要檢查真實性、組織語境與缺漏脈絡

最後一道人工檢查仍然很重要。送出前，請確認：

• 事實是否正確
• 主要請求是否夠明顯
• 是否缺少受眾需要的背景資訊
• 語氣是否符合你的團隊文化
• 訊息是否已把決策清楚記錄下來，方便日後查閱

這也是 professional-communication 真正變得有用的地方：它能加速高品質溝通，但最終什麼內容真的該送出，仍然要靠你的判斷。