SKILL文件构成

skill本质就是一个文件夹，常见结构如下

skill-name/
├── SKILL.md
├── agents/
│   └── openai.yaml
├── scripts/
├── references/
└── assets/

SKILL.md

必须有，是核心文件，是skill的说明书，主要功能：1.skill的功能；2.AI触发了以后该怎么做。可以理解为是一个入口文件。

agents/openai.yaml

这是和界面展示相关的配置文件，通常也需要。

主要功能：1.Skill 在界面里显示的名字；2.简短介绍；3.图标颜色等展示信息。

scripts

主要存放可执行脚本，适合放那些需要精确执行的步骤，例如：Python脚本、shell脚本、JavaScript脚本等。

例如：PDF旋转、数据清洗、固定格式转换这类，写成脚本比使用文字指令更有效。

references

主要存放参考资料，比如：表结构说明、接口文档、输出规范、业务规则、示例说明。这些内容不是每次都需要使用，但是在某些步骤又特别好用，所以专门使用references来存放，而不是全部堆在SKILL.md里面。

assets

这里存放输出所用的素材，比如logo、模版文件、示例表格、固定图片、字体、样式资源等。这些内容不是让模型读懂的，是让模型直接拿来使用的内容。

总结

skill主要分为两层，触发层和执行层

触发层是告诉AI什么时候调用SKILL，用户说什么类型的话时执行SKILL

执行层就是告诉AI怎么做，触发以后的流程是什么样的，是否运行脚本，输出格式什么样

SKILL.md文件

SKILL.md主要分为两大部分

YAML frontmatter和Markdown正文

结构如下

---
name: your-skill-name
description: describe what the skill does and when it should be used
---

# Overview
这里写技能的核心作用和执行说明

## Workflow
这里写步骤

## Resources
这里写参考文件或脚本怎么用

## Output Requirements
这里写输出要求

Frontmatter

在YAML部分主要有两个关键字段，name和description

name是skill的名称，要求：小写、简短、用连字符连接单词、不要把skill这个词放进名字里。

例如：meeting-summary、official-document-drafting

description是触发的依旧，主要描述这个skill该做什么、什么时候使用。

例如：

description: summarize meeting notes into structured decisions, action items, and follow-ups. use when the user provides raw meeting content, transcripts, or notes and wants a clean, organized summary.

description应该尽可能详细，二不能太泛太简单！

Markdown

Markdown部分就是正文，正文不是用来决定“是否触发”的，主要是用来规定“触发之后怎么干”。

# Overview

overview是一级标题所以只用一个#，而二级标题则需要使用两个##

开头首先说明skill的任务重点，如下所示：

# Overview

Turn messy meeting notes into a structured summary.
Identify decisions, action items, open questions, and risks.
Keep the output concise and scannable.

Overview不是在重复frontmatter，Overview的作用是给已经触发该 Skill 的 ChatGPT一个总体执行说明。

语法方面：

普通段落，直接在下面写就可以

# Overview

Transform raw meeting notes into a structured summary.

换段落需要再空一行，这样就可以显示两个段落

# Overview

第一段内容。

第二段内容。

## Workflow

Workflow是二级标题，所以需要使用两个##，此标题下的主要内容就是写步骤流程。

在工作流中最常见的语法就是有序列表，如下所示

## Workflow

1. Read the input and identify its type.
2. Extract the main points.
3. Organize the content into the required structure.
4. Check whether any required field is missing.
5. Produce the final answer in the requested format.

同样的，还可以在每一个步骤下写子项，语法如下所示

## Workflow

1. Read the input.
   - Determine whether it is a transcript, bullet note, or summary.
   - Identify missing or ambiguous information.

2. Extract key content.
   - Capture decisions.
   - Capture action items.
   - Capture deadlines and owners.

3. Format the output.
   - Use the required section order.
   - Mark missing information explicitly.

其中1. 2. 3.叫做有序列表，而-叫做无须列表

