用会议后事项跟进 Skill 讲透新手最常见的 8 个坑

这一章不再泛泛讲“Skill 要不要装很多”。

我们只盯着一个真实场景：

凡是涉及多人协作的会议，纪要必须在会后 24 小时内整理出行动项，每个行动项都要包含负责人、截止时间、交付物和确认人；没有负责人或截止时间的事项不能进入待办列表，内容是当提到小王的时候，就合并进他的工作安排中，工作安排通常在项目路径下的 week-jobs/xiaowang.md 中。

这不是一个“会议纪要润色”需求。

它真正要做的是会议后事项跟进：

• 从会议材料里识别行动项。
• 过滤掉缺少负责人或截止时间的事项。
• 保留负责人、截止时间、交付物、确认人。
• 遇到小王相关事项时，合并进 week-jobs/xiaowang.md。

这类 Skill 特别适合拿来讲新手坑。

因为它看起来很小，实际边界很容易滑坡。你一不小心，就会把它写成“所有会议都管、所有待办都管、所有人的工作安排都管、所有项目管理都管”的超级 Skill。到最后，它既容易误触发，又容易改错文件，还会在每次触发时吃掉一大块上下文。

先把结论放前面：

会议后事项跟进 Skill 应该是项目级、强触发、轻正文、窄边界、可回归的工作单元。

为什么？

因为 Skill 不是常驻大脑增强包。Codex 通常先看到 Skill 的名字和 description，等任务相关时才加载完整 SKILL.md。一旦加载，正文就会进入上下文，和用户请求、对话历史、系统提示一起竞争空间。¹²

所以这一章用同一个会议后事项跟进 Skill，讲 8 个新手最常踩的坑。

---

1. 把项目规则装到用户级

会议后事项跟进 Skill 的第一件事不是写正文，而是先判断它应该装在哪里。

这个案例里有一条非常关键的线索：

工作安排通常在项目路径下的 week-jobs/xiaowang.md 中

只要规则写到了项目路径、项目文件、项目成员，就优先放项目级 Skill。

比如你的项目是 /Users/wing/Develop/codex-tranfu-demo，那么这个 Skill 更适合放在 /Users/wing/Develop/codex-tranfu-demo/.codex/skills/organize-meeting-actions/SKILL.md。

它不适合直接装到用户级。

原因很简单：week-jobs/xiaowang.md 不是你所有项目都有的文件。小王也不是你所有项目里都有的人。把这条规则装到用户级，Codex 在别的项目里也可能误以为应该找这个文件，甚至创建一个不该出现的 week-jobs/xiaowang.md。

用户级更适合放通用方法，例如：

• 如何判断 Skill 是否值得创建。
• 如何审查 Skill 的 description。
• 如何发布或安装 Skill。
• 如何用提问澄清不明确需求。

项目级才适合放这类规则：

• 多人协作会议会后 24 小时内整理行动项。
• 行动项必须包含负责人、截止时间、交付物、确认人。
• 没有负责人或截止时间不能进入待办列表。
• 小王相关事项要合并到 week-jobs/xiaowang.md。

判断方法很直接：

规则内容	推荐位置
所有项目都适用的 Skill 写作方法	用户级
所有会议都适用的行动项基本格式	可能用户级
绑定某个项目路径的工作安排规则	项目级
绑定某个成员文件的小王跟进规则	项目级

新手常犯的错，是把“我常用”误认为“所有项目都该用”。

会议后事项跟进 Skill 要反过来想：

只要它会读写当前项目里的具体文件，就先按项目级处理。

---

2. 不先判断主 Skill，就让相邻 Skill 抢边界

更准确地说，问题通常不在“你会不会拆出很多微 Skill”。

真实工作里，很少有人按程序步骤拆零件，把每个字段检查都做成独立 Skill。

更真实的问题是：你的工作台里已经有几个“看起来都能处理一点”的 Skill。

比如：

Skill	看起来能处理的部分
meeting-notes-summary	把会议记录整理成正式纪要
project-todo-triage	从项目材料里提取待办和风险
weekly-worklog-sync	把成员事项合并进 week-jobs/
lark-meeting-cleanup	清理飞书会议转写和聊天记录
follow-up-message-draft	根据待办起草会后提醒话术

