菜单
从普通用户视角审视代码仓库中的用户可见文案和内容（不是运行中网站测试）：页面文案、 按钮、空状态、错误提示、邮件模板、i18n、meta/SEO、CTA 和下载/升级/帮助入口。 当用户要求改文案、清理产品内容、把开发者语言改成人话、检查页面是否跟最近功能同步、 找缺失入口、做 SEO/meta 检查，或定期跑产品内容审查时触发。优先用于 AI 快速迭代、 文案常常落后于代码的小型产品和 side project。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
周期性代码库维护和质量治理：清理文档、补充测试、拆分大文件、提取共享代码、 合并重复逻辑、替换手写工具、处理 TODO/FIXME、清理已完成 GitHub issue， 以及修剪已合并的本地或远程分支。当用户要求 maintain、clean up、refactor、tidy up、 improve code quality、cleanup tech debt，或提到 "too many docs"、"file is too big"、 "DRY up"、"TODO comments piling up"、"address FIXMEs" 时触发。
处理 PR review 和 code review 评论：获取或解析 review 内容、分类优先级、 判断哪些意见需要修复、哪些应跳过，并协助逐条修改代码或组织回复。当用户提供 PR URL、 粘贴 reviewer 意见，或提到 "review message"、"review 意见"、"PR 评论"、 "处理 review"、"review 反馈"、"帮我处理这些 review 意见"时触发。
生成项目报价单、工时评估和 proposal：拆解需求、按 AI 辅助开发效率估算工作量、 维护技能清单、分析竞品或参考站点，并形成 Markdown 报价文档。当用户提到 "报价"、 "估价"、"工时评估"、"项目评估"、"开发报价"、"给客户报价"、"quote"、"estimate"、 "project proposal"、"development cost"、"更新技能清单"、"参考这个网站报价"、 "仿这个网站"、"分析竞品功能" 时触发。
对公开网站和配套 CMS 做运营/客户视角的真实浏览器人工测试（manual website QA, operator/client acceptance，不是自动化 e2e）。当用户要求列测试用例、逐项执行业务流程、 检查前台和 CMS、记录问题、清理测试数据，或整理 WIP、报告、GitHub issue 时触发。
把直播录像或长视频回放处理成可发布的视频包：转写原始音频、基于 transcription 规划剪辑、剪掉冗余和长停顿、生成 SRT 字幕、章节、章节封面、最终视频和发布文案。 当用户提供 .mp4/.mov/.mkv 直播录像、OBS 录屏、webinar 或课程回放，并要求剪辑、 转写、出字幕、出章节、做封面/章节卡、准备 B 站或 YouTube 发布素材时触发。
| name | product-content-audit |
| description | 从普通用户视角审视代码仓库中的用户可见文案和内容（不是运行中网站测试）：页面文案、 按钮、空状态、错误提示、邮件模板、i18n、meta/SEO、CTA 和下载/升级/帮助入口。 当用户要求改文案、清理产品内容、把开发者语言改成人话、检查页面是否跟最近功能同步、 找缺失入口、做 SEO/meta 检查，或定期跑产品内容审查时触发。优先用于 AI 快速迭代、 文案常常落后于代码的小型产品和 side project。 |
代码迭代得越快，页面上的文字就越容易过时；开发者写的初版文案，对真实用户来说也常常太硬。这个 skill 的目的是定期帮一个资深开发者、但产品/运营经验有限的用户，从普通用户视角检查仓库里的所有面向用户文案，并按用户确认后再动手修改。
如果用户希望的是手动测试一个跑起来的网站，请改用 website-operator-qa。如果是代码层面的清理重构，请改用 code-maintenance。本 skill 关注的是仓库里那些会被用户看见的字符串：页面文案、按钮、空状态、错误提示、邮件模板、meta 标签、i18n 文件等。
下面是默认的两阶段流程。第一阶段产出报告并等待用户确认，第二阶段根据被批准的条目动手修改。除非用户明确说"跳过报告、直接改"，否则永远先做第一阶段。
不管接下来跑哪一阶段，都先读这些再开工，跳过会导致改错或者重复别人已经定过的事：
README.md — 产品定位、目标用户、当前阶段（alpha / beta / 上线了多久），决定我们要不要"贴近小白"还是"贴近开发者"。DEV_NOTE.md / ARCHITECTURE.md 等架构说明 —— 团队对产品语言的既有约定（专有名词、品牌词、要不要保留某些技术词）。package.json — 框架（Next.js / Nuxt / Vite / Astro 等）以及是否使用 i18n 库（next-intl, vue-i18n, react-i18next, paraglide, nuxt-i18n 等），用来定位文案文件。BRAND.md / VOICE.md / STYLEGUIDE.md —— 一定要读，覆盖默认语气。locales/、messages/、i18n/、lang/ 等目录 —— 即便没有显式声明也能找出来。定位用户可见文案，常见但不限于的位置（按命中概率从高到低）：
locales/*.json、messages/*.json、i18n/**/*.{json,ts,yaml}app/**、pages/**、src/views/**、src/routes/**、src/pages/**components/**、src/components/**（特别是 Hero、Pricing、Footer、EmptyState、ErrorState 这类）app/layout.*、pages/_document.*、<head> 配置文件、sitemap、robots、og-image 模板、manifest.jsonemails/**、templates/**、mail/**public/、docs/、marketing/、landing/如果同一字符串既出现在 i18n 文件里，也出现在组件里，以 i18n 文件为准，先改 i18n 资源；只有当组件里的硬编码文本绕过 i18n 时，才改组件。
目标：扫一遍仓库，输出一份审查报告，不修改任何源文件。
理解最近的代码变化
git log --no-merges -n 30 --pretty=format:"%h %s"，再 git log -p / git show 看具体改动。建立全部用户可见文案的清单
dispatch|hydrat|render|endpoint|token|instance|namespace|webhook|payload|stdout|throttle|polling|OAuth|JWT|CORS|SSR|CSR|cron|cli|backend|frontend|API\s*keyTODO|FIXME|TBD|Lorem|placeholder|coming soon（这些词被遗忘出现在生产文案里是常见事故）逐项检查（参考清单） 完整清单见 references/checklist.md。最低限度要覆盖：
title / description / og:* 是否齐备且面向用户而不是开发者把技术黑话改写指南映射到本项目
写出审查报告
WIP/product-content-audit-YYYY-MM-DD.md（如果项目没有 WIP/ 目录就放到仓库根目录，并提醒用户加到 .gitignore）。J1、L2），方便用户在第二阶段说"批准 J1、J3、L2，跳过 J2"。报告完成后停下，把路径告诉用户，等他确认。 不要主动进入 Phase 2。
只有用户明确说"开始改"或者"按报告改 X、Y、Z"之后，才进入这一阶段。
读取上一阶段的报告
WIP/ 目录下最新的 product-content-audit-*.md。逐条修改，每条独立成可识别的最小改动
<p> 改成 <div>）遇到下面这些情况，停下来问用户
结束时给一份变更摘要
website-operator-qa，从用户角度复核改动效果。下面是判断"该不该改"的原则速查。详细清单见 references/checklist.md。
Untitled / 文件名 / 框架默认值；description 是 lorem 或开发笔记；缺 og:image / og:title；同一 locale 缺整段 meta。报告里每条问题都标一个严重度，方便用户取舍。
严重度永远用业务语言解释，不要只给技术分类。
WIP/ 或被 .gitignore 的目录。跑完审查后如果发现下列情况，建议用户切换或并行使用其他 skill：
website-operator-qa 做一次浏览器侧的复核。code-maintenance 做代码侧清理。