Workflow总结：明确先后顺序；多步骤执行流程；标准操作步骤。

## Resources

Resources标题下，主要的功能就是写外部的文件如何配合使用

语法上，通常是列表+链接的组合，如下所示

## Resources

- For output examples, see [references/examples.md](references/examples.md).
- For tone and style rules, see [references/style-guide.md](references/style-guide.md).
- For deterministic parsing, use [scripts/parse_notes.py](scripts/parse_notes.py).

Markdown链接语法：[显示文字](路径)

在方括号[]里面是显示出来的文字的文字，在园括号()里面是实际路径，所以这样写也可以[examples](references/examples.md)

条件说明写法 Use []() when ...   Use[]() only...

## Resources

- Use [references/transcript-rules.md](references/transcript-rules.md) when the input is a full meeting transcript.
- Use [references/summary-template.md](references/summary-template.md) when the user requests a short executive summary.
- Use [scripts/extract_dates.py](scripts/extract_dates.py) only when date normalization is required.

这样可以更好的告诉AI，不是所有资源一起使用，而是根据条件来使用！

## Output Requirements

Output Requirements的作用是规定输出怎么长，怎么写

Skill最终稳不稳定，终究是取决于输出是否具体

可以先直说使用如下结构：

Use the following structure:

然后使用无序列表列举要求

- Keep the summary concise.
- Do not invent facts.

然后使用有序列表来说明输出顺序

1. Summary
2. Decisions
3. Action Items

可以使用子列表来说清楚每一条要求的细项

- For each action item, include:
  - task
  - owner
  - deadline

加粗，作用：强调原样输出内容

**not specified**

行内代码，作用：强调字段名、固定标签、结构名、格式名

`owner`
`deadline`
`JSON`

SKILL.md完整实例

---
name: meeting-note-summarizer
description: summarize meeting notes and transcripts into structured decisions, action items, owners, deadlines, and open questions. use when chatgpt needs to convert raw meeting content into follow-up-ready documentation.
---

# Overview

这个 Skill 用于将原始会议记录、会议纪要或逐字稿整理为结构化输出，便于后续跟进和执行。

当输入内容较为零散、包含口语化表达、重复讨论或未整理的会议笔记时，按照下方流程进行处理。优先提取明确结论、行动项、负责人、截止时间以及未解决问题。

## Workflow

1. 先阅读输入内容，判断它属于哪一种类型：
   - 完整逐字稿
   - 简要会议笔记
   - 已经初步整理过的纪要

2. 提取会议中的关键信息：
   - 明确达成的决定
   - 需要后续执行的事项
   - 已经指出的风险、阻塞或分歧
   - 尚未确认的问题

3. 对行动项进行结构化整理：
   - 识别 `task`
   - 识别 `owner`
   - 识别 `deadline`

4. 如果负责人或截止时间没有被明确写出，不要猜测，直接标注为 `not specified`。

5. 按照输出要求生成最终结果，确保结构统一、表述简洁、便于后续跟进。

## Resources

- 如需查看输出格式示例，参见 [references/examples.md](references/examples.md)。
- 如需查看风格说明，参见 [references/style-guide.md](references/style-guide.md)。
- 如需进行日期标准化处理，使用 [scripts/normalize_dates.py](scripts/normalize_dates.py)。
- 当输入是完整逐字稿时，可优先参考 [references/transcript-rules.md](references/transcript-rules.md)。

## Output Requirements

Use the following section order:
1. Summary
2. Decisions
3. Action Items
4. Risks
5. Open Questions

对输出应用以下要求：

- `Summary` 部分应简洁概括会议核心内容，通常控制在 3 到 5 句。
- `Decisions` 只记录已经明确达成一致的决定，不要把讨论过程误写成结论。
- `Action Items` 中的每一项都应尽量包含：
  - `task`
  - `owner`
  - `deadline`

- 如果某项信息缺失，必须显式标注为 `not specified`。
- 保留项目名称、团队名称、专有名词的原始写法，不要擅自改写。
- 不要虚构事实，不要补全未被明确提及的负责人或时间。
- 除非用户明确要求，否则不要大段复述原始会议内容。