这些名字都合理，也都不是瞎拆。

问题是，用户只说一句：

把这次会议里小王的后续事项整理一下。

到底该用哪个？

Skill 不是越多越强。它更像按需调用的操作卡片。装很多 Skill，不代表它们每次都会一起帮忙；Skills 会按任务相关性自动使用，不需要你每次手动点名。³

这里要先判断“主 Skill”。

主 Skill 不看输入长什么样，而看最后不可省的结果是什么。

如果用户只是要：

把这段会议记录整理成纪要。

那主 Skill 可以是 meeting-notes-summary，甚至普通 prompt 就够。

如果用户要：

把会议里小王的后续事项整理出来，并合并进他的工作安排。

那主 Skill 就应该是项目级的：

organize-meeting-actions

因为这个任务的成败，不取决于纪要写得漂不漂亮，而取决于：

• 有没有提取可跟进的行动项。
• 有没有过滤掉缺负责人或截止时间的事项。
• 有没有把小王相关事项合并进 week-jobs/xiaowang.md。
• 有没有保护旧任务不被覆盖。

其它 Skill 可以作为辅助，但不应该抢主导。

比如飞书转写很乱，可以先让 lark-meeting-cleanup 清理材料；但真正决定行动项是否进入待办、是否写入 week-jobs/xiaowang.md 的，仍然应该是 organize-meeting-actions。

装之前先问这 5 个问题：

问题	通过才装
下周还会处理同类会议吗？	会
是否每次都要检查行动项字段？	是
是否每次都要更新小王工作安排？	是
是否比临时 prompt 更稳定？	是
是否能和已有会议、待办、周报 Skill 分清主次？	能

这些就先别装：

• 只是把会议内容总结得更好听。
• 只偶尔给小王整理一次任务。
• description 写成“资料整理、待办管理、项目推进”。
• 和已有会议纪要 Skill 只有名字差异，没有不同失败标准。
• 需要读写文件，但你没确认它会改哪些路径。

你可以让 Codex 先帮你清理 Skill 工具台：

帮我审查当前可用的 Skills。

只围绕“会议后事项跟进”判断：
1. 哪个 Skill 应该做主 Skill
2. 哪些 Skill 只能作为前置清理或辅助输出
3. 哪些 description 太泛，可能抢错任务
4. 哪些应该合并、改名、收窄或暂时不用

输出判断理由和建议动作，不要解释概念。

一个好 Skill 不靠名字多，而靠主任务判断稳定。

会议后事项跟进就是这种任务：重复、规则明确、出错成本不低。

---

3. description 写成了“会议纪要整理”

会议后事项跟进 Skill 最容易死在 description 上。

坏例子通常长这样：

description: 整理会议纪要、提取待办事项、优化会议内容。

这句话看起来没错，但太宽。

它会带来三个问题。

1. 普通会议摘要也可能触发它。用户只是想要一段纪要摘要，Codex 却可能开始检查负责人和截止时间。
2. 普通待办整理也可能触发它。用户只是整理个人 todo，Codex 却可能去找 week-jobs/xiaowang.md。
3. 文章或周报润色也可能误触发。因为“优化会议内容”这几个字太像内容处理 Skill。

description 是 Skill 的门牌。Codex 通常先看门牌，再决定要不要把完整 SKILL.md 读进来。门牌写宽了，路过也会进；门牌写窄了，该进的时候不进。⁴

这个案例的 description 要把四件事写清楚：

维度	要写清楚的内容
输入	多人协作会议的录音转写、聊天记录、零散会议笔记
输出	可跟进的行动项，以及小王工作安排文件的合并更新
触发	用户要求整理会议后事项、会后待办、小王相关会议任务
排除	普通摘要、文章润色、个人备忘、替负责人拍板

可以这样写：

