| name | chrome-store-submission |
| description | 分析 Chrome 扩展代码并生成 Chrome Web Store 提交所需的全部资料（商店描述、权限说明、隐私政策、数据披露等）。
当用户提到"提交资料"、"上架资料"、"Chrome 商店资料"、"提审文案"、"权限说明"、"隐私政策"、"Web Store listing"、"submission materials"、"准备上架"、"生成提审材料" 时使用此技能。
也适用于用户说"分析这个插件"并且上下文明显是为了 Chrome Web Store 上架的场景。
此技能默认在主目录/桌面根目录生成一个清晰的上架资料包：填文字看 fill-text.md，上传图片和 ZIP 看 upload-files/，并附带中英文归档、隐私页面和审核证据。
|
Chrome Web Store 提交资料生成器
分析 Chrome 扩展源码，一站式生成 Chrome Web Store 上架所需的全部资料（文字 + 图片）。
输出目录
所有产出物统一放在一个文件夹中，避免散落各处。目录名应包含扩展名称，格式为 <扩展名>-store-assets/（使用扩展名的英文或拼音简写，小写连字符），例如 yaoji-store-assets/、image-cropper-store-assets/。
位置规则：
- 默认基准目录是用户能直接找到的主目录，而不是扩展源码目录。macOS 桌面工作流默认使用
~/Desktop/<扩展名>-store-assets/。
- 如果当前仓库位于桌面下的子目录，例如
~/Desktop/js/xPoster/，输出仍然默认放到 ~/Desktop/<扩展名>-store-assets/，不要放到 ~/Desktop/js/xPoster/<扩展名>-store-assets/。
- 如果当前会话的工作目录就是某个主目录，例如
/Users/admin/Desktop，输出默认放在这个工作目录根部：/Users/admin/Desktop/<扩展名>-store-assets/。
- 如果当前会话明确不是桌面工作流，则默认放在当前 workspace 的主目录下：
<workspace>/<扩展名>-store-assets/。这里的 workspace 主目录指用户打开/管理任务的根目录，不是扩展源码内部目录。
- 如果用户明确指定输出路径，则放在用户指定的位置；用户只说“默认”“以后默认”“主目录”时，不视为指定源码目录。
- 不要默认放在扩展源码目录内，除非用户明确要求。上架资料通常需要单独提交、复制、归档，放在主目录更易找到，也避免误打包进扩展 ZIP。
路径解析算法：
- 先找扩展源码目录：包含
manifest.json 的目录。
- 再找输出基准目录：
- 用户给了明确路径：使用用户路径。
- 源码目录在
~/Desktop/ 下面：使用 ~/Desktop/。
- 当前工作目录是用户管理任务的根目录：使用当前工作目录。
- 否则使用源码目录的上一级“项目主目录”，但不能使用源码目录本身。
- 输出目录固定为
<输出基准目录>/<扩展名>-store-assets/。
- 生成 ZIP 时必须排除这个输出目录，即使输出目录碰巧在源码目录附近。
目录结构必须面向用户操作，而不是面向内部分类。顶层只放少量入口：
<扩展名>-store-assets/
├── README.md # 先看这个：一页说明从哪里复制文字、从哪里上传文件
├── fill-text.md # 最重要：按 Dashboard 顺序直接复制粘贴
├── upload-files/ # 所有需要上传/发布的文件都在这里
│ ├── store-icon-128.png
│ ├── promo-small-440x280.png
│ ├── promo-marquee-1400x560.png
│ ├── screenshots/
│ │ ├── 01-主界面.png
│ │ ├── 02-xxx.png
│ │ ├── 03-xxx.png
│ │ ├── 04-xxx.png
│ │ ├── 05-xxx.png
│ │ └── 00-contact-sheet.png
│ ├── privacy-page/
│ │ ├── index.html
│ │ └── README.md
│ └── <扩展名>-v<版本号>.zip
├── language-versions/ # 备份/切换语言用；不是日常入口
│ ├── fill-text.en.md
│ ├── fill-text.zh.md
│ ├── full-submission.en.md
│ ├── full-submission.zh.md
│ ├── privacy-policy.en.md
│ └── privacy-policy.zh.md
└── working/ # 生成脚本、临时页面、原始分析；不要上传
└── ...
用户入口规则：
- 填 Chrome Web Store Dashboard 的所有文字：只打开
<扩展名>-store-assets/fill-text.md。
- 上传商店图标、截图、宣传图、扩展 ZIP：只打开
<扩展名>-store-assets/upload-files/。
- 发布隐私政策网页：使用
<扩展名>-store-assets/upload-files/privacy-page/index.html。
- 需要另一种语言或完整分析：打开
<扩展名>-store-assets/language-versions/。
working/ 只给生成过程使用；最终回复不要让用户去这里找上传材料。
兼容要求：如果为了照顾旧流程，也可以在根目录额外放一份 chrome-store-submission.md、dashboard-paste-fields.md、privacy-policy.md 等快捷副本，但不能替代上面的 fill-text.md 和 upload-files/ 主入口。
旧版结构如下，只有在维护已有输出时才使用；新任务不要只产出这一种扁平结构，也不要在最终回复中把这些旧路径作为主要入口：
<扩展名>-store-assets/
├── chrome-store-submission.md # 提交资料文档（文字部分，兼容快捷副本）
├── store-icon-128.png # 128x128 商店图标
├── screenshots/ # 商店截图
│ ├── 01-主界面.png
│ ├── 02-xxx.png
│ ├── 03-xxx.png
│ ├── 04-xxx.png
│ ├── 05-xxx.png
│ └── 00-contact-sheet.png
├── promo-small-440x280.png # 小宣传图（如已生成）
├── promo-marquee-1400x560.png # 大宣传图（如已生成）
├── privacy-policy.md # 隐私政策草稿（方便用户发布到网页）
├── privacy-policy/
│ └── index.html # 隐私政策 HTML（用于 GitHub Pages）
└── <扩展名>-v<版本号>.zip # 可直接上传到 Chrome Web Store 的扩展包
在 README 和 fill-text 文件开头注明两个最重要路径：fill-text.md 负责填写文字，upload-files/ 负责上传图片和 ZIP。不要让用户在多个编号文件夹中猜。
硬性输出：清晰入口 + 中英文资料
每次必须默认生成以下资料：
fill-text.md：首选入口。按 Chrome Web Store Dashboard 页面顺序写“该填什么、复制哪段、上传哪个文件”。少解释，多可执行。用户打开后可以从上到下完成提交。这里放推荐提交语言的可粘贴版本，并明确说明如需另一种语言应打开 language-versions/fill-text.en.md 或 language-versions/fill-text.zh.md。upload-files/：上传入口。商店图标、截图、宣传图、扩展 ZIP、可发布的隐私政策网页都放这里。任何 Dashboard 需要选择文件的地方，都应能从这个文件夹找到。language-versions/：中英文归档。包含英文和中文的 Dashboard 粘贴稿、完整提交说明、隐私政策。这个目录用于切换语言和留档，不是用户的第一操作入口。
中英文资料必须内容一致、判断一致、隐私披露一致，只是语言不同。不要只在一份 Markdown 里混排中英文作为唯一输出；不要把详细分析放进 fill-text.md 干扰复制粘贴。
缺少 fill-text.md、upload-files/、language-versions/fill-text.en.md、language-versions/fill-text.zh.md 任意一项，或任一语言文件内容混成解释性双语文档，都视为输出失败，必须补齐。
硬性输出：Dashboard 直接填写区
Chrome Web Store Developer Dashboard 有很多独立输入框。用户最需要的不是抽象分析，而是可以直接复制粘贴的字段内容。
因此 fill-text.md 必须是第一优先级产物，并覆盖所有需要人工填写的字段。language-versions/fill-text.en.md 和 language-versions/fill-text.zh.md 分别保存纯英文、纯中文版本。这个章节/文件必须满足：
fill-text.md 按 Dashboard 顺序提供“立即复制粘贴”的推荐版本，不做长篇代码分析，不把用户需要复制的内容藏在解释段落里。language-versions/fill-text.en.md 每个字段只给英文可粘贴文本。language-versions/fill-text.zh.md 每个字段只给中文可粘贴文本。- README 和 fill-text 开头必须明确标注推荐粘贴哪一版。例如：
推荐填写英文版，因为扩展 UI 和商店文案是英文。中文版在 language-versions/fill-text.zh.md。
- 每个可粘贴文本都放在 fenced code block 中，代码块内部必须是纯文本，不要包含 Markdown 标记。
- 不要只写“见权限说明”。Dashboard 的每个输入框都要有一段完整可粘贴文字。
- 如果某个权限或字段来自 manifest，就按 manifest 中的真实名称逐项列出，不要合并到用户找不到对应位置的段落里。
- fill-text 中的文件路径必须指向新目录结构，例如
upload-files/screenshots/... 和 upload-files/<扩展名>-v<版本号>.zip。
必须覆盖的直接粘贴字段：
- Item name
- Summary
- Detailed description
- Single purpose
- Permission justification: 每个
permissions 权限一个字段，例如 storage、tabs、sidePanel
- Host permission justification: 每组
host_permissions 一个字段；宽泛权限必须单独解释
- Remote code declaration
- Data use disclosure: 每个被勾选的数据类型的说明文字，以及每个不勾选但容易误判的数据类型的“不收集”解释
- Limited Use certification explanation
- Privacy policy URL
- Support URL
- Test instructions / Review instructions
- Distribution notes, pricing / in-app purchases, mature content
直接填写区应放在详细代码分析之前。详细分析仍然保留，但不能替代直接填写区。最终交付时必须明确告诉用户：“填文字打开 fill-text.md；上传图片和 ZIP 打开 upload-files/；如果 Dashboard 要另一种语言，打开 language-versions/fill-text.en.md 或 language-versions/fill-text.zh.md。”
工作流程
第一步：分析扩展代码
从 manifest.json 开始，逐步深入理解扩展：
-
读取 manifest.json，提取：
name、version、descriptionmanifest_version（v2 还是 v3）permissions 和 optional_permissionshost_permissionscontent_scripts（匹配了哪些网站）background（service worker / background page）action（popup 等）oauth2、externally_connectable 等敏感字段storage、cookies 等数据相关权限icons 字段（检查是否齐全：16, 32, 48, 128）default_locale 和 _locales 目录
-
浏览核心代码文件，理解：
- 扩展到底做了什么（核心功能）
- 每个权限实际用在哪里、为什么需要
- 是否有网络请求（发往哪里、传了什么数据）
- 是否收集/存储用户数据
- 是否使用远程代码加载（eval、new Function、远程 JS）
- 是否有付费功能或应用内购买
-
识别数据流：
- 哪些数据被读取（浏览历史、书签、标签页信息、表单数据等）
- 哪些数据被存储（本地 storage vs 远程服务器）
- 哪些数据被传输到外部（API 调用、分析服务等）
- 是否处理用户生成内容
这一步要做得扎实——后面所有资料的质量取决于对代码的理解深度。权限说明不能是泛泛的套话，必须精确到"哪行代码用了这个权限、用来做什么"。
第二步：生成图片素材
文字资料分析完成后，在生成文档之前（或同时），完成以下图片素材的生成：
2a. 生成 128x128 商店图标
Chrome Web Store 要求上传一个 128x128 px 的 PNG 商店图标。
必须基于扩展现有图标生成——不要凭空设计新图标。具体流程：
-
在 manifest 的 icons 字段中找到现有图标文件（通常有 16/32/48/128 几种尺寸）
-
读取最大尺寸的图标文件（优先 128，其次 48、32）作为源素材
-
基于源图标，生成一个高清的 128x128 px PNG 商店图标：
- 如果源图标就是 128px 且质量足够，可以直接复制过来
- 如果源图标较小（48 或 32），需要使用脚本将其放大并优化清晰度
- 保持原始图标的设计风格和颜色不变
- 如果原始图标有透明背景且在白色背景上展示效果不好，可以加上圆角矩形或圆形背景色衬底
- 确保图标在小尺寸下辨识度高
-
输出保存到 <扩展名>-store-assets/upload-files/store-icon-128.png
可以使用 Python（Pillow）、Node.js（sharp）或 canvas-design 技能来处理图标缩放和优化。
2b. 生成商店截图
调用 chrome-webstore-screenshots 技能生成 5 张 1280x800 px 的商店截图。
截图输出目录：<扩展名>-store-assets/upload-files/screenshots/
截图场景应基于第一步的代码分析结果来选择——因为你已经完全理解了扩展的功能和 UI 入口，可以给出最合适的 5 个截图场景。
2c. 生成宣传图（可选）
如果有能力生成，也可以额外产出：
- Small Promo Tile: 440x280 px（商店必需）
- Marquee Promo Tile: 1400x560 px（可选）
这两张图通常需要设计感更强的构图（产品截图 + 标语 + 品牌色背景），如果条件允许可以使用 canvas-design 技能生成，否则在文档中提醒用户自行准备。
第三步：生成提交资料文档
将分析结果整理成英文版和中文版两份完整 Markdown 文档。英文版保存到 <扩展名>-store-assets/language-versions/full-submission.en.md，中文版保存到 <扩展名>-store-assets/language-versions/full-submission.zh.md。同时生成 <扩展名>-store-assets/fill-text.md 作为首选填写入口。
隐私政策分别保存到 <扩展名>-store-assets/language-versions/privacy-policy.en.md 和 <扩展名>-store-assets/language-versions/privacy-policy.zh.md，方便用户按商店语言选择发布。兼容旧流程时可在根目录额外放一份推荐语言的 privacy-policy.md 快捷副本。
第四步：打包扩展 ZIP
Chrome Web Store 上传要求提供一个 ZIP 文件，包含扩展的完整源代码。在输出目录中提供一份打包好的 ZIP，方便用户直接上传。
- 从
manifest.json 读取 version 字段（如 "1.0.2"）
- 将扩展源代码目录打包为 ZIP 文件，命名为
<扩展名>-v<版本号>.zip（如 yaoji-v1.0.2.zip）
- 打包时排除以下文件和目录：
.git/、.gitignorenode_modules/<扩展名>-store-assets/（输出目录本身）.DS_Store*.map（source map 文件）- 其他开发工具文件（
.eslintrc*、.prettierrc*、tsconfig.json、package.json、package-lock.json、webpack.config.*、vite.config.* 等），除非它们是扩展运行所必需的
- 保存到
<扩展名>-store-assets/upload-files/<扩展名>-v<版本号>.zip
- 如需兼容旧流程，可在根目录放一份 ZIP 快捷副本，但 Dashboard 文档中的主路径必须指向
upload-files/。
可以用 bash 的 zip 命令或 Python 的 zipfile 模块来打包。确保 ZIP 解压后根目录直接就是 manifest.json 所在的层级（不要多套一层目录）。
文档结构
以下每个章节对应 Chrome Web Store Developer Dashboard 中的一个或多个表单字段。
章节标题后的括号标注了对应的 Dashboard 页签，方便逐项填写。
1. Store Listing — 商店列表页
1.1 扩展名称 (Item name)
从 manifest 的 name 字段取，可适当优化。
要求：
- 不能包含 "extension"、"free"、"best" 等违规关键词
- 不能误导性地使用其他品牌名
- 和 manifest.json 中的 name 保持一致或接近
1.2 简短描述 (Summary)
≤132 字符，显示在商店搜索结果中。一句话说清核心价值。语言与扩展一致。
写法：用动词开头更好。不要用"一个用来..."这种废话开头。
1.3 详细描述 (Detailed Description)
显示在商店扩展详情页。语言与扩展一致。
要求：
- 第一段说清楚这个扩展能帮用户解决什么问题
- 中间段列出关键功能（每个功能另起一行，不要用 Markdown 列表符号）
- 最后一段写使用场景或目标用户
- 不要夸大、不要用 "best"、"#1"、"top" 之类的营销词（Google 审核会拒）
- 不要堆砌关键词（keyword spam 会被拒）
- 长度 300-1000 字符为佳
1.4 分类 (Primary Category)
从以下 Chrome Web Store 官方分类中选择最合适的一个：
| 分类 | 适用场景 |
|---|
| Accessibility | 无障碍辅助功能 |
| Art & Design | 图片查看/编辑/设计工具 |
| Communication | 通讯和消息工具 |
| Developer Tools | 开发调试/性能分析/代码工具 |
| Education | 教学辅助和学习资源 |
| Entertainment | 娱乐、音乐、视频 |
| Functionality & UI | 增强浏览器界面（标签管理等） |
| Games | 游戏 |
| Household | 预算、菜谱、产品研究 |
| Just for Fun | 纯娱乐小工具 |
| News & Weather | 新闻和天气 |
| Privacy & Security | VPN、密码管理、安全工具 |
| Shopping | 比价、优惠券 |
| Social Media & Networking | 社交平台增强 |
| Tools | 通用工具（不属于其他分类） |
| Travel | 旅行规划 |
| Well-being | 自助、正念、个人发展 |
| Workflow & Planning | 生产力工具、任务管理、时间追踪 |
1.5 语言 (Language)
扩展的主要语言。如果有 _locales 目录，列出所有支持的语言。
1.6 商店图标 (Store Icon)
128x128 px PNG 商店图标。在第二步中已自动生成或确认了现有图标，在文档中标注图标文件路径。
1.7 截图 (Screenshots)
5 张 1280x800 px 截图。在第二步中已通过 chrome-webstore-screenshots 技能自动生成，在文档中标注截图文件路径和对应场景说明。
1.8 宣传图 (Promotional Images)
- Small Promo Tile: 440x280 px（必需）
- Marquee Promo Tile: 1400x560 px（可选）
如果在第二步中已生成，标注路径；否则提醒用户自行准备。
1.9 宣传视频 (Promotional Video)
YouTube 视频链接（可选）。如果扩展功能复杂，建议准备。
1.10 其他可选字段
| 字段 | 说明 |
|---|
| Official URL | 官方网站（需通过 Google Search Console 验证） |
| Homepage URL | 扩展主页 |
| Support URL | 用户支持页面 |
| Mature Content | 是否包含成人内容（是/否） |
2. Privacy — 隐私页
2.1 单一用途声明 (Single Purpose Description)
用一句话描述扩展的唯一核心目的。
Google 要求每个扩展只做一件事，而且这件事必须"narrow and easy to understand"。审核员会拿这句话和扩展的实际功能对比——如果扩展做的事情超出了这句话的范围，会被拒。
格式：一句话描述扩展做什么（语言与扩展一致）。
如果扩展做了多件事，找到一个足够概括的上位描述，而不是列举功能。
必须在 Dashboard 直接粘贴字段 章节中提供：
Single purpose — English paste text
[one narrow, easy-to-understand sentence]
单一用途 — 中文说明/中文填写版
[一句中文说明，帮助用户理解；如果扩展中文上架，可直接粘贴]
示例：
xPoster imports user-provided Markdown drafts into the active X Article editor and helps users verify that the publishing workflow is ready and complete.
2.2 权限说明 (Permission Justifications)
这是审核的重点，也是最容易被拒的部分。Dashboard 上会列出 manifest 中声明的每个权限，每个都需要填写说明。
对每个权限逐一说明：
#### `<permission名称>`
**用途**：一句话说明为什么需要这个权限
**代码位置**：具体文件名和功能描述
**如果没有这个权限会怎样**：说明缺少此权限时功能如何受限
要点：
activeTab 比 tabs 安全，如果两个都有要解释为什么 activeTab 不够host_permissions 如果用了 <all_urls> 或通配符，审核会特别严格，必须充分说明storage 要说明存了什么、是否包含用户敏感信息- 任何看起来"超范围"的权限都要解释和核心功能的关系
- Google 的原则是"minimum permissions consistent with the purpose"——多余的权限会导致被拒
- 如果发现代码中有未使用的权限，在文档中标注建议移除
必须为每个权限生成一个 Dashboard 输入框可直接粘贴 的短说明，格式如下：
Permission: tabs — English paste text
[2-4 sentences. Explain exactly why this permission is needed, what user action triggers it, and what the extension does not do if relevant.]
权限：tabs — 中文说明/中文填写版
[对应中文版本。不要只翻译术语，要让用户看懂为什么要填这段。]
权限说明写法要求：
- 开头直接说用途：
The extension uses [permission] to...
- 说明用户触发条件：
when the user clicks...、when the user opens...
- 如权限敏感，补一句限制：
It does not track browsing history.、It does not read unrelated tabs.
tabs 必须解释为什么 active tab URL / tab messaging / tab navigation 与单一用途相关。sidePanel 必须解释它是主 UI，不是辅助功能。storage 必须说清存什么、存在哪里、是否离开设备。- host permissions 必须区分内容脚本站点和通配符/远程资源站点。
常见权限示例：
The extension uses the sidePanel permission to provide its main user interface as a Chrome side panel. Users use this panel to load drafts, preview content, run checks, and start the import workflow while staying on the current browser tab.
The extension uses the tabs permission to identify the active tab, confirm whether it is a supported target page, send messages to that tab, and open or navigate to the required page when the user requests it. It does not track browsing history.
The extension uses the storage permission to save user settings and draft state locally in Chrome extension storage. This data stays in the user's browser and is not sent to the extension developer.
2.3 远程代码声明 (Remote Code Declaration)
Dashboard 会问："Does your extension execute remote code?"
需要选择 Yes 或 No，如果 Yes 需要提供说明。
检测以下情况：
- 动态
eval() 或 new Function()
- 从远程服务器加载并执行 JS
- 使用
chrome.scripting.executeScript 执行非扩展包内的代码
- 通过
<script src="远程URL"> 加载脚本
注意：Manifest V3 已禁止远程代码加载。如果是 MV3 扩展且检测到远程代码，这是一个严重问题，需要在文档开头醒目提醒。
如果没有远程代码：选 "No, I am not using remote code."
必须输出一段可粘贴解释：
Remote code — English paste text
No. The extension does not load or execute remote JavaScript. All executable JavaScript is packaged with the submitted extension.
同时输出中文说明：
远程代码 — 中文说明
选择 No。扩展不加载或执行远程 JavaScript，所有可执行代码都包含在提交的扩展包中。
2.4 数据使用披露 (Data Use Disclosures)
Chrome Web Store 要求声明是否收集以下各类数据。根据代码分析如实填写：
| 数据类型 | 具体包含 | 是否收集 | 用途 | 是否传输到外部 |
|---|
| Personally identifiable information | 姓名、地址、电话、邮箱、用户名、身份证号、账号 | | | |
| Health information | 医疗/健康相关数据 | | | |
| Financial and payment information | 财务和支付信息 | | | |
| Authentication information | 登录凭证、密码、认证 cookies | | | |
| Personal communications | 个人通讯内容 | | | |
| Location | 位置信息 | | | |
| Web browsing activity | 域名、URL、请求/响应内容、浏览器存储（cookies） | | | |
| User activity | 用户在扩展内的操作活动 | | | |
| Website content | 网站页面内容和资源 | | | |
| Form data | 用户提交的表单数据 | | | |
| User-generated content | 用户创建的内容 | | | |
每个标记为"是"的条目，补充说明：
- 具体收集了什么
- 为什么要收集
- 数据去了哪里（本地/远程/第三方）
- 是否匿名化处理
必须新增一个 Data Use — Dashboard 勾选建议 小节：
- 用表格列出每个 Dashboard 数据类型：
建议勾选 Yes/No、English paste text、中文解释。
- 对容易混淆的项目必须给出判断理由，尤其是：
- Authentication information: 是否真正收集凭证，还是浏览器在同站请求中自动发送 cookie。
- Web browsing activity: 是否读取 active tab URL，是否属于保守披露。
- Website content: 是否读取/修改网页内容。
- User-generated content: 是否处理用户草稿。
- Personally identifiable information: 用户内容可能包含个人信息时，是否扩展主动收集。
- 如果建议保守勾选某项，必须明确说“保守披露原因”。
2.5 Limited Use 合规认证
Chrome Web Store 要求开发者确认以下四项合规声明（勾选确认）：
- Allowed Use — 数据仅用于扩展声明的功能
- Allowed Transfer — 数据仅在以下情况转移：实现扩展功能、法律合规、安全需要、业务转让
- No Advertising Use — 不使用用户数据进行个性化广告或重定向广告
- No Human Access — 员工不能查看用户数据，除非：用户同意、安全需要、法律要求、匿名化后用于统计
根据代码分析，评估扩展是否能满足这四项要求。如果某项不满足，在文档中醒目标注。
必须输出一段可粘贴解释：
Limited Use — English paste text
The extension uses user data only to provide or improve its single stated purpose. It does not sell user data, use user data for advertising, transfer user data except as necessary for the user-requested feature, or allow humans to read user data.
并输出中文说明。
2.6 隐私政策链接 (Privacy Policy URL)
必需字段。需要提供一个可公开访问的 URL。
根据数据使用分析，生成一份隐私政策草稿。即使扩展完全不收集任何用户数据，也必须提供隐私政策（声明不收集数据即可）。
隐私政策内容应覆盖：
- 扩展收集哪些信息（如果有的话）
- 信息如何使用
- 信息是否共享给第三方
- 数据存储方式和位置（本地/远程）
- 数据保留期限
- 用户如何查看和删除自己的数据
- 隐私政策的变更通知方式
- 联系方式（检查 memory 中是否存有用户邮箱，如有则直接填入；如无则留占位符
[YOUR_EMAIL]）
- 生效日期
隐私政策和数据使用披露必须一致——Dashboard 上会提示 "Your disclosures should be consistent with the existing privacy policy URL."
隐私政策的发布方式
Chrome Web Store 需要的是一个可公开访问的 URL，最简单的方式是用 GitHub Pages 托管。在 <扩展名>-store-assets/ 中生成隐私政策后，还需要帮用户把它部署上线：
-
生成 upload-files/privacy-page/index.html — 将推荐提交语言的隐私政策内容渲染为一个简洁的 HTML 页面（纯文本排版，不需要花哨样式），放在 <扩展名>-store-assets/upload-files/privacy-page/ 目录下。这个 HTML 文件就是 GitHub Pages 会展示的页面。
-
创建 GitHub 仓库并部署 — 询问用户的 GitHub 用户名，然后：
- 用
gh 命令创建一个公开仓库（命名建议：<扩展名>-privacy，如 yaoji-privacy）
- 将
upload-files/privacy-page/index.html 推送到仓库
- 启用 GitHub Pages（从 main 分支的根目录部署）
- 最终 URL 格式：
https://<username>.github.io/<repo-name>/
-
在提交资料文档中填入最终 URL — 拿到 GitHub Pages URL 后，更新 fill-text.md 和 language-versions/ 中的隐私政策链接字段。
如果用户已有类似仓库（如 https://nevertoday.github.io/xxx-privacy/），可以参考其命名风格。
3. Distribution — 分发设置
3.1 可见性 (Visibility)
建议选项及说明：
| 选项 | 说明 |
|---|
| Public | 所有用户可见，在商店搜索中出现 |
| Unlisted | 不出现在搜索中，仅通过直链安装 |
| Private | 仅限指定用户（测试人员/Google Group/域内用户） |
根据扩展的性质给出建议。
3.2 地区 (Geographic Distribution)
默认选"所有地区"。如果扩展仅适用于特定地区（如仅支持中文），可以建议选择特定国家。
3.3 付费声明 (Pricing / In-App Purchases)
如果扩展有付费功能或应用内购买，需要勾选 "Contains in-app purchases"，商店会显示相应标记。
4. Test Instructions — 测试说明（如需要）
如果扩展需要登录或特殊配置才能使用，需要在此填写：
- 测试步骤说明
- 测试账号和密码（如果需要登录）
- 任何需要的前置条件
5. 审核风险评估
列出可能引起审核员关注的点，提前准备应对：
- 敏感权限组合（如同时有
tabs + webRequest + <all_urls>）
- 宽泛的 host permissions（
<all_urls> 或通配符）
- 特殊 API 使用（如
webRequest、debugger、proxy、nativeMessaging）
- Manifest V2 → V3 迁移问题
- 远程代码使用
- 未使用的权限（多余权限会导致被拒）
- 与政策可能冲突的功能（广告拦截、数据抓取等）
- 是否需要额外的审核表单
6. 提交清单
最后附一份提交前的检查清单，涵盖 Dashboard 所有页签：
Store Listing 页签：
Privacy 页签：
Distribution 页签：
其他：
输出要求
- 所有产出物统一放在主目录/桌面下的
<扩展名>-store-assets/ 文件夹中（见上方"输出目录"章节），默认不要放到扩展源码目录内。
- 填文字入口：
<扩展名>-store-assets/fill-text.md
- 上传文件入口：
<扩展名>-store-assets/upload-files/
- 商店图标：
<扩展名>-store-assets/upload-files/store-icon-128.png
- 截图：
<扩展名>-store-assets/upload-files/screenshots/
- GitHub Pages 隐私网页：
<扩展名>-store-assets/upload-files/privacy-page/index.html
- 可上传扩展 ZIP：
<扩展名>-store-assets/upload-files/<扩展名>-v<版本号>.zip
- 中英文资料归档：
<扩展名>-store-assets/language-versions/
- 生成脚本/临时文件：
<扩展名>-store-assets/working/
- 可选兼容快捷副本：根目录可保留
chrome-store-submission.md、dashboard-paste-fields.md、privacy-policy.md、store-icon-128.png 等，但提交指引必须优先指向 fill-text.md 和 upload-files/。
- 语言规则：所有需要填入 Dashboard 表单的文案必须同时提供英文版和中文版，但要放在
language-versions/ 中，不要把双语内容混成唯一交付物。判断依据：manifest.json 的 default_locale、UI 文本的实际语言，明确标注推荐粘贴哪一版。如果扩展是中文的，fill-text.md 推荐中文；如果扩展是英文的，fill-text.md 推荐英文。另一语言版本必须完整保存在 language-versions/ 中。
language-versions/fill-text.en.md、full-submission.en.md、privacy-policy.en.md 正文应是英文；不要加入“中文说明/中文填写版”这种中文解释。language-versions/fill-text.zh.md、full-submission.zh.md、privacy-policy.zh.md 正文应是中文；不要加入英文解释段落。权限名、API 名、URL、文件路径、产品名可以保持英文原文。- 数据使用披露在
fill-text.md 可以用简短中英对照帮助用户理解 Dashboard；在 language-versions/fill-text.en.md 和 language-versions/fill-text.zh.md 必须分别输出单语言版本。
README.md 和 fill-text.md 开头列出两个核心入口和文件用途，方便用户按顺序上传
文档顺序要求
fill-text.md 必须按 Chrome Web Store Dashboard 页面顺序组织：
- Store Listing
- Privacy
- Permissions / Host permissions
- Distribution
- Review instructions
- Final submit checklist
language-versions/fill-text.en.md 和 language-versions/fill-text.zh.md 必须使用同样顺序，只输出对应语言的可粘贴字段。英文版和中文版完整资料必须分别按这个顺序组织：
- Upload files / 文件清单
- Dashboard 直接粘贴字段（当前文件夹对应语言的纯文本版本，推荐粘贴版本明确）
- Store Listing 详细说明
- Privacy / 数据披露详细说明
- Permission evidence / 权限代码证据
- Test instructions
- Risk assessment
- Final checklist
- Verification performed
如果缺少 fill-text.md、upload-files/、language-versions/fill-text.en.md、language-versions/fill-text.zh.md 中任意一项，视为 skill 输出失败，需要补写。
最终验收要求
交付前必须主动核对并在最终回复中简短报告：
- 输出目录是否位于主目录/桌面根目录，例如
~/Desktop/<扩展名>-store-assets/，而不是扩展源码目录内。
fill-text.md 是否包含 Dashboard 顺序的可粘贴字段、文件上传路径、清单、风险提醒。upload-files/ 是否包含商店图标、截图、宣传图、隐私网页和可上传 ZIP。language-versions/ 是否包含英文 dashboard 字段、中文 dashboard 字段、英文/中文完整提交说明、英文/中文隐私政策。- README 是否清楚告诉用户：填文字打开
fill-text.md；上传图片和 ZIP 打开 upload-files/。
验收时如发现旧版扁平文件仍在根目录，可以保留为兼容快捷副本，但不能让它们成为唯一或主要交付路径。
纯文本格式要求
需要复制粘贴到 Chrome Web Store Dashboard 表单中的文本，必须使用纯文本格式，不要包含任何 Markdown 语法。Chrome 的表单输入框不渲染 Markdown，带语法标记的文本粘贴过去会显得很奇怪。
具体来说，以下内容必须是纯文本：
- 扩展名称、简短描述、详细描述
- 单一用途声明
- 每个权限的说明文字
- 隐私政策正文（
language-versions/privacy-policy.*.md 和可选兼容 privacy-policy.md 中的内容也要是纯文本，因为最终要发布到网页上）
- 测试说明
纯文本的意思是：
- 不要用
**加粗**，直接写文字
- 不要用
# 标题，用文字本身的结构来组织
- 不要用
- 或 * 做列表项，改用换行或数字序号（1. 2. 3.）
- 不要用
`代码` 包裹术语
- 不要用
✓、→ 之类的特殊符号装饰，除非 Chrome 表单本身支持
- 详细描述中如果需要列举功能，直接换行写即可，Chrome 商店详情页会保留换行
文档本身的结构性标题（如"1. Store Listing"、"2.2 权限说明"）可以用 Markdown 格式，因为那些是给开发者看的文档框架，不需要复制到表单里。
- 如果代码分析中发现任何安全隐患或不符合 Chrome Web Store 政策的问题，在文档开头用醒目方式提醒：
> ⚠️ **审核风险提醒**
> - [具体问题描述]
> - [建议的修复方案]
分析深度
不要只看 manifest.json 就开始写。要做到：
- 打开每个 background script / service worker，理解后台逻辑
- 打开 content scripts，理解注入了什么
- 检查 popup / options 页面的逻辑
- 搜索代码中的
fetch、XMLHttpRequest、chrome.storage、chrome.cookies 等关键调用
- 搜索
eval、new Function、chrome.scripting.executeScript 等远程代码标志
- 如果有
_locales 目录，检查国际化支持情况
- 检查是否有第三方 SDK（analytics、ads 等），这些会影响数据披露
这些分析工作量不小，但它直接决定了权限说明和数据披露的准确性——这两项是审核通过率的关键。