中文模版

---
name: meeting-minutes-writer
description: 用于整理会议记录、提炼行动项、规范纪要格式，并生成正式会议纪要文本。适用于用户请求撰写、整理、改写、润色、结构化会议纪要、讨论记录、访谈记录、工作复盘等场景，尤其适合需要固定输出格式、统一措辞和明确待办事项的任务。
---

# 概述

本技能用于帮助 ChatGPT 稳定地完成会议纪要整理类任务，包括但不限于：

- 将原始会议录音转写文本整理为正式纪要
- 将零散讨论内容提炼为结构化要点
- 提取决议事项、责任人、截止时间和后续行动
- 按固定模板输出规范化纪要
- 根据不同会议类型调整语言风格和结构

在执行任务时，优先保证以下目标：

1. 信息准确，不随意补充未提及内容
2. 结构清晰，便于快速阅读
3. 行动项明确，责任到人
4. 用语正式、简洁、可直接发送或归档

# 处理原则

## 1. 忠实原始信息

- 仅基于用户提供的内容进行整理
- 不得臆造结论、时间、责任人或决策
- 当原始信息不完整时，应明确标注“未说明”或“待确认”

## 2. 优先结构化输出

默认将内容整理为以下几类：

- 会议基本信息
- 会议核心讨论
- 已形成的结论
- 待办事项
- 风险与待确认问题

## 3. 语言风格要求

除非用户另有要求，否则默认采用：

- 简洁
- 正式
- 中性
- 适合企业内部流转

避免使用：

- 口语化表达
- 过度修饰性语言
- 模糊指代
- 冗长重复句式

## 4. 不确定信息处理

遇到以下情况时，不要自行猜测，应明确说明：

- 发言人身份不清
- 决议是否最终确定不清
- 时间节点缺失
- 责任人未明确
- 内容互相矛盾

可使用如下表达：

- “原始材料中未明确说明”
- “此处责任人待确认”
- “该事项是否已最终确定，需进一步核实”
- “时间安排在原文中未给出”

# 标准工作流程

## 第一步：识别输入内容类型

先判断用户提供的是哪一种材料：

- 原始会议速记
- 录音转写稿
- 聊天记录
- 零散笔记
- 已有初稿，需润色
- 多份材料合并整理

如果输入内容较混乱，先完成信息清洗，再进入正式整理。

## 第二步：提取关键信息

优先提取以下内容：

- 会议主题
- 会议时间
- 与会人员
- 核心议题
- 主要观点
- 决策结论
- 行动项
- 责任人
- 时间节点

若部分信息缺失，可保留空缺并标注待补充。

## 第三步：合并与去重

对重复、近似或表述不同但含义相同的内容进行合并，避免纪要冗余。

处理时注意：

- 保留信息密度更高的表达
- 删除无实质信息的寒暄和重复确认
- 保留对决策有影响的分歧意见

## 第四步：输出结构化纪要

默认输出为正式会议纪要格式。若用户指定为“简版纪要”“领导汇报版”“行动清单版”，则按指定格式输出。

## 第五步：补充提示信息

在不影响正文正式性的前提下，可在末尾补充：

- 待确认事项
- 资料缺失项
- 建议补充的信息

# 默认输出模板

## 模板一：正式会议纪要

### 会议纪要

**一、会议基本信息**  
- 会议主题：  
- 会议时间：  
- 会议地点：  
- 参会人员：  
- 主持人：  
- 记录人：  

**二、会议讨论要点**  
1.  
2.  
3.  

**三、形成的结论**  
1.  
2.  
3.  

**四、后续行动项**  
| 序号 | 事项 | 责任人 | 截止时间 | 备注 |
|------|------|--------|----------|------|
| 1 |  |  |  |  |
| 2 |  |  |  |  |

**五、待确认事项**  
1.  
2.  

---