description: 整理多人协作会议的录音转写、聊天记录和零散笔记，提取会后行动项，并检查每个行动项是否包含负责人、截止时间、交付物和确认人；没有负责人或截止时间的事项不得进入待办列表。当会议内容提到小王，或用户要求同步小王的会议后事项时，把属于小王的行动项合并进项目内 week-jobs/xiaowang.md。用于会议后事项跟进、会后待办整理和小王工作安排同步。不要用于普通会议摘要、文章润色、个人备忘、战略判断、绩效评价，或替负责人确认未拍板事项。

写完以后不要凭感觉说“应该可以”。直接做触发测试。

应该触发：

• 把这次会议里的行动项整理出来，提到小王的同步到他的工作安排。
• 这段飞书会议记录按会后待办处理，负责人和截止时间不全的不要进列表。
• 小王在会上认领的任务帮我合并进 week-jobs/xiaowang.md。

不应该触发：

• 把这次会议摘要写得更正式一点。
• 帮我润色这篇周报。
• 整理一下我今天的个人 todo。
• 评价一下小王这周表现怎么样。

可复制：

请帮我优化这个会议后事项跟进 Skill 的 description。

要求：
1. 保留“多人协作会议 -> 行动项 -> 小王工作安排文件”的边界
2. 明确负责人、截止时间、交付物、确认人四个字段
3. 明确没有负责人或截止时间不能进入待办列表
4. 补上 8 条应该触发的真实用户说法
5. 补上 8 条不应该触发的相邻场景
6. 只改 description，不改正文

Skill 路径：
[粘贴 SKILL.md 路径]

如果会议后事项 Skill 经常误触发，先别急着怪模型。多数时候，是 description 把“会议摘要”“待办管理”“项目管理”这些相邻任务也写进来了。

---

4. 把所有会议规则都塞进 SKILL.md

会议后事项跟进 Skill 一旦触发，完整 SKILL.md 会进入上下文。

这就是为什么它不能写成一份“会议管理百科”。

上下文窗口是公共资源。Skill 会和系统提示、对话历史、其他 Skill 元数据、用户请求一起竞争上下文。即使 SKILL.md 写得有道理，只要它太长，一旦加载，每个 token 都会和其它信息抢位置。¹

这个案例的主文件应该很短。

应该放进 SKILL.md 的，是执行时必须马上知道的规则：

• 只处理多人协作会议后的事项跟进。
• 行动项必须包含负责人、截止时间、交付物、确认人。
• 没有负责人或截止时间，不得进入待办列表。
• 提到小王时，合并进 week-jobs/xiaowang.md。
• 更新文件前先读取现有内容，避免覆盖旧任务。
• 无法判断负责人、截止时间或确认人时，放入待确认，不要编造。

不应该放进主文件的，是低频背景：

• 公司会议文化说明。
• 所有团队成员的职责介绍。
• 会议纪要写作教程。
• 项目管理理论。
• 历史会议完整样例。

如果确实需要长资料，拆到 references/：

Reference	放什么
references/action-item-format.md	行动项字段和示例
references/team-members.md	团队成员角色说明
references/follow-up-examples.md	历史会议样例

但只拆出去还不够。你还要写清楚什么时候读。

这样写才有用：

• 当用户要求解释行动项字段格式时，读取 references/action-item-format.md。
• 当会议里出现不熟悉的成员简称时，读取 references/team-members.md。
• 当用户要求对齐历史写法时，读取 references/follow-up-examples.md。
• 默认不要读取 references/ 下的长样例。

别只写：

更多资料见 references/。

这句话对 Codex 没什么帮助。它知道有仓库，但不知道该翻哪一箱。

固定检查可以脚本化。

比如这个 Skill 的稳定校验可以放到 scripts/：

• 检查输出行动项是否都有负责人。
• 检查输出行动项是否都有截止时间。
• 检查是否意外删除 week-jobs/xiaowang.md 里的旧任务。
• 检查是否把待确认事项写进正式待办列表。

还有一类内容既不是 references/，也不是 scripts/。

它是关键任务流程里的显式动作。

比如会议后事项跟进 Skill 如果只写：

• 必要时澄清。
• 必要时拆分任务。
• 必要时检查文件。

这不够。

