Skill什么是skillskill就是为AI安装的可重复工作流包把一件经常做并且有固定规则的事情整理成一套模板必要时附上脚本和资源。即Skill 说明书(SKill.md) 元数据(openai.yaml) 可选的脚本/参考资料/资源文件结构skill-name/ | |-- SKILL.md # 必需入口说明告诉 ChatGPT 这个 skill 是做什么的、什么时候触发、怎么做 | |-- agents/ | -- openai.yaml # 必需UI/元数据比如显示名称、简介、图标等 | |-- scripts/ # 可选放可执行脚本适合稳定、可重复的步骤 | |-- analyze.py | -- helper.sh | |-- references/ # 可选放参考资料、规则、模板说明 | |-- schema.md | -- style-guide.md | -- assets/ # 可选放输出会用到的资源文件 |-- template.docx -- logo.png简单实现实现一个git PR变更摘要your-skill/ ├── agents/ │ └── openai.yaml └── SKILL.mdinterface:这一段是在定义这个 skill 的“界面展示信息”。display_name: PR Change Summary这是这个 skill 在界面上显示出来的名字。用户看到的通常就是这个名字而不是目录名。interface:display_name:PR Change Summaryshort_description:Summarize git diffs into short developer-facing updates用---上下包裹着的是元信息name:skill的名字description:触发描述## Overview说明 skill 的总目标## Workflow定义执行步骤### Read the diff structurally结构化阅读变化### Infer the real change推断改动类型### Produce a brief developer summary生成短的摘要## Output rules定义输出边界## Heuristics给出好坏范式--- name: pr-change-summary description: summarize git diff or patch content into a short developer-facing change summary. use when chatgpt or codex is given a git diff, patch, unified diff, or code change snippet and needs to quickly explain what changed, highlight impacted areas, and produce a concise summary for engineers. --- # PR Change Summary ## Overview Turn raw git diff or patch text into a short summary for developers. Focus on what changed, where it changed, and why it likely matters. ## Workflow ### 1. Read the diff structurally Identify: - files changed - added, removed, or renamed files - changed functions, classes, routes, queries, configs, or tests - recurring patterns across files Prefer the semantic change over line-by-line narration. ### 2. Infer the real change Summarize the implementation intent in plain engineering language: - bug fix - refactor - feature addition - cleanup - configuration change - test-only update - dependency or build change Do not overclaim intent when the diff is ambiguous. Use wording like likely, appears to, or seems to when needed. ### 3. Produce a brief developer summary Default output should be short and scan-friendly. Use this structure unless the user asks for another format: markdown Summary: 1-3 sentences Changed areas: - area 1 - area 2 - area 3 ## Output rules - Write for developers, not for end users. - Keep the whole summary brief. - Mention concrete modules, files, or components when visible in the diff. - Group related edits together instead of listing every file separately. - Mention tests only if the diff clearly changes or adds tests. - Avoid filler such as This PR basically... or Overall.... - Do not invent motivation, risk, or product impact unless directly supported by the diff. ## Heuristics ### Prefer summaries like these Good: - Adds validation for empty email input in the signup flow and updates the API handler to return a 400 response instead of silently accepting invalid data. - Refactors cache invalidation into a shared helper and updates the user/profile paths to call the new helper. - Updates test fixtures and snapshot expectations for the new serializer output. Bad: - Changes many files across the codebase. - Improves the system. - Adds some fixes and refactors. ## Special cases ### Large diffs For large patches: - collapse low-signal edits - emphasize the main theme of the change - mention only the most important 2-5 changed areas ### Mixed diffs If a diff mixes unrelated work, call that out briefly and summarize each cluster separately. ### Pure formatting changes Say so directly, for example: - Mostly formatting and lint-driven cleanup; no clear behavioral change is visible in the diff. ## Example ### Input pattern A user provides raw git diff or patch text. ### Expected style markdown Summary: Refactors authentication token parsing into a shared utility and updates the login and refresh handlers to use it. Also adds tests covering expired-token behavior. Changed areas: - auth utility extraction - login and refresh handlers - expired-token test coverage 整体结构SKILL.md | |-- Frontmatter | |-- name | -- description | |-- Title | -- PR Change Summary | |-- Overview | -- 说明任务目标 | |-- Workflow | |-- 1. 结构化读 diff | |-- 2. 推断真实改动类型 | -- 3. 输出简短摘要 | |-- Output rules | -- 约束输出内容和边界 | |-- Heuristics | -- 给出好坏摘要示例 | |-- Special cases | |-- large diffs | |-- mixed diffs | -- formatting-only diffs | -- Example -- 给出目标输出样式使用在chatgptweb端安装skill上传skill压缩包进行skill测试由于 web 端 gpt 不能使用 git 命令所以这里失败了可以尝试用 codex-cli测试该skill
什么是Skill
Skill什么是skillskill就是为AI安装的可重复工作流包把一件经常做并且有固定规则的事情整理成一套模板必要时附上脚本和资源。即Skill 说明书(SKill.md) 元数据(openai.yaml) 可选的脚本/参考资料/资源文件结构skill-name/ | |-- SKILL.md # 必需入口说明告诉 ChatGPT 这个 skill 是做什么的、什么时候触发、怎么做 | |-- agents/ | -- openai.yaml # 必需UI/元数据比如显示名称、简介、图标等 | |-- scripts/ # 可选放可执行脚本适合稳定、可重复的步骤 | |-- analyze.py | -- helper.sh | |-- references/ # 可选放参考资料、规则、模板说明 | |-- schema.md | -- style-guide.md | -- assets/ # 可选放输出会用到的资源文件 |-- template.docx -- logo.png简单实现实现一个git PR变更摘要your-skill/ ├── agents/ │ └── openai.yaml └── SKILL.mdinterface:这一段是在定义这个 skill 的“界面展示信息”。display_name: PR Change Summary这是这个 skill 在界面上显示出来的名字。用户看到的通常就是这个名字而不是目录名。interface:display_name:PR Change Summaryshort_description:Summarize git diffs into short developer-facing updates用---上下包裹着的是元信息name:skill的名字description:触发描述## Overview说明 skill 的总目标## Workflow定义执行步骤### Read the diff structurally结构化阅读变化### Infer the real change推断改动类型### Produce a brief developer summary生成短的摘要## Output rules定义输出边界## Heuristics给出好坏范式--- name: pr-change-summary description: summarize git diff or patch content into a short developer-facing change summary. use when chatgpt or codex is given a git diff, patch, unified diff, or code change snippet and needs to quickly explain what changed, highlight impacted areas, and produce a concise summary for engineers. --- # PR Change Summary ## Overview Turn raw git diff or patch text into a short summary for developers. Focus on what changed, where it changed, and why it likely matters. ## Workflow ### 1. Read the diff structurally Identify: - files changed - added, removed, or renamed files - changed functions, classes, routes, queries, configs, or tests - recurring patterns across files Prefer the semantic change over line-by-line narration. ### 2. Infer the real change Summarize the implementation intent in plain engineering language: - bug fix - refactor - feature addition - cleanup - configuration change - test-only update - dependency or build change Do not overclaim intent when the diff is ambiguous. Use wording like likely, appears to, or seems to when needed. ### 3. Produce a brief developer summary Default output should be short and scan-friendly. Use this structure unless the user asks for another format: markdown Summary: 1-3 sentences Changed areas: - area 1 - area 2 - area 3 ## Output rules - Write for developers, not for end users. - Keep the whole summary brief. - Mention concrete modules, files, or components when visible in the diff. - Group related edits together instead of listing every file separately. - Mention tests only if the diff clearly changes or adds tests. - Avoid filler such as This PR basically... or Overall.... - Do not invent motivation, risk, or product impact unless directly supported by the diff. ## Heuristics ### Prefer summaries like these Good: - Adds validation for empty email input in the signup flow and updates the API handler to return a 400 response instead of silently accepting invalid data. - Refactors cache invalidation into a shared helper and updates the user/profile paths to call the new helper. - Updates test fixtures and snapshot expectations for the new serializer output. Bad: - Changes many files across the codebase. - Improves the system. - Adds some fixes and refactors. ## Special cases ### Large diffs For large patches: - collapse low-signal edits - emphasize the main theme of the change - mention only the most important 2-5 changed areas ### Mixed diffs If a diff mixes unrelated work, call that out briefly and summarize each cluster separately. ### Pure formatting changes Say so directly, for example: - Mostly formatting and lint-driven cleanup; no clear behavioral change is visible in the diff. ## Example ### Input pattern A user provides raw git diff or patch text. ### Expected style markdown Summary: Refactors authentication token parsing into a shared utility and updates the login and refresh handlers to use it. Also adds tests covering expired-token behavior. Changed areas: - auth utility extraction - login and refresh handlers - expired-token test coverage 整体结构SKILL.md | |-- Frontmatter | |-- name | -- description | |-- Title | -- PR Change Summary | |-- Overview | -- 说明任务目标 | |-- Workflow | |-- 1. 结构化读 diff | |-- 2. 推断真实改动类型 | -- 3. 输出简短摘要 | |-- Output rules | -- 约束输出内容和边界 | |-- Heuristics | -- 给出好坏摘要示例 | |-- Special cases | |-- large diffs | |-- mixed diffs | -- formatting-only diffs | -- Example -- 给出目标输出样式使用在chatgptweb端安装skill上传skill压缩包进行skill测试由于 web 端 gpt 不能使用 git 命令所以这里失败了可以尝试用 codex-cli测试该skill
