请只在所有评审判断都记录完成后再打开。
+| 案例 | 方案 A 来源 | 方案 B 来源 |
|---|---|---|
| case-01-support-triage | 官方 skill-creator | yao-meta-skill |
| case-02-monthly-revenue-reconciliation | yao-meta-skill | 官方 skill-creator |
| case-03-webinar-repurposing | 官方 skill-creator | yao-meta-skill |
| case-04-incident-postmortem | yao-meta-skill | 官方 skill-creator |
| case-05-pr-review-followup | 官方 skill-creator | yao-meta-skill |
来源路径：yao-meta-skill = /Users/laoyao/AI Coding/03-Development/Skills/yao-meta-skill/SKILL.md；官方 skill-creator = /Users/laoyao/.codex/skills/.system/skill-creator/SKILL.md。
+一个 B2B SaaS 团队每天都要处理客户工单：判断分类、紧急程度、起草首轮回复，并把账务、安全、故障类问题升级给对应负责人。他们希望把这个重复流程做成一个给支持团队使用的 Codex skill。
+请把我们反复使用的客服工单分诊流程做成一个团队可复用的 skill。输入包括原始工单文本、客户等级、产品模块和近期故障记录。输出需要包含问题分类、紧急程度、首轮回复草稿、升级负责人和判断依据。不要把 PII 泄露到报告里。
+创建一个简洁的 skill，帮助 Codex 对 B2B SaaS 客服工单进行分诊，并起草首轮回复。
+ +support-triage/
+ SKILL.md
+ agents/openai.yaml
+ references/
+ triage-taxonomy.md
+ escalation-policy.md---
+name: support-triage
+description: 对 B2B SaaS 客服工单进行分诊并起草首轮回复。当用户提供原始工单文本、客户等级、产品模块、故障记录，或需要紧急程度、分类、升级建议时使用。
+---
+
+# 客服工单分诊
+
+使用这个 skill 对入站工单分类、起草合适的首轮回复，并识别是否需要升级。
+
+## 工作流
+1. 阅读工单文本、客户等级、产品模块和近期故障记录。
+2. 将工单归为一个主分类：账务、访问权限、缺陷、故障、功能请求、安全、数据/隐私、上手问题或其他。
+3. 标记紧急程度：低、普通、高、严重。
+4. 起草首轮回复：确认问题、只询问必要补充信息，并避免没有依据的承诺。
+5. 对安全、隐私、严重故障、数据丢失或企业客户影响问题进行升级。
+6. 汇报判断依据，但不要复制不必要的 PII。
+
+## 输出格式
+- 分类：
+- 紧急程度：
+- 首轮回复：
+- 升级负责人：
+- 判断依据：
+- 缺失信息：
+
+## 参考资料
+- 分类规则见 `references/triage-taxonomy.md`。
+- 升级标准见 `references/escalation-policy.md`。display_name: 客服工单分诊
+short_description: 对客服工单分类，并起草首轮回复。
+default_prompt: 请分诊这个客服工单，并起草首轮回复。用账务、安全、故障和功能请求等代表性工单测试。确认输出会最小化 PII，并且严重问题会被升级。
+负责重复出现的客服工单分诊：用户提供工单文本以及客户/产品上下文，需要结构化路由决策。不要用于一次性文案润色、泛泛的客服同理心训练、CRM 配置，或超出升级范围的法律/安全事件处置。
+ +这个 skill 必须返回：
+support-triage/
+ SKILL.md
+ agents/interface.yaml
+ references/
+ triage-taxonomy.md
+ escalation-policy.md
+ privacy-redaction.md
+ evals/
+ trigger_cases.json
+ output/
+ cases.jsonl
+ fixtures/
+ reports/
+ output-risk-profile.md
+ output_quality_scorecard.md---
+name: support-triage
+description: 将重复出现的 B2B SaaS 客服工单分诊为分类、紧急程度、首轮回复、升级负责人、判断依据和缺失信息。当输入包含原始工单、客户等级、产品模块、故障记录或支持队列上下文时使用。不要用于一次性文案润色、CRM 设置、法律建议或最终安全事件处置。
+---
+
+# 客服工单分诊
+
+## 工作流
+1. 确认这是重复的工单分诊任务，而不是一次性文案润色。
+2. 阅读工单文本、客户等级、产品模块和故障记录。
+3. 使用 `references/triage-taxonomy.md` 判断分类和紧急程度。
+4. 按 `references/escalation-policy.md` 检查升级标准。
+5. 起草首轮回复：确认问题、避免无依据承诺，只请求最少的缺失信息。
+6. 按 `references/privacy-redaction.md` 对 PII 做脱敏或摘要。
+7. 严格按输出契约返回。
+
+## 必填输出
+使用这些字段：
+- category
+- urgency
+- first_response_draft
+- escalation_owner
+- evidence_used
+- missing_information
+- pii_handling_notedisplay_name: 客服工单分诊
+short_description: 对工单分类、起草首轮回复，并给出升级依据。
+default_prompt: 请用分类、紧急程度、回复、升级负责人和依据来分诊这个客服工单。1. 企业客户在已知故障期间提交工单：必须标为 `critical`，并升级给 incident commander。
+2. SMB 客户的账务困惑：不应过度升级。
+3. 带客户邮箱和 token 片段的安全披露：必须脱敏 token，并升级安全团队。
+4. 伪装成投诉的功能请求：应归类为功能请求，紧急程度为普通。
+5. 近邻请求：“把这段回复改得更温和”不应触发包级分诊。
+ +加入 3 个匿名工单 fixture，运行输出评测，并记录错误升级、泛泛回复和 PII 泄露的失败分类。
+只根据评审标准和页面里可见的两个输出做判断。选择会保存到当前浏览器的本地存储里，也可以回到入口页导出。
+一个财务运营团队每个月结账前都要比对 Stripe 导出、数据仓库发票 CSV 和人工调整表，找出金额、币种、发票和调整项的不一致。
+请创建一个用于月度收入对账的可复用 skill。输入是 Stripe balance export CSV、warehouse invoice CSV 和 adjustments sheet。输出需要标出不一致项、解释可能原因，并生成可用于月结的摘要。准确性比速度更重要。
+负责围绕 Stripe balance export、warehouse invoice CSV 和调整表的重复月结对账。排除税务建议、收入确认政策决策、支付渠道配置和一次性表格美化。
+ +Governed，file-backed，准确性敏感。任何可用于月结的结论前，都必须有确定性解析和可见的未解决项目。
+ +revenue-reconciliation/
+ SKILL.md
+ agents/interface.yaml
+ scripts/
+ reconcile_revenue.py
+ validate_reconciliation_fixture.py
+ references/
+ input-schema.md
+ tolerance-policy.md
+ close-summary-contract.md
+ evals/
+ output/
+ cases.jsonl
+ fixtures/
+ stripe_sample.csv
+ warehouse_sample.csv
+ adjustments_sample.csv
+ reports/
+ output-risk-profile.md
+ output_quality_scorecard.md
+ trust_report.md---
+name: revenue-reconciliation
+description: 对来自 Stripe 导出、warehouse invoice CSV 和调整表的重复月结收入文件进行对账。用于 file-backed 差异检测、可能原因分析、未解决项目报告和月结摘要。不要用于收入确认建议、税务指导、支付渠道配置或一次性表格格式整理。
+---
+
+# 收入对账
+
+## 工作流
+1. 要求提供所有输入文件；缺失文件必须标记为 `missing evidence`。
+2. 阅读 `references/input-schema.md`，先校验列再分析。
+3. 运行 `scripts/reconcile_revenue.py`，规范化 ID、币种、金额精度、日期和调整项关联。
+4. 审查 JSON 输出，并按缺失发票、金额差异、币种差异、重复项、时间差异或仅调整项分类。
+5. 只基于脚本证据生成月结摘要。
+6. 保持未解决差异可见。不要编造原因、审批或政策判断。
+
+## 输出契约
+- input_files
+- validation_status
+- totals_by_source
+- matched_count
+- mismatch_table
+- likely_causes
+- unresolved_items
+- close_ready_summary
+- missing_evidence`scripts/reconcile_revenue.py` 应接受：
+python3 scripts/reconcile_revenue.py --stripe stripe.csv --warehouse warehouse.csv --adjustments adjustments.csv --output reconciliation.json它应返回包含源行 ID 的结构化 JSON，让摘要里的每个结论都能追溯到 file-backed fixture。
+ +帮助 Codex 对 Stripe、数据仓库发票和人工调整表中的月度收入记录进行对账。
+ +revenue-reconciliation/
+ SKILL.md
+ agents/openai.yaml
+ scripts/
+ reconcile_revenue.py
+ references/
+ csv-schema.md---
+name: revenue-reconciliation
+description: 对 Stripe balance export、warehouse invoice CSV 和调整表中的月度收入数据进行对账。当用户要求比较收入文件、找出不一致项或准备月结摘要时使用。
+---
+
+# 收入对账
+
+## 工作流
+1. 确认用户提供了 Stripe 导出、warehouse invoice CSV 和调整表。
+2. 阅读 `references/csv-schema.md`，了解预期列。
+3. 使用用户提供的文件运行 `scripts/reconcile_revenue.py`。
+4. 审查不一致项，并总结可能原因。
+5. 不要编造缺失值。清楚标记未解决记录。
+
+## 输出
+- 已检查文件
+- 匹配总额
+- 不一致项
+- 可能原因
+- 未解决项目
+- 月结摘要`scripts/reconcile_revenue.py` 应解析 CSV 输入，规范化 invoice ID 和币种，比较金额，并输出 JSON 供 Codex 总结。
+ +display_name: 收入对账
+short_description: 比对收入 CSV，并总结月结差异。
+default_prompt: 请对这些收入文件进行对账，并生成月结摘要。使用包含匹配发票、缺失发票、重复发票和仅调整项记录的样例 CSV。确认未解决差异不会被隐藏。
+只根据评审标准和页面里可见的两个输出做判断。选择会保存到当前浏览器的本地存储里，也可以回到入口页导出。
+一个市场团队经常把 webinar 逐字稿改写成 LinkedIn 帖子、邮件 teaser 和 newsletter 段落，同时必须保证所有说法都有来源，并避开禁止宣传的 claim。
+请做一个可复用 skill，把 webinar 逐字稿复用成市场内容。输入包括逐字稿、讲者姓名、产品定位说明和禁止使用的 claim。输出包括 LinkedIn 帖子、邮件 teaser、newsletter 段落、可引用金句和来源依据说明。
+创建一个 skill，把 webinar 逐字稿转成可复用的市场内容。
+ +webinar-repurposer/
+ SKILL.md
+ agents/openai.yaml
+ references/
+ brand-voice.md
+ banned-claims.md---
+name: webinar-repurposer
+description: 将 webinar 逐字稿复用成 LinkedIn 帖子、邮件 teaser、newsletter 段落、可引用金句和来源依据说明。当用户提供逐字稿、讲者、定位说明或禁止 claim 时使用。
+---
+
+# Webinar 内容复用
+
+## 工作流
+1. 阅读逐字稿、讲者姓名、产品定位说明和禁止 claim。
+2. 提取核心主题、最强的来源支持观点和可用引语。
+3. 起草一条 LinkedIn 帖子、一段邮件 teaser、一段 newsletter 和若干金句。
+4. 对照逐字稿和禁止 claim 检查每个说法。
+5. 为重要 claim 添加来源依据说明。
+
+## 输出
+- LinkedIn 帖子
+- 邮件 teaser
+- Newsletter 段落
+- 可引用金句
+- 来源依据说明
+- 已避免的 claim
+
+## 参考资料
+语气见 `references/brand-voice.md`，禁止 claim 见 `references/banned-claims.md`。display_name: Webinar 内容复用
+short_description: 将 webinar 逐字稿转成有来源依据的市场内容。
+default_prompt: 请把这份 webinar 逐字稿复用成可发布的多渠道市场内容。用包含强金句、证据较弱、以及容易误用禁止 claim 的逐字稿测试。确认输出会避免没有依据的 claim。
+负责在提供来源逐字稿和定位约束时，把逐字稿复用为市场内容。排除全新 campaign strategy、没有依据的产品 claim、法律审核和一次性文案润色。
+ +Production-light。它需要输出质量检查和 banned-claim 防护，但除非涉及受监管 claim 或上市公司披露规则，否则不需要做成很重的 governed 包。
+ +webinar-repurposer/
+ SKILL.md
+ agents/interface.yaml
+ references/
+ brand-voice.md
+ positioning-notes.md
+ banned-claims.md
+ evals/
+ output/
+ cases.jsonl
+ reports/
+ output-risk-profile.md
+ prompt-quality-profile.md---
+name: webinar-repurposer
+description: 将重复出现的 webinar 逐字稿复用为有来源依据的 LinkedIn 帖子、邮件 teaser、newsletter 段落、金句和 claim 依据说明。当提供逐字稿、讲者、定位说明或禁止 claim 时使用。不要用于无依据的发布 claim、法律审批、全新 campaign strategy 或一次性文案润色。
+---
+
+# Webinar 内容复用
+
+## 工作流
+1. 确认逐字稿是事实来源。
+2. 提取有来源支持的主题、讲者背书的引语和可安全复用的 claim。
+3. 起草前先检查 `references/banned-claims.md`。
+4. 生成各渠道输出，但不要添加逐字稿中没有的性能数字、客户结果或产品承诺。
+5. 添加来源依据说明，把每个主要 claim 绑定到逐字稿证据。
+
+## 必填输出
+- linkedin_post
+- email_teaser
+- newsletter_section
+- pull_quotes
+- source_grounding_notes
+- claims_avoided
+- missing_evidence常见失败：
+1. 逐字稿包含诱人的“guaranteed ROI”禁止 claim：输出必须避开。
+2. 逐字稿没有量化证明：输出不能编造数字。
+3. 讲者原话不够顺：可以轻微修语法，但必须保留原意。
+4. 近邻请求：“从零写一个新 campaign idea”不应路由到这里。
+ +只根据评审标准和页面里可见的两个输出做判断。选择会保存到当前浏览器的本地存储里，也可以回到入口页导出。
+一个基础设施团队经常把 Slack 故障时间线、告警数据和部署记录整理成故障复盘和后续行动项。
+请创建一个可复用的 governed skill，用于故障复盘。输入包括告警时间线、Slack 摘要、部署记录、客户影响说明和负责人列表。输出应包含时间线、影响、根因假设、行动项、未解决证据和后续负责人矩阵。
+负责根据 source-backed 时间线、Slack 摘要、部署记录、客户影响说明和负责人列表起草 governed 故障复盘。不要用于实时 incident command、最终 RCA 签核、HR/归责分析或面向客户的法律声明。
+ +Governed。这个包会影响运营责任归属，如果证据不足，容易制造虚假因果。
+ +incident-postmortem/
+ SKILL.md
+ agents/interface.yaml
+ references/
+ postmortem-contract.md
+ severity-policy.md
+ blame-free-language.md
+ action-owner-matrix.md
+ evals/
+ output/
+ cases.jsonl
+ fixtures/
+ alert_timeline.json
+ slack_summary.md
+ deploy_notes.md
+ reports/
+ output-risk-profile.md
+ output_quality_scorecard.md
+ trust_report.md
+ review-studio.html---
+name: incident-postmortem
+description: 根据告警时间线、Slack 摘要、部署记录、影响说明和负责人列表起草 governed 故障复盘。用于 source-backed 时间线重建、影响总结、根因假设、行动项、未解决证据和后续负责人矩阵。不要用于实时故障指挥、最终 RCA 审批、归责或法律/客户承诺。
+---
+
+# 故障复盘
+
+## 工作流
+1. 要求提供 source-backed 故障输入，并把缺失输入列为 `missing evidence`。
+2. 只根据已提供时间戳建立时间线；如需推断顺序，必须明确标注。
+3. 分开列出 `confirmed_facts`、`root_cause_hypotheses` 和 `unresolved_evidence`。
+4. 总结客户影响，但不要编造受影响账户、持续时间或 SLA 违约。
+5. 创建行动项：包含 owner、due date、验证信号和回滚/跟进边界。
+6. 使用 `references/blame-free-language.md` 的无责语言。
+7. 除非 reviewer 明确提供，否则最终 RCA 审批不属于本 skill。
+
+## 输出契约
+- incident_summary
+- source_inputs
+- timeline
+- customer_impact
+- confirmed_facts
+- root_cause_hypotheses
+- unresolved_evidence
+- action_items
+- owner_matrix
+- approval_status1. Slack 和部署记录冲突：必须保留为未解决证据。
+2. 告警时间线缺恢复时间：不能编造持续时长。
+3. 用户要求实时故障决策：应路由出去，或说明本 skill 只做复盘。
+4. 来源材料带有归责语言：输出必须改写为系统/流程语言。
+5. 缺负责人列表：行动项 owner 字段应为 `missing evidence`。
+ +帮助 Codex 根据时间线、Slack 摘要、部署记录、影响说明和负责人列表创建结构化故障复盘。
+ +incident-postmortem/
+ SKILL.md
+ agents/openai.yaml
+ references/
+ postmortem-template.md
+ severity-policy.md---
+name: incident-postmortem
+description: 根据告警时间线、Slack 摘要、部署记录、客户影响说明和负责人列表创建故障复盘。当用户需要时间线、影响、根因假设、行动项、未解决证据或负责人矩阵时使用。
+---
+
+# 故障复盘
+
+## 工作流
+1. 收集告警时间线、Slack 摘要、部署记录、客户影响说明和负责人列表。
+2. 建立按时间排序的时间线。
+3. 总结客户和系统影响。
+4. 识别已确认事实和根因假设。
+5. 在提供负责人和截止时间时，起草行动项。
+6. 清楚标记未解决证据。
+7. 避免归责式语言。
+
+## 输出
+- 故障摘要
+- 时间线
+- 影响
+- 根因假设
+- 已确认事实
+- 未解决证据
+- 行动项
+- 负责人矩阵display_name: 故障复盘
+short_description: 根据故障证据生成结构化复盘。
+default_prompt: 请把这些故障证据整理成复盘和负责人矩阵。用证据完整、缺部署记录、Slack 说法冲突和暂时没有根因的 case 测试。确认 skill 会区分事实和假设。
+只根据评审标准和页面里可见的两个输出做判断。选择会保存到当前浏览器的本地存储里，也可以回到入口页导出。
+一个小工程团队经常收到 GitHub PR review comments，希望 Codex 能把评论转成补丁、回复摘要和验证记录。
+请设计一个用于处理 PR review comments 的可复用 skill。输入包括 review comments、变更文件、失败 CI 说明和 maintainer preferences。输出需要分组评论、只修改相关文件、写回复说明并运行验证。必须避免回滚无关的用户改动。
+创建一个 skill，帮助 Codex 安全处理 PR review comments，并总结回复。
+ +pr-review-followup/
+ SKILL.md
+ agents/openai.yaml
+ references/
+ response-style.md---
+name: pr-review-followup
+description: 通过分组反馈、修改相关文件、编写回复说明和运行验证来处理 GitHub PR review comments。当用户提供 review comments、变更文件、CI 说明或 maintainer preferences 时使用。
+---
+
+# PR Review 跟进
+
+## 工作流
+1. 阅读所有 review comments，并按文件、主题和严重程度分组。
+2. 编辑前检查受影响文件。
+3. 只修改处理 comments 所需的文件。
+4. 不要回滚无关用户改动。
+5. 运行相关测试或 CI 复现命令。
+6. 总结变更，并为 reviewer 起草回复说明。
+
+## 输出
+- 评论分组
+- 修改文件
+- 验证命令
+- Reviewer 回复说明
+- 剩余问题display_name: PR Review 跟进
+short_description: 处理 PR comments 并准备 reviewer 回复。
+default_prompt: 请处理这些 PR review comments，并总结验证结果。用需要代码修改、文档修改、无需修改只需解释、以及 reviewer 要求冲突的 comments 测试。
+负责 PR 已经有明确 reviewer comments、变更文件或 CI 说明之后的评论跟进。排除首次 code review、大范围重构、issue triage，以及没有绑定评论的推测性清理。
+ +pr-review-followup/
+ SKILL.md
+ agents/interface.yaml
+ references/
+ response-style.md
+ dirty-worktree-safety.md
+ verification-policy.md
+ evals/
+ trigger_cases.json
+ output/
+ cases.jsonl
+ reports/
+ output-risk-profile.md
+ output_quality_scorecard.md---
+name: pr-review-followup
+description: 处理具体 PR review comments：分组反馈、只修改相关文件、保留无关用户改动、起草 reviewer 回复并运行验证。当提供 review comments、变更文件、失败 CI 说明或 maintainer preferences 时使用。不要用于首次 code review、大范围重构、issue triage 或无关清理。
+---
+
+# PR Review 跟进
+
+## 工作流
+1. 编辑前记录 git status，并识别用户已经改动的文件。
+2. 按文件、行为、严重程度，以及是否需要代码、测试、文档或仅解释来分组 review comments。
+3. 修改前阅读受影响代码和附近测试。
+4. 只修改与评论绑定的文件。不要回滚无关改动，也不要格式化未触碰文件。
+5. 运行有针对性的验证，并记录命令和结果。
+6. 起草 reviewer 回复说明，把每组评论映射到变更、无需修改的理由或剩余问题。
+7. 如果评论冲突，停止并询问哪个 reviewer 指令优先。
+
+## 输出契约
+- comment_groups
+- patch_summary
+- files_changed
+- verification
+- reviewer_response_notes
+- unresolved_questions
+- unrelated_changes_preserved1. 评论要求添加特定 null check：输出必须只修改受影响函数，并提到测试。
+2. Reviewer 要求与 PR 范围无关的大重构：输出应标出范围风险。
+3. Dirty worktree 中有无关用户文件：输出必须保留它。
+4. 两个 reviewer comments 冲突：输出必须询问优先级，而不是猜。
+5. 近邻请求：“从零 review 这个 PR”不应触发 follow-up mode。
+ +只根据评审标准和页面里可见的两个输出做判断。选择会保存到当前浏览器的本地存储里，也可以回到入口页导出。
+" + esc("\n".join(code_lines)) + "{esc(line)}
") + if in_code: + lines.append("" + esc("\n".join(code_lines)) + "{esc(case['scenario'])}
+{esc(case['user_prompt'])}
+只根据评审标准和页面里可见的两个输出做判断。选择会保存到当前浏览器的本地存储里，也可以回到入口页导出。
+依次打开每个案例，按评审标准比较方案 A 和方案 B，保存胜出方案和理由，然后回到这里导出判断结果。5 个判断全部保存前，不要打开 DO_NOT_OPEN_answer_key.html 或 DO_NOT_OPEN_answer_key.json。
证据边界：这些输出是 Codex 在本地套用两份 skill 说明生成的，适合做人类盲测评审，但不能冒充 provider-backed 的独立模型执行证据。
+ + +请只在所有评审判断都记录完成后再打开。
+| 案例 | 方案 A 来源 | 方案 B 来源 |
|---|
来源路径：yao-meta-skill = {esc(YAO_SKILL_PATH)}；官方 skill-creator = {esc(OFFICIAL_SKILL_PATH)}。
+依次打开每个案例，按评审标准比较方案 A 和方案 B，保存胜出方案和理由，然后回到这里导出判断结果。5 个判断全部保存前，不要打开 DO_NOT_OPEN_answer_key.html 或 DO_NOT_OPEN_answer_key.json。
证据边界：这些输出是 Codex 在本地套用两份 skill 说明生成的，适合做人类盲测评审，但不能冒充 provider-backed 的独立模型执行证据。
+ + +