这些话太软，Codex 很可能直接往下做。关键流程缺失时，要把 Codex 里更接近的动作写明白。Codex 官方建议复杂或模糊任务先 plan，也可以让 Codex 先 interview 你；subagents 也不会自动触发，必须明确要求 spawn / delegate。⁵⁶

在这个 Skill 里可以这样写：

缺的不是规则，而是流程动作	在 Codex 里应该写成
会议目标、确认人、目标文件不清楚	先进入 Plan mode，或先 interview 用户，问清缺失字段再执行
步骤多，容易漏读旧文件或漏验证	维护执行计划，逐步更新 update_plan：提取、过滤、读旧文件、合并、验证7
会议材料很长，提取行动项会污染主上下文	显式 spawn 一个 subagent，只负责从材料里提取候选行动项并返回摘要
需要实际落地到项目文件	明确读 week-jobs/xiaowang.md、合并编辑、再检查 diff

注意，这里不是把 Claude Code 的 AskUserQuestion、TaskCreate 这些名字照搬进 Codex Skill。

更稳的写法是写 Codex 能直接执行或理解的动作：

• 如果关键字段缺失，先进入 Plan mode 或 interview 用户，不要继续写文件。
• 如果会议材料超过一屏或包含多场会议，spawn 一个 subagent 只做候选行动项提取；主 agent 负责判断哪些能进入正式待办。
• 执行过程中维护 update_plan，至少包含：提取行动项、过滤缺字段事项、读取小王旧工作安排、合并新事项、检查 diff。

可复制：

请压缩这个会议后事项跟进 Skill。

目标：
1. 删除会议管理科普和 Agent 已经知道的通用解释
2. 保留触发边界、行动项字段、待确认规则、文件更新规则
3. 把低频样例拆到 references/
4. 把可机械检查的字段完整性规则放到 scripts/
5. 在 SKILL.md 里写清每个 reference 和 script 什么时候使用
6. 补上关键流程动作：什么时候 Plan/interview，什么时候 update_plan，什么时候 spawn subagent，什么时候读写文件
7. 不改变“多人协作会议 -> 行动项 -> 小王工作安排”的任务边界

Skill 路径：
[粘贴 SKILL.md 路径]

会议后事项跟进 Skill 费不费 token，不只看它有没有用，还看它有没有把低频资料全带上桌。

---

5. 把会议后事项跟进扩大成项目管理

这个 Skill 应该写大一点，还是拆小一点？

不要按字数判断。

按工作单元判断。

更稳的方法是问三件事：

1. 输入是不是同一类？
2. 产出是不是同一种？
3. 失败标准是不是同一个？

对会议后事项跟进来说：

维度	会议后事项跟进的判断
输入	多人协作会议材料
产出	结构化行动项，以及小王工作安排文件更新
失败标准	漏掉行动项、编造负责人、缺少截止时间、覆盖旧任务、误改无关文件

这些可以放在同一个 Skill 里：

候选范围	判断
会议录音、会议聊天记录、零散会议笔记 -> 行动项	可以合
行动项字段完整性检查	可以合
小王相关行动项 -> week-jobs/xiaowang.md	可以合
读取旧工作安排并合并新任务	可以合

这些不要顺手塞进去。不是因为它们不重要，而是它们更像另一个主任务：

候选范围	判断
把所有成员的事项统一归档到 week-jobs/	可能是 weekly-worklog-sync
从会议结论更新项目排期表	可能是项目排期维护 Skill
给参会人起草会后提醒消息	可能是会后沟通 Skill
把会议记录改写成正式纪要	可能是会议纪要 Skill
根据会议内容生成周报	可能是周报 Skill

为什么“写入小王文件”可以合？

因为它不是另一个任务，而是这个会议后事项跟进流程的落地动作。会议里提到小王，如果不更新他的工作安排，这个 Skill 的目标就没完成。

为什么“所有成员事项归档”不要直接合？

因为输入、输出、失败标准都变了。它不再是处理一场会议里的小王事项，而是在维护一套成员工作台账。那可以是另一个 Skill，也可以是后续工作流，但不该悄悄塞进当前 Skill。

可复制：

帮我判断这个会议后事项跟进 Skill 应该拆还是合。

