agentsclimarketplace

Internal comms

Skill findscripter/everything-skills/01-documents/internal-comms

当需要撰写公司内部沟通文书(3P 进展报、全员通讯、FAQ、状态/领导汇报、事故报告等)时使用;做按公司固定格式产出简洁、数据驱动的内部沟通稿;不适用于对外新闻稿、营销文案、SEO 文章或代码文档;触发词:内部沟通、3P 更新、进展报告、周报、全员通讯、newsletter、FAQ、常见问题、领导汇报、status update、incident reportFrom its SKILL.md

Install
npx -y skills add findscripter/everything-skills --skill internal-comms

Assembled 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.
  • 1 stars1 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 file declares

Copied from the file, not written here

The file declares its own license as Apache-2.0. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

6.4 KB, ~2.1k tokens by cl100k_base, as published. Nobody here has run it

何时使用

当被要求撰写公司内部的沟通文书时使用,覆盖以下类型:

  • 3P 进展报(Progress / Plans / Problems 进展、计划、问题)
  • 全员通讯(company newsletter,全公司可读的周报/月报)
  • FAQ(汇总并回答全公司高频问题)
  • 状态报告、领导汇报、项目更新、事故报告等

不该用的边界:对外新闻稿与公关文案、面向客户的营销内容、SEO 长文(用 seo-content-writer)、代码与 API 文档、个人简历。这些都不是「内部沟通」。

核心原则:先判定文书类型,再套用该类型对应的固定格式;内容力求简洁、数据驱动、要点前置。

步骤

  1. 识别类型:从需求判定属于 3P / newsletter / FAQ / 其他通用四类中的哪一种;无法归类时,向用户追问目标受众、目的、语气与格式要求。
  2. 澄清范围:确认团队名 / 公司名与时间范围(Progress、Problems 取「过去一周」,Plans 取「未来一周」)。团队名缺失时直接询问。
  3. 收集信息:尽量从可用来源拉取素材——
    • Slack:大频道里高互动(多回复/多 reaction)的帖子
    • 邮件:高管发出的全公司公告、长内容或多回复邮件
    • 文档(如 Google Drive):高浏览量的关键文档、季度规划、愿景文档
    • 日历:All-Hands、产品评审等大型非例行会议及其附件文档
    • 外部报道:近期媒体引用或获得的报道 若无相关工具权限,直接请用户提供要点;此时你主要负责套格式润色,并可提示「接入这些来源后产出会更好」。
  4. 按固定格式起草:见下方各类型格式,格式必须严格遵守。
  5. 复核:3P 控制在 30-60 秒可读完;尽量带指标;语气就事论事,少用华丽长句。

指令

3P 进展报(受众:高管/领导/同事,对团队有一定但不深的了解;篇幅极短) 固定格式,除此之外不要使用其他格式;emoji 选一个能体现团队与本期氛围的:

[emoji] [团队名](覆盖日期,通常一周)
Progress:[1-3 句,已交付/达成的里程碑/已完成任务,尽量带指标]
Plans:[1-3 句,下周最高优先级、最受关注的事]
Problems:[1-3 句,拖慢团队的阻塞、缺人、bug、谈崩的合作等]

团队越大,任务粒度越粗(如「移动团队:上线了某功能」对比「公司:新招 20 人、签下 10 个新单」)。

全员通讯 newsletter(受众:1000+ 人全公司;经 Slack + 邮件发送) 约 20-25 条 bullet,每条 1-2 句;多放链接(关联文档、公告频道高管帖、全员邮件);用「我们(we)」口吻。按主题分组成节,让公司各板块都被覆盖,例如 {产品研发 / GTM / 财务} 或 {招聘 / 执行 / 愿景} 或 {内部新闻 / 外部新闻}。

:megaphone: 公司公告
- ...
:dart: 重点进展
- 板块一
    - 子项
- 板块二
    - 子项
:pillar: 领导动态
- ...
:thread: 社区/社交动态
- ...

优先:全公司影响、领导公告、重大里程碑、影响多数员工的信息、外部认可/报道。避免:过细的单团队更新(留给 3P)、仅小群体相关的信息、已传达过的重复内容。

FAQ(汇总全公司高频困惑并简答) 格式:

- *问题*:[1 句]
- *回答*:[1-2 句]

要holistic:覆盖整个公司而非提问者本人或其团队。答案尽量基于官方沟通;信息不确定时明确标注;链接到权威来源;语气专业而亲和;需要高管定夺或官方回应的问题要标记出来。常见主题:融资、新高管、即将发布的产品、招聘进展、愿景/重点变化等。

通用内部沟通(不属上述三类时) 先问清:目标受众、沟通目的、期望语气(正式/随意/紧急/告知)、格式要求。原则:清晰简洁、用主动语态、最重要信息前置、附相关链接、贴合公司沟通风格。

示例

3P 进展报:

🚀 移动团队(5/26 - 6/1)
Progress:上线了 v2.3 登录改版,崩溃率下降 18%;关闭 24 个积压 bug。
Plans:开始离线模式预研,目标本周出技术方案;配合营销完成 6/8 发布演练。
Problems:缺 1 名 iOS 工程师,影响排期约 1 周;与支付方联调被对方 API 限流阻塞。

FAQ:

- *问题*:B 轮融资什么时候完成,对期权有何影响?
- *回答*:已于上周完成,公告见 #announce 频道帖子;期权细则将由财务在全员邮件中单独说明(需 HR/财务官方确认)。

注意事项

  • 格式是硬约束:3P 与 newsletter 的版式不要自由发挥。
  • 简洁优先:3P 每节 1-3 句、就事论事;newsletter 每条 1-2 句。
  • 数据驱动:能给指标就给指标,避免空泛形容。
  • 缺信息就问:团队名、时间范围、受众等关键信息缺失时主动澄清,不要臆造。
  • 来源真实:FAQ/通讯里引用的事实应来自官方沟通;不确定要标注,必要时标记需高管定夺。
  • 本技能改写自 Apache-2.0 / 许可源(原 internal-comms),保留其格式与约束要点。

互见

  • fact-checking:发布前核对通讯/FAQ 中引用的事实与数据。
  • markdown-to-docx:需要把成稿导出为 Word 正式文档时。
  • seo-content-writer:面向对外的内容写作(与本技能边界互补)。

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Keep looking

Skills are one crate of 326,835. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.