## 模板二：简版纪要

### 会议纪要（简版）

- **会议主题：**
- **时间：**
- **参会人员：**
- **核心结论：**
  - 
  - 
- **行动项：**
  - 
  - 

---

## 模板三：行动项清单版

### 会议行动项清单

| 序号 | 任务 | 具体要求 | 责任人 | 完成时间 | 协同方 |
|------|------|----------|--------|----------|--------|
| 1 |  |  |  |  |  |
| 2 |  |  |  |  |  |

# 特殊场景处理

## 1. 领导讲话类会议

若材料以领导发言为主，应：

- 优先提炼指导意见和工作要求
- 弱化琐碎讨论过程
- 强化部署、要求、节点、责任分工
- 语言更正式、更凝练

## 2. 讨论分歧较多的会议

若会议未形成统一结论，应：

- 分开列出各方观点
- 明确哪些内容已达成一致，哪些仍待讨论
- 不将讨论意见误写成正式决议

## 3. 跨部门协同会议

应特别关注：

- 部门分工
- 依赖关系
- 前后置条件
- 对接人
- 时间衔接

## 4. 用户要求“润色已有纪要”

此时应：

- 保留原有结构和事实
- 提升表达准确性与正式程度
- 修正歧义、病句、重复和逻辑不清之处
- 不随意扩写未出现内容

# 输出质量检查清单

在输出前，检查以下内容：

- 是否遗漏关键议题
- 是否将“讨论意见”误写成“最终决议”
- 是否所有行动项都尽可能对应责任人
- 是否存在时间、人物、事项指代不清
- 是否有明显重复内容
- 是否符合用户指定格式
- 是否语言简洁、正式、可直接使用

# 示例

## 示例一：将杂乱记录整理为纪要

### 输入

- 产品上线时间大家倾向于下周三
- 技术说接口还有两个问题
- 市场部希望宣传文案周一前确认
- 张三负责再和研发确认风险
- 李四出最终文案

### 输出

### 会议纪要

**一、会议讨论要点**  
1. 产品上线时间初步倾向定为下周三。  
2. 技术侧反馈当前接口仍存在两个待解决问题。  
3. 市场部提出宣传文案需于周一前完成确认。  

**二、形成的结论**  
1. 产品上线计划暂按下周三推进。  
2. 上线前需先完成接口问题核实与处理。  
3. 宣传文案由相关负责人尽快定稿。  

**三、后续行动项**  

| 序号 | 事项 | 责任人 | 截止时间 | 备注 |
|------|------|--------|----------|------|
| 1 | 与研发确认接口风险及处理情况 | 张三 | 待确认 | 影响上线安排 |
| 2 | 输出最终宣传文案 | 李四 | 周一前 | 提供市场使用 |

## 示例二：信息不完整时的处理

若原始材料未写明会议时间、参会人员、责任人，不要自行补充，可写为：

- 会议时间：原始材料中未说明
- 参会人员：原始材料中未说明
- 责任人：待确认

# 执行要求

在使用本技能时，ChatGPT 必须：

1. 先理解用户目标，是“整理”“提炼”“改写”“润色”还是“套模板输出”
2. 再根据输入完整度决定输出详略
3. 默认给出可直接使用的成稿
4. 当信息不足时，明确标注不确定项，而不是猜测
5. 除非用户要求保留口语风格，否则统一改写为书面表达

# 优先级规则

当多个要求同时出现时，按以下优先级执行：

1. 用户明确指定的格式要求
2. 用户明确指定的语言风格
3. 信息准确与事实忠实
4. 结构化与可执行性
5. 表达简洁性

# 可扩展方向

如有需要，可在本技能目录中补充以下资源：

- `references/templates.md`：更多纪要模板
- `references/style-guide.md`：不同文风规范
- `assets/纪要模板.docx`：固定格式模板
- `scripts/clean_notes.py`：对原始速记文本进行预清洗的脚本

如果这些资源存在，在相关任务中优先参考或调用。