候选范围：
1. 整理多人协作会议行动项
2. 检查负责人、截止时间、交付物、确认人
3. 小王相关事项写入 week-jobs/xiaowang.md
4. 把所有成员事项统一归档到 week-jobs/
5. 根据会议内容起草会后提醒消息

只按这 3 个标准判断：
1. 输入是不是同一类
2. 产出是不是同一种
3. 失败标准是不是同一个

最后输出：
1. 保留一个 / 拆成几个 / 合并到已有 Skill
2. 推荐 Skill 名称
3. 推荐 description 边界
4. 不要覆盖的相邻场景

判断拆还是合，不要问“它能不能顺手也做”。会议后事项跟进 Skill 的边界，通常就是被“顺手把所有人的安排也同步一下”撑爆的。

---

6. 把每次 prompt 都复制成 Skill 正文

prompt 管这一次。

Skill 管以后每一次。

会议后事项跟进特别适合说明这个区别。

如果你只是在某一次会议后说：

• 这次纪要写得口语一点。
• 这次只保留技术相关事项。
• 这次不要更新小王文件，先给我看草稿。

这些是 prompt。

它们只影响这一次，不应该写进 Skill。

但下面这些是每次都要遵守的规则：

• 多人协作会议会后 24 小时内整理行动项。
• 每个行动项必须包含负责人、截止时间、交付物、确认人。
• 没有负责人或截止时间，不能进入待办列表。
• 提到小王时，要合并进 week-jobs/xiaowang.md。
• 更新前读取旧文件，合并而不是覆盖。
• 不确定时放入待确认，不编造。

这些应该写进 Skill。

资料里对这个区别说得很清楚：prompt 是对话级的一次性指令；Skill 是按需加载的可复用专业能力。Skills 适合团队流程、品牌规范、会议纪要格式、数据分析流程这类可重复工作。Custom instructions 更广泛地应用，Skills 只在相关任务加载。⁸²

简单判断：

内容	放哪里
这次纪要语气轻松一点	prompt
这次只看技术事项	prompt
先输出草稿，不写文件	prompt
行动项必须有负责人和截止时间	Skill
小王事项合并进 week-jobs/xiaowang.md	Skill
旧任务不能被覆盖	Skill
长样例和历史写法	references/
字段完整性和文件差异检查	scripts/

千万别把 Skill 写成“我每次都可能想说的话合集”。

会议后事项跟进 Skill 只应该固定这几件事：

• 遇到哪类会议材料。
• 按什么步骤提取行动项。
• 输出什么字段。
• 哪些事项不能进入待办。
• 什么时候更新小王文件。
• 不确定时怎么处理。
• 怎么验证没有漏字段、没覆盖旧任务。

可复制：

请判断下面这些要求应该放进会议后事项跟进 Skill，还是留在本次 prompt。

规则列表：
1. [规则 1]
2. [规则 2]
3. [规则 3]

判断标准：
1. 只对这次会议有效 -> prompt
2. 每次会议后都要遵守 -> Skill
3. 很长但低频 -> references/
4. 可自动校验 -> scripts/

输出表格，不要展开解释。

一句话：你只是今天想这么做，用 prompt；你不想以后每次都重新解释，就写进 Skill。

---

7. 发布后跑歪了就整份重写

会议后事项跟进 Skill 发布后，第一次跑歪很正常。

但不要整份重写。

要先分类。

同样是跑歪，原因可能完全不同：

现象	先改哪里
用户说“整理小王会后事项”但 Skill 没触发	description 太窄
用户只是要会议摘要，Skill 却触发	description 太宽
输出了没有截止时间的待办	workflow 或 gotchas 缺规则
把“待确认”写进正式待办	输出模板不清
覆盖了 week-jobs/xiaowang.md 旧内容	文件更新步骤缺读旧文件
把小张的事项写给小王	负责人归属规则不清
每次都手动检查字段	应该补 scripts/
关键字段缺失时还继续写文件	应该显式要求 Plan mode 或 interview 用户
经常漏掉读取旧文件、合并、验证这几个步骤	应该显式要求维护 update_plan
会议材料太长，主线程里塞满转写细节	应该明确 spawn subagent 做候选行动项提取

