这一章不再泛泛讲“Skill 要不要装很多”。
我们只盯着一个真实场景：
凡是涉及多人协作的会议，纪要必须在会后 24 小时内整理出行动项，每个行动项都要包含负责人、截止时间、交付物和确认人；没有负责人或截止时间的事项不能进入待办列表，内容是当提到小王的时候，就合并进他的工作安排中，工作安排通常在项目路径下的
week-jobs/xiaowang.md中。
这不是一个“会议纪要润色”需求。
它真正要做的是会议后事项跟进：
- 从会议材料里识别行动项。
- 过滤掉缺少负责人或截止时间的事项。
- 保留负责人、截止时间、交付物、确认人。
- 遇到小王相关事项时，合并进
week-jobs/xiaowang.md。
这类 Skill 特别适合拿来讲新手坑。
因为它看起来很小，实际边界很容易滑坡。你一不小心，就会把它写成“所有会议都管、所有待办都管、所有人的工作安排都管、所有项目管理都管”的超级 Skill。到最后，它既容易误触发，又容易改错文件，还会在每次触发时吃掉一大块上下文。
先把结论放前面：
会议后事项跟进 Skill 应该是项目级、强触发、轻正文、窄边界、可回归的工作单元。
为什么？
因为 Skill 不是常驻大脑增强包。Codex 通常先看到 Skill 的名字和 description，等任务相关时才加载完整 SKILL.md。一旦加载，正文就会进入上下文，和用户请求、对话历史、系统提示一起竞争空间。12
所以这一章用同一个会议后事项跟进 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 会按任务相关性自动使用，不需要你每次手动点名。3
这里要先判断“主 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: 整理会议纪要、提取待办事项、优化会议内容。这句话看起来没错，但太宽。
它会带来三个问题。
- 普通会议摘要也可能触发它。用户只是想要一段纪要摘要，Codex 却可能开始检查负责人和截止时间。
- 普通待办整理也可能触发它。用户只是整理个人 todo，Codex 却可能去找
week-jobs/xiaowang.md。 - 文章或周报润色也可能误触发。因为“优化会议内容”这几个字太像内容处理 Skill。
description 是 Skill 的门牌。Codex 通常先看门牌，再决定要不要把完整 SKILL.md 读进来。门牌写宽了，路过也会进；门牌写窄了，该进的时候不进。4
这个案例的 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 都会和其它信息抢位置。1
这个案例的主文件应该很短。
应该放进 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。56
在这个 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 应该写大一点，还是拆小一点？
不要按字数判断。
按工作单元判断。
更稳的方法是问三件事：
- 输入是不是同一类？
- 产出是不是同一种？
- 失败标准是不是同一个？
对会议后事项跟进来说：
| 维度 | 会议后事项跟进的判断 |
|---|---|
| 输入 | 多人协作会议材料 |
| 产出 | 结构化行动项，以及小王工作安排文件更新 |
| 失败标准 | 漏掉行动项、编造负责人、缺少截止时间、覆盖旧任务、误改无关文件 |
这些可以放在同一个 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 只在相关任务加载。82
简单判断：
| 内容 | 放哪里 |
|---|---|
| 这次纪要语气轻松一点 | 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 查询集反复测。94
修改时记住三条：
- 一次只改一个问题。
- 每次改完用同一条会议材料回归。
- 不要为了一个失败案例，把
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。3
翻译成人话就是：
它可能诱导 Agent 做不该做的事，也可能把不该出去的数据带出去。
安装这个 Skill 前，至少看 6 件事：
SKILL.md的任务边界是不是只处理会议后事项跟进。description有没有泛化到资料整理、项目管理、绩效评价。allowed-tools/disallowed-tools有没有给过大权限。scripts/是否会读写week-jobs/之外的路径。- 是否要求安装第三方包。
- 是否会访问外部网络或上传会议内容。
优先安装这些：
- 团队验证过。
- 边界只覆盖会议后事项跟进。
- 明确写了读写文件路径。
- 更新文件前会读取旧内容。
- 没有负责人或截止时间不会写入正式待办。
- 脚本只做本地字段检查。
先别安装这些：
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 固定以后每一次。
参考资料
这篇只用了能落到操作上的一手资料：