第一版 Skill 本来就常常要靠真实任务继续修改。更重要的是，你要看执行轨迹，不只看最终结果。如果 Agent 浪费步骤，常见原因是规则太泛、不适用，或者给了太多同级选项。触发问题还要用 should-trigger / should-not-trigger 查询集反复测。⁹⁴

修改时记住三条：

1. 一次只改一个问题。
2. 每次改完用同一条会议材料回归。
3. 不要为了一个失败案例，把 description 改到过拟合。

再加一条更关键的：

• 如果缺的是任务流程，不要只补一句“注意检查”；要补显式动作。
• 如果缺的是长子任务，不要让主 agent 硬扛；要明确交给 subagent，并规定返回摘要。

比如失败现象是：

会议里说“小王先按现有字段做 mock”，但没有明确截止时间。Codex 把它写进了正式待办。

这时候不要重写整个 Skill。

只补一条 gotcha：

如果行动项缺少负责人或截止时间，必须放入“待确认”，不得写入正式待办，也不得写入 week-jobs/xiaowang.md。

再用同一条会议材料回归。

如果失败现象是：

会议材料很长，Codex 在主线程里贴了大量转写细节，最后漏掉了小王的两条任务。

也不要只补一句“仔细阅读会议材料”。

要补成可执行的子 Agent 规则：

当会议材料很长、包含多段转写或多场会议时，spawn 一个 subagent。该 subagent 只做候选行动项提取，返回负责人、截止时间、交付物、确认人和原文依据。主 agent 不接收原始长转写，只接收摘要后再判断哪些事项能进入正式待办和 week-jobs/xiaowang.md。

如果失败现象是：

Codex 提取了行动项，但忘了先读取 week-jobs/xiaowang.md，直接覆盖了旧内容。

要补成计划规则：

执行时必须维护 update_plan，且不能跳过这 5 步：提取候选行动项、过滤缺负责人或截止时间的事项、读取 week-jobs/xiaowang.md 旧内容、合并新事项、检查 diff 确认旧事项未被删除。

可复制：

这个会议后事项跟进 Skill 发布后跑歪了。

失败现象：
[写清楚哪里错]

真实会议材料：
[粘贴触发请求和会议内容]

请先分类：
1. 触发问题
2. 执行步骤问题
3. 输出格式问题
4. 缺少 gotcha
5. 应该脚本化
6. 是否缺少 Plan/interview/update_plan/文件读写这类显式流程动作
7. 是否应该把过长子任务交给 subagent

然后只做最小修改。
不要重写整份 SKILL.md。
改完后，用同一条会议材料再跑一次。

会议后事项跟进 Skill 的迭代，不靠豪华重构。它靠一次抓住一个偏差。

---

8. 从公司库安装前不看权限和脚本

公司库里的 Skill 也不能闭眼装。

会议后事项跟进 Skill 尤其要小心，因为它通常会读写项目文件：

• 读取会议材料。
• 读取 week-jobs/xiaowang.md。
• 修改 week-jobs/xiaowang.md。
• 可能读取 references/ 里的团队成员说明。
• 可能运行 scripts/ 做字段检查。

资料里说得很直接：只从可信来源安装 Skill；安装不太可信的 Skill 前，要检查其中的文件、依赖、资源和外部网络访问。Skill 的主要风险包括 prompt injection 和 data exfiltration。³

翻译成人话就是：

它可能诱导 Agent 做不该做的事，也可能把不该出去的数据带出去。

安装这个 Skill 前，至少看 6 件事：

1. SKILL.md 的任务边界是不是只处理会议后事项跟进。
2. description 有没有泛化到资料整理、项目管理、绩效评价。
3. allowed-tools / disallowed-tools 有没有给过大权限。
4. scripts/ 是否会读写 week-jobs/ 之外的路径。
5. 是否要求安装第三方包。
6. 是否会访问外部网络或上传会议内容。

优先安装这些：

• 团队验证过。
• 边界只覆盖会议后事项跟进。
• 明确写了读写文件路径。
• 更新文件前会读取旧内容。
• 没有负责人或截止时间不会写入正式待办。
• 脚本只做本地字段检查。

先别安装这些：

• description 写成“整理会议、同步待办、推进项目、跟踪成员”。
• 脚本默认扫描整个项目目录，而不是限定 week-jobs/ 和会议材料。
• 需要联网但没说明原因。
• 会把会议内容发到外部服务。
• 会根据会议内容自动评价成员表现。

可复制：

帮我审查这个公司库里的会议后事项跟进 Skill 是否适合安装到真实项目。

检查：
1. SKILL.md 是否只覆盖多人协作会议后的行动项跟进
2. description 是否太泛，是否会误触发普通摘要、周报、项目管理
3. allowed-tools / disallowed-tools 是否合理
4. scripts/ 是否只做本地字段检查，是否读写敏感文件
5. 是否会访问外部网络或上传会议内容
6. 是否明确保护 week-jobs/xiaowang.md 的旧内容
7. 是否和我已有会议纪要或待办 Skill 重叠

输出：
1. 建议安装 / 先不安装 / 只在练习项目试用
2. 风险点
3. 安装前要问维护者的问题

公司库不是自动可信区。会议内容和成员工作安排都可能敏感，越是会读写项目文件的 Skill，越要先看清楚它能碰哪里。

---

会议后事项跟进 Skill 避坑清单

把这张表贴到每次审查前面。

问题	判断标准
1. 装到哪里？	写到项目路径和小王文件，就放项目级
2. 怎么判断主 Skill？	看最后不可省的结果，不看输入材料像什么
3. 为什么误触发？	多半是 description 把会议摘要、待办管理、项目管理都写进来了
4. 为什么更费 Token？	SKILL.md 太重，触发后抢上下文
5. 写大还是拆小？	输入、产出、失败标准一致就合，否则拆
6. Skill 和 prompt 怎么分工？	一次性偏好放 prompt，重复流程放 Skill
7. 发布后不好用怎么办？	分类问题；流程缺失补显式动作，长子任务指定 subagent
8. 公司库能不能直接装？	先审来源、权限、脚本、联网和文件读写范围

最后给 Codex 的总检查 prompt：

请按“会议后事项跟进 Skill 避坑清单”审查这个 Skill。

检查 8 件事：
1. 是否应该装到项目级
2. 是否值得创建或安装
3. description 是否容易误触发
4. SKILL.md 是否太重
5. 范围应该拆还是合
6. 哪些内容应该留在 prompt
7. 是否缺少 Plan/interview/update_plan/文件读写/subagent 这些显式流程动作
8. 是否适合从公司库安装到真实项目

要求：
1. 先给结论：保留 / 修改 / 不建议安装
2. 每条只写问题和最小修改建议
3. 不要重写整份 Skill

Skill 路径：
[粘贴 SKILL.md 路径]

会议后事项跟进 Skill 真正厉害的地方，不是把“会议纪要”四个字写进一个新文件。

它厉害在：把会后跟进里最容易漏、最容易编、最容易改错文件的规则固定下来。

下次你再丢一段会议记录，Codex 不应该只是写一段漂亮摘要。

它应该知道：

• 哪些是行动项。
• 哪些缺字段不能进待办。
• 哪些属于小王。
• 应该合并到哪个项目文件。
• 哪些不确定必须问。

这才是 Skill 和普通 prompt 的区别。

prompt 解决这一次。

Skill 固定以后每一次。

---

参考资料

这篇只用了能落到操作上的一手资料：

Footnotes

1. Anthropic: Skill authoring best practices ↩ ↩²

2. Claude Help Center: What are Skills? ↩ ↩²

3. Claude Help Center: Use skills in Claude ↩ ↩²

4. Agent Skills: Optimizing skill descriptions ↩ ↩²

5. OpenAI Developers: Codex best practices ↩

6. OpenAI Developers: Codex subagents ↩

7. OpenAI: Unrolling the Codex agent loop ↩

8. Claude Managed Agents: Skills ↩

9. Agent Skills: Best practices for skill creators ↩