feat(skills): built-in skill catalog with install-on-demand

apps/desktop/resources/bundled-skills/brand-guidelines/SKILL.md

@@ -0,0 +1,118 @@
+---
+name: 品牌规范
+description: 梳理品牌定位与调性，定义 logo 用法、主辅色、字体、图形语言与语气，输出可分发的品牌规范文档（Markdown 或单文件 HTML，含色值与用法示例）
+category: 设计与UI
+allowed-tools:
+ - Read
+ - Write
+---
+
+# 品牌规范
+
+## 目标
+
+为一个企业、产品或个人品牌产出一份**可分发、可执行的品牌规范文档（Brand Guidelines）**：把品牌的定位、调性、logo 用法、配色、字体、图形语言、语气统一成一套明确规则，让不同的人（设计、市场、外包、AI）在做官网、宣传册、PPT、社媒、邮件时都能做出**风格一致**的东西。
+
+品牌规范的价值在于**约束**：不是罗列"我们有蓝色和白色"，而是明确"主色是 #1B3A6B，用在标题和主按钮；辅色橙 #FF7A45，只做点缀，占比不超过 10%；正文永远用中性灰，不用主色"。规则越具体，一致性越强。
+
+## 工作流
+
+### 第 1 步：梳理品牌定位与调性
+
+先收敛品牌的"人格"，这是所有视觉决策的根：
+
+- **品牌是什么**：一句话定位、核心价值主张、与竞品的差异。
+- **给谁看**：目标人群、行业、To B / To C，决定专业度与温度。
+- **品牌人格**：用形容词或对立轴定位——专业⇄亲和、稳重⇄先锋、极简⇄丰富、理性⇄感性、高端⇄普惠。挑 3–5 个关键词。
+- **参考与禁忌**：欣赏哪些品牌的观感、绝对不想要的感觉。
+
+若用户已有 logo、现用色、现用字体或既有物料，用 Read 读取用户提供的相关文件（品牌简报、现有文档、色值表）作为输入，在其基础上系统化，而不是推倒重来。
+
+### 第 2 步：定义视觉与语言规范
+
+逐项定义，每一项都要给**规则 + 数值 + 该用/不该用**：
+
+**Logo 用法**
+- 主 logo、副标（横版/竖版/纯图标）各自的使用场景。
+- **安全边距（clear space）**：logo 四周留白不小于某个基准（如 logo 高度的 0.5 倍）。
+- **最小尺寸**：小于多少像素/毫米不得使用，保证清晰。
+- **禁用示范**：不得拉伸变形、不得改色、不得加阴影/描边、不得置于杂乱或低对比背景上。
+
+**配色系统**
+- **主色（Primary）**：1–2 个，给 HEX + RGB，说明用途（标题、主按钮、品牌标识）。
+- **辅助色（Secondary）**：支撑主色的邻近色/深浅变体。
+- **强调色（Accent）**：1 个，只做点缀（CTA、高亮），并规定占比上限。
+- **中性色（Neutral）**：文字、背景、分隔线用的黑白灰阶梯。
+- **语义色**（如需）：成功/警告/错误。
+- 给每个色标注**无障碍对比**建议（正文与背景对比度尽量 ≥ 4.5:1）。
+
+**字体系统（Typography）**
+- 中文主字体 + 英文主字体（如思源黑体 / Roboto），及备用（fallback）字体。
+- **字阶（type scale）**：H1/H2/H3/正文/注释的字号、字重、行高，给一套具体数值。
+- 用途规则：标题用什么字重、正文永远不用某某色等。
+
+**图形语言（Graphics）**
+- 圆角还是直角、线条粗细、图标风格（线性/面性）、插画/摄影的调性、间距节奏、常用版式栅格。
+
+**语气（Voice & Tone）**
+- 品牌怎么说话：专业 vs 亲切、是否用"你"、是否用 emoji、术语深浅。
+- 给 **Do / Don't 例句**：同一句话"品牌腔"怎么写、"不要"怎么写。
+
+### 第 3 步：配用法示例
+
+每条规则尽量配一个**正例 + 反例**，让读者一眼看懂边界。如配色给色块 + 十六进制；字体给排版样张；logo 给"正确留白"与"禁止拉伸"对照。示例是品牌规范里最被反复查阅的部分。
+
+### 第 4 步：输出可分发文档
+
+把上述内容组织成一份完整文档，用 Write 保存。两种格式按用户需要选择：
+
+- **Markdown**：便于纳入代码仓 / wiki / 协作文档，纯文本可 diff。
+- **单文件 HTML**：自包含、内联 CSS，可直接在浏览器打开演示，能用真实色块、真实字体样张把规范"演出来"，观感更接近成品。适合对外分发或给非技术同事看。
+
+若选 HTML，直接用 CSS 变量把品牌色/字体定义在 `:root`，让文档本身就是品牌的一次示范。
+
+## 输出格式
+
+文档结构建议如下：
+
+```markdown
+# <品牌名> 品牌规范 Brand Guidelines
+
+## 1. 品牌定位与调性
+- 一句话定位 / 价值主张 / 人格关键词（3–5 个）
+
+## 2. Logo 用法
+- 主/副标 · 使用场景
+- 安全边距 · 最小尺寸
+- ✅ 正确用法 / ❌ 禁用示范
+
+## 3. 配色系统
+| 角色 | 名称 | HEX | RGB | 用途 | 占比/对比建议 |
+|------|------|-----|-----|------|--------------|
+| 主色 | … | #1B3A6B | … | 标题/主按钮 | 对比≥4.5 |
+| 强调 | … | #FF7A45 | … | 仅 CTA 点缀 | ≤10% |
+| 中性 | … | #2B2B2B / #F5F7FA | … | 文字/背景 | — |
+
+## 4. 字体系统
+- 中文 / 英文主字体 + fallback
+- 字阶表：H1…正文（字号/字重/行高）
+
+## 5. 图形语言
+- 圆角 · 线条 · 图标风格 · 版式栅格
+
+## 6. 语气 Voice & Tone
+- 人格描述 + Do / Don't 例句
+
+## 7. 应用示例
+- 名片 / PPT / 社媒 / 邮件签名 的示范
+```
+
+HTML 版则把上述各节渲染为带真实色块、真实字体样张、对照示例的页面，内联所有样式，单文件可直接打开。
+
+## 边界
+
+- **基于用户素材系统化**，不凭空替品牌重定方向；有既有 logo/色值/字体时用 Read 读入并沿用。
+- **不生成 logo 图形本身**：本 skill 定义 logo 的**用法规则**，不绘制/生成 logo 图像；若无 logo，提示用户先确定标识。
+- **不复刻他人品牌**：可参考某种"风格气质"，但不得直接照搬受版权/商标保护的品牌资产（配色体系、logo）。用户举例的知名品牌风格仅作调性参考。
+- **色值与字体要可落地**：优先给可获取的字体（系统字体 / 开源字体如思源系列 / Google Fonts），避免规范无法执行。
+- 规则要**具体到可执行**——给数值、给占比、给 Do/Don't，而不是含糊的形容词堆砌。

apps/desktop/resources/bundled-skills/changelog-generator/SKILL.md

@@ -0,0 +1,131 @@
+---
+name: Changelog 生成
+description: 从 git 提交历史生成结构化 changelog 或 release notes，按 feat/fix/breaking 分类，并把技术描述改写成面向用户的语言。当用户需要生成更新日志、发布说明、版本变更记录时使用。
+category: 文档与写作
+allowed-tools:
+ - Bash
+ - Read
+ - Write
+---
+
+# Changelog 生成
+
+## 目标
+
+从项目的 git 提交历史中提取变更，生成**结构化、面向读者**的 changelog 或 release notes。核心工作是两步转换：先把散乱的 commit 归类（新功能 / 改进 / 修复 / 破坏性变更等），再把工程师视角的技术描述改写成目标读者（终端用户、集成方开发者、或应用商店审核）看得懂、关心的语言。
+
+一条 commit `fix: null check in auth middleware` 对开发者有意义，但用户想看到的是"修复了部分场景下登录失败的问题"。本 skill 就是完成这层翻译，并按版本 / 时间范围组织成规范文档。
+
+## 工作流步骤
+
+### 步骤 1：确认输入参数
+
+动手前明确以下信息，缺失的先问用户或用合理默认：
+
+- **仓库位置**：默认当前工作目录；若用户给了路径则 `cd` 到对应目录操作。
+- **范围**：三选一
+ - 版本区间：如 `v2.4.0..v2.5.0` 或 `v2.4.0..HEAD`
+ - 时间范围：如 `2024-03-01` 到 `2024-03-15`
+ - 相对范围：如"本周""最近 20 次提交"
+- **目标读者**：终端用户（弱化技术）/ 开发者集成方（保留 API 细节）/ 应用商店（简短生动、≤200 字）。读者不同，改写力度完全不同。
+- **输出格式与语言**：Markdown（默认）/ 纯文本；中文 / 英文。
+- **产品名与版本号**：用于标题。
+
+### 步骤 2：用 Bash 抓取提交历史
+
+用 `git log` 拉取范围内的提交。**不要用 `git log` 的分页交互**，加 `--no-pager` 或管道处理。推荐命令（按范围二选一）：
+
+版本区间：
+```
+git --no-pager log v2.4.0..v2.5.0 --pretty=format:'%h%x09%an%x09%ad%x09%s' --date=short
+```
+
+时间范围：
+```
+git --no-pager log --since='2024-03-01' --until='2024-03-15' --pretty=format:'%h%x09%an%x09%ad%x09%s' --date=short
+```
+
+需要正文（含 BREAKING CHANGE 说明、多行描述）时追加 `%x09%b` 或分次用 `--pretty=format:'%H%n%B%n---'`。
+
+辅助命令：
+- 列出可用 tag（确认版本区间是否存在）：`git --no-pager tag --sort=-creatordate | head -20`
+- 上一个 tag：`git describe --tags --abbrev=0`
+- 首次提交（无上一 tag 时兜底范围）：`git --no-pager log --pretty=format:'%h %ad %s' --date=short`
+- 统计文件改动辅助判断影响面：`git --no-pager log <range> --stat`
+
+若范围内无提交或 tag 不存在，明确告知用户并请其确认范围，不要静默产出空文档。
+
+### 步骤 3：解析与归类
+
+逐条解析 commit subject，优先识别 Conventional Commits 前缀，映射到用户友好的分组：
+
+| commit 前缀 | 分组 | Emoji |
+| --- | --- | --- |
+| `feat` | 新功能 | ✨ |
+| `fix` | 问题修复 | 🐛 |
+| `perf` | 性能优化 | ⚡ |
+| `refactor` / `style` / `chore` / `build` / `ci` | 内部改进（多数对用户不可见，视读者决定是否收录或合并为一句） | 🔧 |
+| `docs` | 文档 | 📝 |
+| `revert` | 回滚 | ⏪ |
+| 含 `BREAKING CHANGE` 或 `!`（如 `feat!:`） | 破坏性变更（单独置顶章节） | ⚠️ |
+
+处理原则：
+- **破坏性变更最重要**，永远放在最前，说明改了什么、为何、如何迁移。
+- 面向终端用户时，`chore`/`refactor`/`ci`/`test` 等纯工程提交通常**不进入**正文，或合并成一句"底层稳定性与性能改进"。
+- 面向开发者集成方时，API 变更、依赖升级要保留并标注。
+- 不带规范前缀的 commit：读 subject 语义自行归类；实在无法判断的归到"其他变更"。
+- 合并重复：同一功能的多次提交（`wip`、`fix typo`、`address review`）合并为一条有意义的条目，不逐条罗列。
+- 过滤噪音：`Merge branch`、纯格式化、版本号 bump 等一般剔除。
+
+### 步骤 4：面向读者改写
+
+这是最关键的一步。把每条选中的 commit 改写成读者视角：
+
+- **讲结果，不讲实现**："重构了 X 模块"→"提升了 X 的加载速度"。
+- **讲价值**：说明这个变更给用户带来什么好处或解决了什么困扰。
+- **去术语**：终端用户文档避免 `middleware`、`race condition`、`refactor` 等词；开发者文档可保留。
+- **动词开头、简洁**：每条一句话，句式统一（如统一用"新增/优化/修复"开头）。
+- **不确定语义时不编造**：若 commit 信息太简略无法判断用户可见影响，保留原意并标注 `[待确认：此项面向用户的表述]`，请用户核对，不要臆造功能。
+
+### 步骤 5：组装文档
+
+按目标格式拼装（见下）。破坏性变更置顶，其余按重要性排序（新功能 > 修复 > 改进）。
+
+## 输出格式约定
+
+**标准 changelog / release notes（Markdown）：**
+
+```
+# [产品名] [版本号] — [日期或日期范围]
+
+> [可选：一句话概述本次更新亮点]
+
+## ⚠️ 破坏性变更
+- [改了什么]。迁移方式：[如何适配]
+
+## ✨ 新功能
+- [用户视角的功能描述]
+
+## ⚡ 性能优化
+- [优化点]
+
+## 🐛 问题修复
+- [修了什么问题]
+
+## 🔧 其他改进
+- [底层改进合并描述]
+```
+
+- 遵循 [Keep a Changelog] 惯例：分组标题稳定、条目以动词开头、最新版本在最上。
+- **应用商店描述**：不用分组标题，写成 150~200 字的连贯段落，突出 1~3 个最重要的新功能，语言生动、避免技术词，末尾可加一句好评引导。
+- 空的分组不输出（没有 perf 就不放性能章节）。
+- 交付方式：短内容直接贴在对话中；用户要求成文或内容较长时，用 `Write` 保存为 `CHANGELOG.md` 或 `RELEASE_NOTES.md`。若项目已有 `CHANGELOG.md`，先 `Read` 读取，把新版本**追加到顶部**，保留历史条目，不要覆盖。
+- 每条可选择性附上 commit 短哈希便于溯源（`(a1b2c3d)`），面向终端用户时通常省略。
+
+## 边界
+
+- **只读取，不改写历史**：仅执行 `git log`、`git tag`、`git describe` 等只读命令，绝不执行 commit、push、tag、rebase 等修改仓库的操作。
+- **不编造变更**：文档内容严格来自真实 commit；无法判断的表述标注待确认，不虚构功能或数据。
+- **范围为空要报告**：区间无提交、tag 不存在、非 git 目录等情况，明确告知并请用户修正，不产出空壳文档。
+- **不做版本决策**：是否发布、版本号怎么定（semver 判断可给建议）由用户决定。
+- **敏感信息**：若 commit 信息里出现内部代号、未公开客户名、密钥等，改写时剔除或提示用户。

apps/desktop/resources/bundled-skills/competitive-ads-extractor/SKILL.md

@@ -0,0 +1,85 @@
+---
+name: 竞品广告拆解
+description: 当用户想研究竞争对手的广告与投放策略时使用。典型问法："帮我分析 X 竞品在 Facebook / 各渠道的广告"、"拆解这几个对手的广告卖点和落地页"、"看看同行都用什么钩子和 CTA"、"整理一份竞品广告对比，找可借鉴的打法"。
+category: 研究与分析
+allowed-tools:
+ - Read
+ - WebSearch
+---
+
+# 竞品广告拆解
+
+## 目标
+
+系统性拆解竞争对手的广告与落地页，把零散的广告素材转化为**结构化、可对比、能落地借鉴**的营销情报。产出不是"看到了哪些广告"，而是"对手在用什么打法、为什么有效、我方可以借鉴或差异化什么"。
+
+拆解维度贯穿从广告创意到转化路径的全链路：钩子（hook）、核心卖点、目标受众、创意角度、行动号召（CTA）、落地页设计与转化逻辑。适用场景：投放前的竞品调研、找新的创意角度、诊断自身广告为何转化差、进入新市场前摸清同行打法。
+
+## 工作流步骤
+
+### 1. 明确分析目标与范围
+
+先与用户确认这次拆解要服务什么决策，避免漫无目的地收集：
+
+- **分析目的**：找新创意角度、优化现有广告文案、研究定价与卖点、还是全面摸底一个新市场？
+- **竞品清单**：直接竞品（同品类）与间接/参照竞品（打同一人群）分别列出；如用户只给了行业，先帮其识别主要玩家。
+- **渠道范围**：Facebook/Instagram、Google、TikTok、LinkedIn、YouTube、落地页、邮件等，聚焦用户目标客群实际所在的渠道。
+- **分析维度侧重**：文案钩子、视觉创意、受众定位、卖点、优惠机制、落地页转化，明确重点，不必每维都同等深挖。
+
+把界定后的范围复述确认，作为后续拆解的锚点。
+
+### 2. 收集竞品广告与落地页素材
+
+用 WebSearch 系统性收集可公开获取的广告与营销素材：
+
+- **公开广告库**：Facebook/Meta Ad Library、TikTok Creative Center、Google Ads Transparency 等平台会公开展示投放中的广告，是一手素材的主要来源；检索时定位到具体品牌/主页。
+- **落地页**：从广告指向的落地页或官网营销页收集，关注首屏主张、卖点排布、社会证明、CTA、定价与优惠。
+- **多渠道多角度**：换关键词（品牌名、产品名、slogan、品类词）多轮检索；覆盖官方投放、媒体报道、用户讨论、营销分析文章等不同来源。
+- **记录元信息**：为每条素材记下来源、渠道、大致投放时间、广告形式（图文/视频/轮播）、可见的互动或投放持续情况，作为"是否是主推/长青广告"的旁证。
+
+注意：只收集平台公开展示的广告与营销信息；无法获取的（如真实投放预算、精确受众设置、内部数据）不臆测，标注为不可得。
+
+### 3. 结构化提取
+
+对每一条（或每一组）广告，按统一维度拆解，保证可横向对比：
+
+- **钩子（Hook）**：开头 3 秒/首行如何抓注意力——痛点、提问、反常识、数字、身份认同、好奇缺口等。
+- **核心卖点**：主打的价值主张是什么（省钱/省时/效果/身份/风险规避），一条广告的主卖点通常只有一个。
+- **目标受众**：从文案口吻、场景、痛点反推其瞄准的人群画像（身份、阶段、痛点、动机）。
+- **创意角度（Angle）**：切入同一卖点的叙事框架——恐惧诉求、before/after、用户证言、权威背书、对比竞品、稀缺/紧迫等。
+- **CTA**：行动号召的措辞与强度（立即购买 / 免费试用 / 领取优惠 / 了解更多），以及配套的优惠或紧迫感设计。
+- **创意形式**：图文/短视频/UGC 风格/达人口播等表现形式与视觉调性。
+- **落地页衔接**：广告承诺与落地页首屏是否一致，落地页如何承接并推进转化（表单/购买/预约），转化路径长短。
+
+对拿不准的推断（如受众、投放意图）标注为"推测"，与可直接观察到的事实区分开。
+
+### 4. 对比分析与洞察
+
+把结构化提取的结果汇总成对比，从中提炼可行动的洞察：
+
+- **横向对比**：把各竞品放在同一张表里，对比钩子类型、主卖点、角度、CTA、优惠机制，一眼看出各家打法异同。
+- **模式识别**：找出反复出现的共性打法（多家都在用的钩子/角度/卖点），这通常是被市场验证过的有效套路。
+- **空白与差异化**：识别无人主打的卖点、无人覆盖的人群、无人用的角度——这是差异化机会。
+- **可借鉴 vs 需规避**：明确哪些打法值得测试借鉴（并说明如何适配到自身产品），哪些是踩坑或不适合自身定位的。
+- **落地建议**：给出具体、可执行的下一步，如"可测试的 3 个新钩子""建议补强的落地页首屏主张""值得抢占的差异化卖点"。
+
+洞察要落到"我方能做什么"，而非停留在描述对手。
+
+## 输出格式
+
+默认交付**对比表 + 洞察小结**两部分：
+
+- **竞品广告对比表**：每行一个竞品（或一条代表性广告），列为 渠道 / 钩子 / 核心卖点 / 目标受众 / 创意角度 / CTA / 落地页要点 / 备注（来源与投放线索）。
+- **模式与洞察**：分点总结共性打法、市场空白、差异化机会。
+- **可借鉴清单**：按优先级列出可测试的具体动作，每条说明借鉴点与适配方式。
+- **来源附录**：列出所收集素材的来源/链接与观察时间，保证可追溯。
+
+如用户需要，可对单个重点竞品做深度拆解（逐条广告 + 落地页），或输出为可复用的分析模板。
+
+## 边界与注意事项
+
+- **只用公开信息**：仅分析平台公开展示的广告与营销页；不获取、不臆测竞品的内部数据（真实预算、精确受众、后台配置、转化率），此类信息标注为不可得。
+- **区分事实与推测**：可直接观察到的（文案、CTA、形式）为事实；受众、投放意图等反推内容明确标为推测。
+- **不编造**：无法找到素材时如实说明，不虚构广告内容或数据；缺口用占位符标注（如 `[未找到该品牌 TikTok 投放素材]`）。
+- **合规借鉴**：借鉴的是策略与创意角度，不照抄受版权/商标保护的文案与素材；提醒用户避免误导性宣传与侵权。
+- **时效性**：广告投放变化快，标注素材的观察时间，说明结论反映的是某一时点的情况。

apps/desktop/resources/bundled-skills/brand-guidelines/SKILL.md

@@ -0,0 +1,118 @@
+---
+name: 品牌规范
+description: 梳理品牌定位与调性，定义 logo 用法、主辅色、字体、图形语言与语气，输出可分发的品牌规范文档（Markdown 或单文件 HTML，含色值与用法示例）
+category: 设计与UI
+allowed-tools:
+ - Read
+ - Write
+---
+
+# 品牌规范
+
+## 目标
+
+为一个企业、产品或个人品牌产出一份**可分发、可执行的品牌规范文档（Brand Guidelines）**：把品牌的定位、调性、logo 用法、配色、字体、图形语言、语气统一成一套明确规则，让不同的人（设计、市场、外包、AI）在做官网、宣传册、PPT、社媒、邮件时都能做出**风格一致**的东西。
+
+品牌规范的价值在于**约束**：不是罗列"我们有蓝色和白色"，而是明确"主色是 #1B3A6B，用在标题和主按钮；辅色橙 #FF7A45，只做点缀，占比不超过 10%；正文永远用中性灰，不用主色"。规则越具体，一致性越强。
+
+## 工作流
+
+### 第 1 步：梳理品牌定位与调性
+
+先收敛品牌的"人格"，这是所有视觉决策的根：
+
+- **品牌是什么**：一句话定位、核心价值主张、与竞品的差异。
+- **给谁看**：目标人群、行业、To B / To C，决定专业度与温度。
+- **品牌人格**：用形容词或对立轴定位——专业⇄亲和、稳重⇄先锋、极简⇄丰富、理性⇄感性、高端⇄普惠。挑 3–5 个关键词。
+- **参考与禁忌**：欣赏哪些品牌的观感、绝对不想要的感觉。
+
+若用户已有 logo、现用色、现用字体或既有物料，用 Read 读取用户提供的相关文件（品牌简报、现有文档、色值表）作为输入，在其基础上系统化，而不是推倒重来。
+
+### 第 2 步：定义视觉与语言规范
+
+逐项定义，每一项都要给**规则 + 数值 + 该用/不该用**：
+
+**Logo 用法**
+- 主 logo、副标（横版/竖版/纯图标）各自的使用场景。
+- **安全边距（clear space）**：logo 四周留白不小于某个基准（如 logo 高度的 0.5 倍）。
+- **最小尺寸**：小于多少像素/毫米不得使用，保证清晰。
+- **禁用示范**：不得拉伸变形、不得改色、不得加阴影/描边、不得置于杂乱或低对比背景上。
+
+**配色系统**
+- **主色（Primary）**：1–2 个，给 HEX + RGB，说明用途（标题、主按钮、品牌标识）。
+- **辅助色（Secondary）**：支撑主色的邻近色/深浅变体。
+- **强调色（Accent）**：1 个，只做点缀（CTA、高亮），并规定占比上限。
+- **中性色（Neutral）**：文字、背景、分隔线用的黑白灰阶梯。
+- **语义色**（如需）：成功/警告/错误。
+- 给每个色标注**无障碍对比**建议（正文与背景对比度尽量 ≥ 4.5:1）。
+
+**字体系统（Typography）**
+- 中文主字体 + 英文主字体（如思源黑体 / Roboto），及备用（fallback）字体。
+- **字阶（type scale）**：H1/H2/H3/正文/注释的字号、字重、行高，给一套具体数值。
+- 用途规则：标题用什么字重、正文永远不用某某色等。
+
+**图形语言（Graphics）**
+- 圆角还是直角、线条粗细、图标风格（线性/面性）、插画/摄影的调性、间距节奏、常用版式栅格。
+
+**语气（Voice & Tone）**
+- 品牌怎么说话：专业 vs 亲切、是否用"你"、是否用 emoji、术语深浅。
+- 给 **Do / Don't 例句**：同一句话"品牌腔"怎么写、"不要"怎么写。
+
+### 第 3 步：配用法示例
+
+每条规则尽量配一个**正例 + 反例**，让读者一眼看懂边界。如配色给色块 + 十六进制；字体给排版样张；logo 给"正确留白"与"禁止拉伸"对照。示例是品牌规范里最被反复查阅的部分。
+
+### 第 4 步：输出可分发文档
+
+把上述内容组织成一份完整文档，用 Write 保存。两种格式按用户需要选择：
+
+- **Markdown**：便于纳入代码仓 / wiki / 协作文档，纯文本可 diff。
+- **单文件 HTML**：自包含、内联 CSS，可直接在浏览器打开演示，能用真实色块、真实字体样张把规范"演出来"，观感更接近成品。适合对外分发或给非技术同事看。
+
+若选 HTML，直接用 CSS 变量把品牌色/字体定义在 `:root`，让文档本身就是品牌的一次示范。
+
+## 输出格式
+
+文档结构建议如下：
+
+```markdown
+# <品牌名> 品牌规范 Brand Guidelines
+
+## 1. 品牌定位与调性
+- 一句话定位 / 价值主张 / 人格关键词（3–5 个）
+
+## 2. Logo 用法
+- 主/副标 · 使用场景
+- 安全边距 · 最小尺寸
+- ✅ 正确用法 / ❌ 禁用示范
+
+## 3. 配色系统
+| 角色 | 名称 | HEX | RGB | 用途 | 占比/对比建议 |
+|------|------|-----|-----|------|--------------|
+| 主色 | … | #1B3A6B | … | 标题/主按钮 | 对比≥4.5 |
+| 强调 | … | #FF7A45 | … | 仅 CTA 点缀 | ≤10% |
+| 中性 | … | #2B2B2B / #F5F7FA | … | 文字/背景 | — |
+
+## 4. 字体系统
+- 中文 / 英文主字体 + fallback
+- 字阶表：H1…正文（字号/字重/行高）
+
+## 5. 图形语言
+- 圆角 · 线条 · 图标风格 · 版式栅格
+
+## 6. 语气 Voice & Tone
+- 人格描述 + Do / Don't 例句
+
+## 7. 应用示例
+- 名片 / PPT / 社媒 / 邮件签名 的示范
+```
+
+HTML 版则把上述各节渲染为带真实色块、真实字体样张、对照示例的页面，内联所有样式，单文件可直接打开。
+
+## 边界
+
+- **基于用户素材系统化**，不凭空替品牌重定方向；有既有 logo/色值/字体时用 Read 读入并沿用。
+- **不生成 logo 图形本身**：本 skill 定义 logo 的**用法规则**，不绘制/生成 logo 图像；若无 logo，提示用户先确定标识。
+- **不复刻他人品牌**：可参考某种"风格气质"，但不得直接照搬受版权/商标保护的品牌资产（配色体系、logo）。用户举例的知名品牌风格仅作调性参考。
+- **色值与字体要可落地**：优先给可获取的字体（系统字体 / 开源字体如思源系列 / Google Fonts），避免规范无法执行。
+- 规则要**具体到可执行**——给数值、给占比、给 Do/Don't，而不是含糊的形容词堆砌。

apps/desktop/resources/bundled-skills/changelog-generator/SKILL.md

@@ -0,0 +1,131 @@
+---
+name: Changelog 生成
+description: 从 git 提交历史生成结构化 changelog 或 release notes，按 feat/fix/breaking 分类，并把技术描述改写成面向用户的语言。当用户需要生成更新日志、发布说明、版本变更记录时使用。
+category: 文档与写作
+allowed-tools:
+ - Bash
+ - Read
+ - Write
+---
+
+# Changelog 生成
+
+## 目标
+
+从项目的 git 提交历史中提取变更，生成**结构化、面向读者**的 changelog 或 release notes。核心工作是两步转换：先把散乱的 commit 归类（新功能 / 改进 / 修复 / 破坏性变更等），再把工程师视角的技术描述改写成目标读者（终端用户、集成方开发者、或应用商店审核）看得懂、关心的语言。
+
+一条 commit `fix: null check in auth middleware` 对开发者有意义，但用户想看到的是"修复了部分场景下登录失败的问题"。本 skill 就是完成这层翻译，并按版本 / 时间范围组织成规范文档。
+
+## 工作流步骤
+
+### 步骤 1：确认输入参数
+
+动手前明确以下信息，缺失的先问用户或用合理默认：
+
+- **仓库位置**：默认当前工作目录；若用户给了路径则 `cd` 到对应目录操作。
+- **范围**：三选一
+ - 版本区间：如 `v2.4.0..v2.5.0` 或 `v2.4.0..HEAD`
+ - 时间范围：如 `2024-03-01` 到 `2024-03-15`
+ - 相对范围：如"本周""最近 20 次提交"
+- **目标读者**：终端用户（弱化技术）/ 开发者集成方（保留 API 细节）/ 应用商店（简短生动、≤200 字）。读者不同，改写力度完全不同。
+- **输出格式与语言**：Markdown（默认）/ 纯文本；中文 / 英文。
+- **产品名与版本号**：用于标题。
+
+### 步骤 2：用 Bash 抓取提交历史
+
+用 `git log` 拉取范围内的提交。**不要用 `git log` 的分页交互**，加 `--no-pager` 或管道处理。推荐命令（按范围二选一）：
+
+版本区间：
+```
+git --no-pager log v2.4.0..v2.5.0 --pretty=format:'%h%x09%an%x09%ad%x09%s' --date=short
+```
+
+时间范围：
+```
+git --no-pager log --since='2024-03-01' --until='2024-03-15' --pretty=format:'%h%x09%an%x09%ad%x09%s' --date=short
+```
+
+需要正文（含 BREAKING CHANGE 说明、多行描述）时追加 `%x09%b` 或分次用 `--pretty=format:'%H%n%B%n---'`。
+
+辅助命令：
+- 列出可用 tag（确认版本区间是否存在）：`git --no-pager tag --sort=-creatordate | head -20`
+- 上一个 tag：`git describe --tags --abbrev=0`
+- 首次提交（无上一 tag 时兜底范围）：`git --no-pager log --pretty=format:'%h %ad %s' --date=short`
+- 统计文件改动辅助判断影响面：`git --no-pager log <range> --stat`
+
+若范围内无提交或 tag 不存在，明确告知用户并请其确认范围，不要静默产出空文档。
+
+### 步骤 3：解析与归类
+
+逐条解析 commit subject，优先识别 Conventional Commits 前缀，映射到用户友好的分组：
+
+| commit 前缀 | 分组 | Emoji |
+| --- | --- | --- |
+| `feat` | 新功能 | ✨ |
+| `fix` | 问题修复 | 🐛 |
+| `perf` | 性能优化 | ⚡ |
+| `refactor` / `style` / `chore` / `build` / `ci` | 内部改进（多数对用户不可见，视读者决定是否收录或合并为一句） | 🔧 |
+| `docs` | 文档 | 📝 |
+| `revert` | 回滚 | ⏪ |
+| 含 `BREAKING CHANGE` 或 `!`（如 `feat!:`） | 破坏性变更（单独置顶章节） | ⚠️ |
+
+处理原则：
+- **破坏性变更最重要**，永远放在最前，说明改了什么、为何、如何迁移。
+- 面向终端用户时，`chore`/`refactor`/`ci`/`test` 等纯工程提交通常**不进入**正文，或合并成一句"底层稳定性与性能改进"。
+- 面向开发者集成方时，API 变更、依赖升级要保留并标注。
+- 不带规范前缀的 commit：读 subject 语义自行归类；实在无法判断的归到"其他变更"。
+- 合并重复：同一功能的多次提交（`wip`、`fix typo`、`address review`）合并为一条有意义的条目，不逐条罗列。
+- 过滤噪音：`Merge branch`、纯格式化、版本号 bump 等一般剔除。
+
+### 步骤 4：面向读者改写
+
+这是最关键的一步。把每条选中的 commit 改写成读者视角：
+
+- **讲结果，不讲实现**："重构了 X 模块"→"提升了 X 的加载速度"。
+- **讲价值**：说明这个变更给用户带来什么好处或解决了什么困扰。
+- **去术语**：终端用户文档避免 `middleware`、`race condition`、`refactor` 等词；开发者文档可保留。
+- **动词开头、简洁**：每条一句话，句式统一（如统一用"新增/优化/修复"开头）。
+- **不确定语义时不编造**：若 commit 信息太简略无法判断用户可见影响，保留原意并标注 `[待确认：此项面向用户的表述]`，请用户核对，不要臆造功能。
+
+### 步骤 5：组装文档
+
+按目标格式拼装（见下）。破坏性变更置顶，其余按重要性排序（新功能 > 修复 > 改进）。
+
+## 输出格式约定
+
+**标准 changelog / release notes（Markdown）：**
+
+```
+# [产品名] [版本号] — [日期或日期范围]
+
+> [可选：一句话概述本次更新亮点]
+
+## ⚠️ 破坏性变更
+- [改了什么]。迁移方式：[如何适配]
+
+## ✨ 新功能
+- [用户视角的功能描述]
+
+## ⚡ 性能优化
+- [优化点]
+
+## 🐛 问题修复
+- [修了什么问题]
+
+## 🔧 其他改进
+- [底层改进合并描述]
+```
+
+- 遵循 [Keep a Changelog] 惯例：分组标题稳定、条目以动词开头、最新版本在最上。
+- **应用商店描述**：不用分组标题，写成 150~200 字的连贯段落，突出 1~3 个最重要的新功能，语言生动、避免技术词，末尾可加一句好评引导。
+- 空的分组不输出（没有 perf 就不放性能章节）。
+- 交付方式：短内容直接贴在对话中；用户要求成文或内容较长时，用 `Write` 保存为 `CHANGELOG.md` 或 `RELEASE_NOTES.md`。若项目已有 `CHANGELOG.md`，先 `Read` 读取，把新版本**追加到顶部**，保留历史条目，不要覆盖。
+- 每条可选择性附上 commit 短哈希便于溯源（`(a1b2c3d)`），面向终端用户时通常省略。
+
+## 边界
+
+- **只读取，不改写历史**：仅执行 `git log`、`git tag`、`git describe` 等只读命令，绝不执行 commit、push、tag、rebase 等修改仓库的操作。
+- **不编造变更**：文档内容严格来自真实 commit；无法判断的表述标注待确认，不虚构功能或数据。
+- **范围为空要报告**：区间无提交、tag 不存在、非 git 目录等情况，明确告知并请用户修正，不产出空壳文档。
+- **不做版本决策**：是否发布、版本号怎么定（semver 判断可给建议）由用户决定。
+- **敏感信息**：若 commit 信息里出现内部代号、未公开客户名、密钥等，改写时剔除或提示用户。

apps/desktop/resources/bundled-skills/competitive-ads-extractor/SKILL.md

@@ -0,0 +1,85 @@
+---
+name: 竞品广告拆解
+description: 当用户想研究竞争对手的广告与投放策略时使用。典型问法："帮我分析 X 竞品在 Facebook / 各渠道的广告"、"拆解这几个对手的广告卖点和落地页"、"看看同行都用什么钩子和 CTA"、"整理一份竞品广告对比，找可借鉴的打法"。
+category: 研究与分析
+allowed-tools:
+ - Read
+ - WebSearch
+---
+
+# 竞品广告拆解
+
+## 目标
+
+系统性拆解竞争对手的广告与落地页，把零散的广告素材转化为**结构化、可对比、能落地借鉴**的营销情报。产出不是"看到了哪些广告"，而是"对手在用什么打法、为什么有效、我方可以借鉴或差异化什么"。
+
+拆解维度贯穿从广告创意到转化路径的全链路：钩子（hook）、核心卖点、目标受众、创意角度、行动号召（CTA）、落地页设计与转化逻辑。适用场景：投放前的竞品调研、找新的创意角度、诊断自身广告为何转化差、进入新市场前摸清同行打法。
+
+## 工作流步骤
+
+### 1. 明确分析目标与范围
+
+先与用户确认这次拆解要服务什么决策，避免漫无目的地收集：
+
+- **分析目的**：找新创意角度、优化现有广告文案、研究定价与卖点、还是全面摸底一个新市场？
+- **竞品清单**：直接竞品（同品类）与间接/参照竞品（打同一人群）分别列出；如用户只给了行业，先帮其识别主要玩家。
+- **渠道范围**：Facebook/Instagram、Google、TikTok、LinkedIn、YouTube、落地页、邮件等，聚焦用户目标客群实际所在的渠道。
+- **分析维度侧重**：文案钩子、视觉创意、受众定位、卖点、优惠机制、落地页转化，明确重点，不必每维都同等深挖。
+
+把界定后的范围复述确认，作为后续拆解的锚点。
+
+### 2. 收集竞品广告与落地页素材
+
+用 WebSearch 系统性收集可公开获取的广告与营销素材：
+
+- **公开广告库**：Facebook/Meta Ad Library、TikTok Creative Center、Google Ads Transparency 等平台会公开展示投放中的广告，是一手素材的主要来源；检索时定位到具体品牌/主页。
+- **落地页**：从广告指向的落地页或官网营销页收集，关注首屏主张、卖点排布、社会证明、CTA、定价与优惠。
+- **多渠道多角度**：换关键词（品牌名、产品名、slogan、品类词）多轮检索；覆盖官方投放、媒体报道、用户讨论、营销分析文章等不同来源。
+- **记录元信息**：为每条素材记下来源、渠道、大致投放时间、广告形式（图文/视频/轮播）、可见的互动或投放持续情况，作为"是否是主推/长青广告"的旁证。
+
+注意：只收集平台公开展示的广告与营销信息；无法获取的（如真实投放预算、精确受众设置、内部数据）不臆测，标注为不可得。
+
+### 3. 结构化提取
+
+对每一条（或每一组）广告，按统一维度拆解，保证可横向对比：
+
+- **钩子（Hook）**：开头 3 秒/首行如何抓注意力——痛点、提问、反常识、数字、身份认同、好奇缺口等。
+- **核心卖点**：主打的价值主张是什么（省钱/省时/效果/身份/风险规避），一条广告的主卖点通常只有一个。
+- **目标受众**：从文案口吻、场景、痛点反推其瞄准的人群画像（身份、阶段、痛点、动机）。
+- **创意角度（Angle）**：切入同一卖点的叙事框架——恐惧诉求、before/after、用户证言、权威背书、对比竞品、稀缺/紧迫等。
+- **CTA**：行动号召的措辞与强度（立即购买 / 免费试用 / 领取优惠 / 了解更多），以及配套的优惠或紧迫感设计。
+- **创意形式**：图文/短视频/UGC 风格/达人口播等表现形式与视觉调性。
+- **落地页衔接**：广告承诺与落地页首屏是否一致，落地页如何承接并推进转化（表单/购买/预约），转化路径长短。
+
+对拿不准的推断（如受众、投放意图）标注为"推测"，与可直接观察到的事实区分开。
+
+### 4. 对比分析与洞察
+
+把结构化提取的结果汇总成对比，从中提炼可行动的洞察：
+
+- **横向对比**：把各竞品放在同一张表里，对比钩子类型、主卖点、角度、CTA、优惠机制，一眼看出各家打法异同。
+- **模式识别**：找出反复出现的共性打法（多家都在用的钩子/角度/卖点），这通常是被市场验证过的有效套路。
+- **空白与差异化**：识别无人主打的卖点、无人覆盖的人群、无人用的角度——这是差异化机会。
+- **可借鉴 vs 需规避**：明确哪些打法值得测试借鉴（并说明如何适配到自身产品），哪些是踩坑或不适合自身定位的。
+- **落地建议**：给出具体、可执行的下一步，如"可测试的 3 个新钩子""建议补强的落地页首屏主张""值得抢占的差异化卖点"。
+
+洞察要落到"我方能做什么"，而非停留在描述对手。
+
+## 输出格式
+
+默认交付**对比表 + 洞察小结**两部分：
+
+- **竞品广告对比表**：每行一个竞品（或一条代表性广告），列为 渠道 / 钩子 / 核心卖点 / 目标受众 / 创意角度 / CTA / 落地页要点 / 备注（来源与投放线索）。
+- **模式与洞察**：分点总结共性打法、市场空白、差异化机会。
+- **可借鉴清单**：按优先级列出可测试的具体动作，每条说明借鉴点与适配方式。
+- **来源附录**：列出所收集素材的来源/链接与观察时间，保证可追溯。
+
+如用户需要，可对单个重点竞品做深度拆解（逐条广告 + 落地页），或输出为可复用的分析模板。
+
+## 边界与注意事项
+
+- **只用公开信息**：仅分析平台公开展示的广告与营销页；不获取、不臆测竞品的内部数据（真实预算、精确受众、后台配置、转化率），此类信息标注为不可得。
+- **区分事实与推测**：可直接观察到的（文案、CTA、形式）为事实；受众、投放意图等反推内容明确标为推测。
+- **不编造**：无法找到素材时如实说明，不虚构广告内容或数据；缺口用占位符标注（如 `[未找到该品牌 TikTok 投放素材]`）。
+- **合规借鉴**：借鉴的是策略与创意角度，不照抄受版权/商标保护的文案与素材；提醒用户避免误导性宣传与侵权。
+- **时效性**：广告投放变化快，标注素材的观察时间，说明结论反映的是某一时点的情况。

apps/desktop/resources/bundled-skills/brand-guidelines/SKILL.md

@@ -0,0 +1,118 @@
+---
+name: 品牌规范
+description: 梳理品牌定位与调性，定义 logo 用法、主辅色、字体、图形语言与语气，输出可分发的品牌规范文档（Markdown 或单文件 HTML，含色值与用法示例）
+category: 设计与UI
+allowed-tools:
+ - Read
+ - Write
+---
+
+# 品牌规范
+
+## 目标
+
+为一个企业、产品或个人品牌产出一份**可分发、可执行的品牌规范文档（Brand Guidelines）**：把品牌的定位、调性、logo 用法、配色、字体、图形语言、语气统一成一套明确规则，让不同的人（设计、市场、外包、AI）在做官网、宣传册、PPT、社媒、邮件时都能做出**风格一致**的东西。
+
+品牌规范的价值在于**约束**：不是罗列"我们有蓝色和白色"，而是明确"主色是 #1B3A6B，用在标题和主按钮；辅色橙 #FF7A45，只做点缀，占比不超过 10%；正文永远用中性灰，不用主色"。规则越具体，一致性越强。
+
+## 工作流
+
+### 第 1 步：梳理品牌定位与调性
+
+先收敛品牌的"人格"，这是所有视觉决策的根：
+
+- **品牌是什么**：一句话定位、核心价值主张、与竞品的差异。
+- **给谁看**：目标人群、行业、To B / To C，决定专业度与温度。
+- **品牌人格**：用形容词或对立轴定位——专业⇄亲和、稳重⇄先锋、极简⇄丰富、理性⇄感性、高端⇄普惠。挑 3–5 个关键词。
+- **参考与禁忌**：欣赏哪些品牌的观感、绝对不想要的感觉。
+
+若用户已有 logo、现用色、现用字体或既有物料，用 Read 读取用户提供的相关文件（品牌简报、现有文档、色值表）作为输入，在其基础上系统化，而不是推倒重来。
+
+### 第 2 步：定义视觉与语言规范
+
+逐项定义，每一项都要给**规则 + 数值 + 该用/不该用**：
+
+**Logo 用法**
+- 主 logo、副标（横版/竖版/纯图标）各自的使用场景。
+- **安全边距（clear space）**：logo 四周留白不小于某个基准（如 logo 高度的 0.5 倍）。
+- **最小尺寸**：小于多少像素/毫米不得使用，保证清晰。
+- **禁用示范**：不得拉伸变形、不得改色、不得加阴影/描边、不得置于杂乱或低对比背景上。
+
+**配色系统**
+- **主色（Primary）**：1–2 个，给 HEX + RGB，说明用途（标题、主按钮、品牌标识）。
+- **辅助色（Secondary）**：支撑主色的邻近色/深浅变体。
+- **强调色（Accent）**：1 个，只做点缀（CTA、高亮），并规定占比上限。
+- **中性色（Neutral）**：文字、背景、分隔线用的黑白灰阶梯。
+- **语义色**（如需）：成功/警告/错误。
+- 给每个色标注**无障碍对比**建议（正文与背景对比度尽量 ≥ 4.5:1）。
+
+**字体系统（Typography）**
+- 中文主字体 + 英文主字体（如思源黑体 / Roboto），及备用（fallback）字体。
+- **字阶（type scale）**：H1/H2/H3/正文/注释的字号、字重、行高，给一套具体数值。
+- 用途规则：标题用什么字重、正文永远不用某某色等。
+
+**图形语言（Graphics）**
+- 圆角还是直角、线条粗细、图标风格（线性/面性）、插画/摄影的调性、间距节奏、常用版式栅格。
+
+**语气（Voice & Tone）**
+- 品牌怎么说话：专业 vs 亲切、是否用"你"、是否用 emoji、术语深浅。
+- 给 **Do / Don't 例句**：同一句话"品牌腔"怎么写、"不要"怎么写。
+
+### 第 3 步：配用法示例
+
+每条规则尽量配一个**正例 + 反例**，让读者一眼看懂边界。如配色给色块 + 十六进制；字体给排版样张；logo 给"正确留白"与"禁止拉伸"对照。示例是品牌规范里最被反复查阅的部分。
+
+### 第 4 步：输出可分发文档
+
+把上述内容组织成一份完整文档，用 Write 保存。两种格式按用户需要选择：
+
+- **Markdown**：便于纳入代码仓 / wiki / 协作文档，纯文本可 diff。
+- **单文件 HTML**：自包含、内联 CSS，可直接在浏览器打开演示，能用真实色块、真实字体样张把规范"演出来"，观感更接近成品。适合对外分发或给非技术同事看。
+
+若选 HTML，直接用 CSS 变量把品牌色/字体定义在 `:root`，让文档本身就是品牌的一次示范。
+
+## 输出格式
+
+文档结构建议如下：
+
+```markdown
+# <品牌名> 品牌规范 Brand Guidelines
+
+## 1. 品牌定位与调性
+- 一句话定位 / 价值主张 / 人格关键词（3–5 个）
+
+## 2. Logo 用法
+- 主/副标 · 使用场景
+- 安全边距 · 最小尺寸
+- ✅ 正确用法 / ❌ 禁用示范
+
+## 3. 配色系统
+| 角色 | 名称 | HEX | RGB | 用途 | 占比/对比建议 |
+|------|------|-----|-----|------|--------------|
+| 主色 | … | #1B3A6B | … | 标题/主按钮 | 对比≥4.5 |
+| 强调 | … | #FF7A45 | … | 仅 CTA 点缀 | ≤10% |
+| 中性 | … | #2B2B2B / #F5F7FA | … | 文字/背景 | — |
+
+## 4. 字体系统
+- 中文 / 英文主字体 + fallback
+- 字阶表：H1…正文（字号/字重/行高）
+
+## 5. 图形语言
+- 圆角 · 线条 · 图标风格 · 版式栅格
+
+## 6. 语气 Voice & Tone
+- 人格描述 + Do / Don't 例句
+
+## 7. 应用示例
+- 名片 / PPT / 社媒 / 邮件签名 的示范
+```
+
+HTML 版则把上述各节渲染为带真实色块、真实字体样张、对照示例的页面，内联所有样式，单文件可直接打开。
+
+## 边界
+
+- **基于用户素材系统化**，不凭空替品牌重定方向；有既有 logo/色值/字体时用 Read 读入并沿用。
+- **不生成 logo 图形本身**：本 skill 定义 logo 的**用法规则**，不绘制/生成 logo 图像；若无 logo，提示用户先确定标识。
+- **不复刻他人品牌**：可参考某种"风格气质"，但不得直接照搬受版权/商标保护的品牌资产（配色体系、logo）。用户举例的知名品牌风格仅作调性参考。
+- **色值与字体要可落地**：优先给可获取的字体（系统字体 / 开源字体如思源系列 / Google Fonts），避免规范无法执行。
+- 规则要**具体到可执行**——给数值、给占比、给 Do/Don't，而不是含糊的形容词堆砌。

apps/desktop/resources/bundled-skills/changelog-generator/SKILL.md

@@ -0,0 +1,131 @@
+---
+name: Changelog 生成
+description: 从 git 提交历史生成结构化 changelog 或 release notes，按 feat/fix/breaking 分类，并把技术描述改写成面向用户的语言。当用户需要生成更新日志、发布说明、版本变更记录时使用。
+category: 文档与写作
+allowed-tools:
+ - Bash
+ - Read
+ - Write
+---
+
+# Changelog 生成
+
+## 目标
+
+从项目的 git 提交历史中提取变更，生成**结构化、面向读者**的 changelog 或 release notes。核心工作是两步转换：先把散乱的 commit 归类（新功能 / 改进 / 修复 / 破坏性变更等），再把工程师视角的技术描述改写成目标读者（终端用户、集成方开发者、或应用商店审核）看得懂、关心的语言。
+
+一条 commit `fix: null check in auth middleware` 对开发者有意义，但用户想看到的是"修复了部分场景下登录失败的问题"。本 skill 就是完成这层翻译，并按版本 / 时间范围组织成规范文档。
+
+## 工作流步骤
+
+### 步骤 1：确认输入参数
+
+动手前明确以下信息，缺失的先问用户或用合理默认：
+
+- **仓库位置**：默认当前工作目录；若用户给了路径则 `cd` 到对应目录操作。
+- **范围**：三选一
+ - 版本区间：如 `v2.4.0..v2.5.0` 或 `v2.4.0..HEAD`
+ - 时间范围：如 `2024-03-01` 到 `2024-03-15`
+ - 相对范围：如"本周""最近 20 次提交"
+- **目标读者**：终端用户（弱化技术）/ 开发者集成方（保留 API 细节）/ 应用商店（简短生动、≤200 字）。读者不同，改写力度完全不同。
+- **输出格式与语言**：Markdown（默认）/ 纯文本；中文 / 英文。
+- **产品名与版本号**：用于标题。
+
+### 步骤 2：用 Bash 抓取提交历史
+
+用 `git log` 拉取范围内的提交。**不要用 `git log` 的分页交互**，加 `--no-pager` 或管道处理。推荐命令（按范围二选一）：
+
+版本区间：
+```
+git --no-pager log v2.4.0..v2.5.0 --pretty=format:'%h%x09%an%x09%ad%x09%s' --date=short
+```
+
+时间范围：
+```
+git --no-pager log --since='2024-03-01' --until='2024-03-15' --pretty=format:'%h%x09%an%x09%ad%x09%s' --date=short
+```
+
+需要正文（含 BREAKING CHANGE 说明、多行描述）时追加 `%x09%b` 或分次用 `--pretty=format:'%H%n%B%n---'`。
+
+辅助命令：
+- 列出可用 tag（确认版本区间是否存在）：`git --no-pager tag --sort=-creatordate | head -20`
+- 上一个 tag：`git describe --tags --abbrev=0`
+- 首次提交（无上一 tag 时兜底范围）：`git --no-pager log --pretty=format:'%h %ad %s' --date=short`
+- 统计文件改动辅助判断影响面：`git --no-pager log <range> --stat`
+
+若范围内无提交或 tag 不存在，明确告知用户并请其确认范围，不要静默产出空文档。
+
+### 步骤 3：解析与归类
+
+逐条解析 commit subject，优先识别 Conventional Commits 前缀，映射到用户友好的分组：
+
+| commit 前缀 | 分组 | Emoji |
+| --- | --- | --- |
+| `feat` | 新功能 | ✨ |
+| `fix` | 问题修复 | 🐛 |
+| `perf` | 性能优化 | ⚡ |
+| `refactor` / `style` / `chore` / `build` / `ci` | 内部改进（多数对用户不可见，视读者决定是否收录或合并为一句） | 🔧 |
+| `docs` | 文档 | 📝 |
+| `revert` | 回滚 | ⏪ |
+| 含 `BREAKING CHANGE` 或 `!`（如 `feat!:`） | 破坏性变更（单独置顶章节） | ⚠️ |
+
+处理原则：
+- **破坏性变更最重要**，永远放在最前，说明改了什么、为何、如何迁移。
+- 面向终端用户时，`chore`/`refactor`/`ci`/`test` 等纯工程提交通常**不进入**正文，或合并成一句"底层稳定性与性能改进"。
+- 面向开发者集成方时，API 变更、依赖升级要保留并标注。
+- 不带规范前缀的 commit：读 subject 语义自行归类；实在无法判断的归到"其他变更"。
+- 合并重复：同一功能的多次提交（`wip`、`fix typo`、`address review`）合并为一条有意义的条目，不逐条罗列。
+- 过滤噪音：`Merge branch`、纯格式化、版本号 bump 等一般剔除。
+
+### 步骤 4：面向读者改写
+
+这是最关键的一步。把每条选中的 commit 改写成读者视角：
+
+- **讲结果，不讲实现**："重构了 X 模块"→"提升了 X 的加载速度"。
+- **讲价值**：说明这个变更给用户带来什么好处或解决了什么困扰。
+- **去术语**：终端用户文档避免 `middleware`、`race condition`、`refactor` 等词；开发者文档可保留。
+- **动词开头、简洁**：每条一句话，句式统一（如统一用"新增/优化/修复"开头）。
+- **不确定语义时不编造**：若 commit 信息太简略无法判断用户可见影响，保留原意并标注 `[待确认：此项面向用户的表述]`，请用户核对，不要臆造功能。
+
+### 步骤 5：组装文档
+
+按目标格式拼装（见下）。破坏性变更置顶，其余按重要性排序（新功能 > 修复 > 改进）。
+
+## 输出格式约定
+
+**标准 changelog / release notes（Markdown）：**
+
+```
+# [产品名] [版本号] — [日期或日期范围]
+
+> [可选：一句话概述本次更新亮点]
+
+## ⚠️ 破坏性变更
+- [改了什么]。迁移方式：[如何适配]
+
+## ✨ 新功能
+- [用户视角的功能描述]
+
+## ⚡ 性能优化
+- [优化点]
+
+## 🐛 问题修复
+- [修了什么问题]
+
+## 🔧 其他改进
+- [底层改进合并描述]
+```
+
+- 遵循 [Keep a Changelog] 惯例：分组标题稳定、条目以动词开头、最新版本在最上。
+- **应用商店描述**：不用分组标题，写成 150~200 字的连贯段落，突出 1~3 个最重要的新功能，语言生动、避免技术词，末尾可加一句好评引导。
+- 空的分组不输出（没有 perf 就不放性能章节）。
+- 交付方式：短内容直接贴在对话中；用户要求成文或内容较长时，用 `Write` 保存为 `CHANGELOG.md` 或 `RELEASE_NOTES.md`。若项目已有 `CHANGELOG.md`，先 `Read` 读取，把新版本**追加到顶部**，保留历史条目，不要覆盖。
+- 每条可选择性附上 commit 短哈希便于溯源（`(a1b2c3d)`），面向终端用户时通常省略。
+
+## 边界
+
+- **只读取，不改写历史**：仅执行 `git log`、`git tag`、`git describe` 等只读命令，绝不执行 commit、push、tag、rebase 等修改仓库的操作。
+- **不编造变更**：文档内容严格来自真实 commit；无法判断的表述标注待确认，不虚构功能或数据。
+- **范围为空要报告**：区间无提交、tag 不存在、非 git 目录等情况，明确告知并请用户修正，不产出空壳文档。
+- **不做版本决策**：是否发布、版本号怎么定（semver 判断可给建议）由用户决定。
+- **敏感信息**：若 commit 信息里出现内部代号、未公开客户名、密钥等，改写时剔除或提示用户。

apps/desktop/resources/bundled-skills/competitive-ads-extractor/SKILL.md

@@ -0,0 +1,85 @@
+---
+name: 竞品广告拆解
+description: 当用户想研究竞争对手的广告与投放策略时使用。典型问法："帮我分析 X 竞品在 Facebook / 各渠道的广告"、"拆解这几个对手的广告卖点和落地页"、"看看同行都用什么钩子和 CTA"、"整理一份竞品广告对比，找可借鉴的打法"。
+category: 研究与分析
+allowed-tools:
+ - Read
+ - WebSearch
+---
+
+# 竞品广告拆解
+
+## 目标
+
+系统性拆解竞争对手的广告与落地页，把零散的广告素材转化为**结构化、可对比、能落地借鉴**的营销情报。产出不是"看到了哪些广告"，而是"对手在用什么打法、为什么有效、我方可以借鉴或差异化什么"。
+
+拆解维度贯穿从广告创意到转化路径的全链路：钩子（hook）、核心卖点、目标受众、创意角度、行动号召（CTA）、落地页设计与转化逻辑。适用场景：投放前的竞品调研、找新的创意角度、诊断自身广告为何转化差、进入新市场前摸清同行打法。
+
+## 工作流步骤
+
+### 1. 明确分析目标与范围
+
+先与用户确认这次拆解要服务什么决策，避免漫无目的地收集：
+
+- **分析目的**：找新创意角度、优化现有广告文案、研究定价与卖点、还是全面摸底一个新市场？
+- **竞品清单**：直接竞品（同品类）与间接/参照竞品（打同一人群）分别列出；如用户只给了行业，先帮其识别主要玩家。
+- **渠道范围**：Facebook/Instagram、Google、TikTok、LinkedIn、YouTube、落地页、邮件等，聚焦用户目标客群实际所在的渠道。
+- **分析维度侧重**：文案钩子、视觉创意、受众定位、卖点、优惠机制、落地页转化，明确重点，不必每维都同等深挖。
+
+把界定后的范围复述确认，作为后续拆解的锚点。
+
+### 2. 收集竞品广告与落地页素材
+
+用 WebSearch 系统性收集可公开获取的广告与营销素材：
+
+- **公开广告库**：Facebook/Meta Ad Library、TikTok Creative Center、Google Ads Transparency 等平台会公开展示投放中的广告，是一手素材的主要来源；检索时定位到具体品牌/主页。
+- **落地页**：从广告指向的落地页或官网营销页收集，关注首屏主张、卖点排布、社会证明、CTA、定价与优惠。
+- **多渠道多角度**：换关键词（品牌名、产品名、slogan、品类词）多轮检索；覆盖官方投放、媒体报道、用户讨论、营销分析文章等不同来源。
+- **记录元信息**：为每条素材记下来源、渠道、大致投放时间、广告形式（图文/视频/轮播）、可见的互动或投放持续情况，作为"是否是主推/长青广告"的旁证。
+
+注意：只收集平台公开展示的广告与营销信息；无法获取的（如真实投放预算、精确受众设置、内部数据）不臆测，标注为不可得。
+
+### 3. 结构化提取
+
+对每一条（或每一组）广告，按统一维度拆解，保证可横向对比：
+
+- **钩子（Hook）**：开头 3 秒/首行如何抓注意力——痛点、提问、反常识、数字、身份认同、好奇缺口等。
+- **核心卖点**：主打的价值主张是什么（省钱/省时/效果/身份/风险规避），一条广告的主卖点通常只有一个。
+- **目标受众**：从文案口吻、场景、痛点反推其瞄准的人群画像（身份、阶段、痛点、动机）。
+- **创意角度（Angle）**：切入同一卖点的叙事框架——恐惧诉求、before/after、用户证言、权威背书、对比竞品、稀缺/紧迫等。
+- **CTA**：行动号召的措辞与强度（立即购买 / 免费试用 / 领取优惠 / 了解更多），以及配套的优惠或紧迫感设计。
+- **创意形式**：图文/短视频/UGC 风格/达人口播等表现形式与视觉调性。
+- **落地页衔接**：广告承诺与落地页首屏是否一致，落地页如何承接并推进转化（表单/购买/预约），转化路径长短。
+
+对拿不准的推断（如受众、投放意图）标注为"推测"，与可直接观察到的事实区分开。
+
+### 4. 对比分析与洞察
+
+把结构化提取的结果汇总成对比，从中提炼可行动的洞察：
+
+- **横向对比**：把各竞品放在同一张表里，对比钩子类型、主卖点、角度、CTA、优惠机制，一眼看出各家打法异同。
+- **模式识别**：找出反复出现的共性打法（多家都在用的钩子/角度/卖点），这通常是被市场验证过的有效套路。
+- **空白与差异化**：识别无人主打的卖点、无人覆盖的人群、无人用的角度——这是差异化机会。
+- **可借鉴 vs 需规避**：明确哪些打法值得测试借鉴（并说明如何适配到自身产品），哪些是踩坑或不适合自身定位的。
+- **落地建议**：给出具体、可执行的下一步，如"可测试的 3 个新钩子""建议补强的落地页首屏主张""值得抢占的差异化卖点"。
+
+洞察要落到"我方能做什么"，而非停留在描述对手。
+
+## 输出格式
+
+默认交付**对比表 + 洞察小结**两部分：
+
+- **竞品广告对比表**：每行一个竞品（或一条代表性广告），列为 渠道 / 钩子 / 核心卖点 / 目标受众 / 创意角度 / CTA / 落地页要点 / 备注（来源与投放线索）。
+- **模式与洞察**：分点总结共性打法、市场空白、差异化机会。
+- **可借鉴清单**：按优先级列出可测试的具体动作，每条说明借鉴点与适配方式。
+- **来源附录**：列出所收集素材的来源/链接与观察时间，保证可追溯。
+
+如用户需要，可对单个重点竞品做深度拆解（逐条广告 + 落地页），或输出为可复用的分析模板。
+
+## 边界与注意事项
+
+- **只用公开信息**：仅分析平台公开展示的广告与营销页；不获取、不臆测竞品的内部数据（真实预算、精确受众、后台配置、转化率），此类信息标注为不可得。
+- **区分事实与推测**：可直接观察到的（文案、CTA、形式）为事实；受众、投放意图等反推内容明确标为推测。
+- **不编造**：无法找到素材时如实说明，不虚构广告内容或数据；缺口用占位符标注（如 `[未找到该品牌 TikTok 投放素材]`）。
+- **合规借鉴**：借鉴的是策略与创意角度，不照抄受版权/商标保护的文案与素材；提醒用户避免误导性宣传与侵权。
+- **时效性**：广告投放变化快，标注素材的观察时间，说明结论反映的是某一时点的情况。

apps/desktop/resources/bundled-skills/brand-guidelines/SKILL.md

@@ -0,0 +1,118 @@
+---
+name: 品牌规范
+description: 梳理品牌定位与调性，定义 logo 用法、主辅色、字体、图形语言与语气，输出可分发的品牌规范文档（Markdown 或单文件 HTML，含色值与用法示例）
+category: 设计与UI
+allowed-tools:
+ - Read
+ - Write
+---
+
+# 品牌规范
+
+## 目标
+
+为一个企业、产品或个人品牌产出一份**可分发、可执行的品牌规范文档（Brand Guidelines）**：把品牌的定位、调性、logo 用法、配色、字体、图形语言、语气统一成一套明确规则，让不同的人（设计、市场、外包、AI）在做官网、宣传册、PPT、社媒、邮件时都能做出**风格一致**的东西。
+
+品牌规范的价值在于**约束**：不是罗列"我们有蓝色和白色"，而是明确"主色是 #1B3A6B，用在标题和主按钮；辅色橙 #FF7A45，只做点缀，占比不超过 10%；正文永远用中性灰，不用主色"。规则越具体，一致性越强。
+
+## 工作流
+
+### 第 1 步：梳理品牌定位与调性
+
+先收敛品牌的"人格"，这是所有视觉决策的根：
+
+- **品牌是什么**：一句话定位、核心价值主张、与竞品的差异。
+- **给谁看**：目标人群、行业、To B / To C，决定专业度与温度。
+- **品牌人格**：用形容词或对立轴定位——专业⇄亲和、稳重⇄先锋、极简⇄丰富、理性⇄感性、高端⇄普惠。挑 3–5 个关键词。
+- **参考与禁忌**：欣赏哪些品牌的观感、绝对不想要的感觉。
+
+若用户已有 logo、现用色、现用字体或既有物料，用 Read 读取用户提供的相关文件（品牌简报、现有文档、色值表）作为输入，在其基础上系统化，而不是推倒重来。
+
+### 第 2 步：定义视觉与语言规范
+
+逐项定义，每一项都要给**规则 + 数值 + 该用/不该用**：
+
+**Logo 用法**
+- 主 logo、副标（横版/竖版/纯图标）各自的使用场景。
+- **安全边距（clear space）**：logo 四周留白不小于某个基准（如 logo 高度的 0.5 倍）。
+- **最小尺寸**：小于多少像素/毫米不得使用，保证清晰。
+- **禁用示范**：不得拉伸变形、不得改色、不得加阴影/描边、不得置于杂乱或低对比背景上。
+
+**配色系统**
+- **主色（Primary）**：1–2 个，给 HEX + RGB，说明用途（标题、主按钮、品牌标识）。
+- **辅助色（Secondary）**：支撑主色的邻近色/深浅变体。
+- **强调色（Accent）**：1 个，只做点缀（CTA、高亮），并规定占比上限。
+- **中性色（Neutral）**：文字、背景、分隔线用的黑白灰阶梯。
+- **语义色**（如需）：成功/警告/错误。
+- 给每个色标注**无障碍对比**建议（正文与背景对比度尽量 ≥ 4.5:1）。
+
+**字体系统（Typography）**
+- 中文主字体 + 英文主字体（如思源黑体 / Roboto），及备用（fallback）字体。
+- **字阶（type scale）**：H1/H2/H3/正文/注释的字号、字重、行高，给一套具体数值。
+- 用途规则：标题用什么字重、正文永远不用某某色等。
+
+**图形语言（Graphics）**
+- 圆角还是直角、线条粗细、图标风格（线性/面性）、插画/摄影的调性、间距节奏、常用版式栅格。
+
+**语气（Voice & Tone）**
+- 品牌怎么说话：专业 vs 亲切、是否用"你"、是否用 emoji、术语深浅。
+- 给 **Do / Don't 例句**：同一句话"品牌腔"怎么写、"不要"怎么写。
+
+### 第 3 步：配用法示例
+
+每条规则尽量配一个**正例 + 反例**，让读者一眼看懂边界。如配色给色块 + 十六进制；字体给排版样张；logo 给"正确留白"与"禁止拉伸"对照。示例是品牌规范里最被反复查阅的部分。
+
+### 第 4 步：输出可分发文档
+
+把上述内容组织成一份完整文档，用 Write 保存。两种格式按用户需要选择：
+
+- **Markdown**：便于纳入代码仓 / wiki / 协作文档，纯文本可 diff。
+- **单文件 HTML**：自包含、内联 CSS，可直接在浏览器打开演示，能用真实色块、真实字体样张把规范"演出来"，观感更接近成品。适合对外分发或给非技术同事看。
+
+若选 HTML，直接用 CSS 变量把品牌色/字体定义在 `:root`，让文档本身就是品牌的一次示范。
+
+## 输出格式
+
+文档结构建议如下：
+
+```markdown
+# <品牌名> 品牌规范 Brand Guidelines
+
+## 1. 品牌定位与调性
+- 一句话定位 / 价值主张 / 人格关键词（3–5 个）
+
+## 2. Logo 用法
+- 主/副标 · 使用场景
+- 安全边距 · 最小尺寸
+- ✅ 正确用法 / ❌ 禁用示范
+
+## 3. 配色系统
+| 角色 | 名称 | HEX | RGB | 用途 | 占比/对比建议 |
+|------|------|-----|-----|------|--------------|
+| 主色 | … | #1B3A6B | … | 标题/主按钮 | 对比≥4.5 |
+| 强调 | … | #FF7A45 | … | 仅 CTA 点缀 | ≤10% |
+| 中性 | … | #2B2B2B / #F5F7FA | … | 文字/背景 | — |
+
+## 4. 字体系统
+- 中文 / 英文主字体 + fallback
+- 字阶表：H1…正文（字号/字重/行高）
+
+## 5. 图形语言
+- 圆角 · 线条 · 图标风格 · 版式栅格
+
+## 6. 语气 Voice & Tone
+- 人格描述 + Do / Don't 例句
+
+## 7. 应用示例
+- 名片 / PPT / 社媒 / 邮件签名 的示范
+```
+
+HTML 版则把上述各节渲染为带真实色块、真实字体样张、对照示例的页面，内联所有样式，单文件可直接打开。
+
+## 边界
+
+- **基于用户素材系统化**，不凭空替品牌重定方向；有既有 logo/色值/字体时用 Read 读入并沿用。
+- **不生成 logo 图形本身**：本 skill 定义 logo 的**用法规则**，不绘制/生成 logo 图像；若无 logo，提示用户先确定标识。
+- **不复刻他人品牌**：可参考某种"风格气质"，但不得直接照搬受版权/商标保护的品牌资产（配色体系、logo）。用户举例的知名品牌风格仅作调性参考。
+- **色值与字体要可落地**：优先给可获取的字体（系统字体 / 开源字体如思源系列 / Google Fonts），避免规范无法执行。
+- 规则要**具体到可执行**——给数值、给占比、给 Do/Don't，而不是含糊的形容词堆砌。

apps/desktop/resources/bundled-skills/changelog-generator/SKILL.md

@@ -0,0 +1,131 @@
+---
+name: Changelog 生成
+description: 从 git 提交历史生成结构化 changelog 或 release notes，按 feat/fix/breaking 分类，并把技术描述改写成面向用户的语言。当用户需要生成更新日志、发布说明、版本变更记录时使用。
+category: 文档与写作
+allowed-tools:
+ - Bash
+ - Read
+ - Write
+---
+
+# Changelog 生成
+
+## 目标
+
+从项目的 git 提交历史中提取变更，生成**结构化、面向读者**的 changelog 或 release notes。核心工作是两步转换：先把散乱的 commit 归类（新功能 / 改进 / 修复 / 破坏性变更等），再把工程师视角的技术描述改写成目标读者（终端用户、集成方开发者、或应用商店审核）看得懂、关心的语言。
+
+一条 commit `fix: null check in auth middleware` 对开发者有意义，但用户想看到的是"修复了部分场景下登录失败的问题"。本 skill 就是完成这层翻译，并按版本 / 时间范围组织成规范文档。
+
+## 工作流步骤
+
+### 步骤 1：确认输入参数
+
+动手前明确以下信息，缺失的先问用户或用合理默认：
+
+- **仓库位置**：默认当前工作目录；若用户给了路径则 `cd` 到对应目录操作。
+- **范围**：三选一
+ - 版本区间：如 `v2.4.0..v2.5.0` 或 `v2.4.0..HEAD`
+ - 时间范围：如 `2024-03-01` 到 `2024-03-15`
+ - 相对范围：如"本周""最近 20 次提交"
+- **目标读者**：终端用户（弱化技术）/ 开发者集成方（保留 API 细节）/ 应用商店（简短生动、≤200 字）。读者不同，改写力度完全不同。
+- **输出格式与语言**：Markdown（默认）/ 纯文本；中文 / 英文。
+- **产品名与版本号**：用于标题。
+
+### 步骤 2：用 Bash 抓取提交历史
+
+用 `git log` 拉取范围内的提交。**不要用 `git log` 的分页交互**，加 `--no-pager` 或管道处理。推荐命令（按范围二选一）：
+
+版本区间：
+```
+git --no-pager log v2.4.0..v2.5.0 --pretty=format:'%h%x09%an%x09%ad%x09%s' --date=short
+```
+
+时间范围：
+```
+git --no-pager log --since='2024-03-01' --until='2024-03-15' --pretty=format:'%h%x09%an%x09%ad%x09%s' --date=short
+```
+
+需要正文（含 BREAKING CHANGE 说明、多行描述）时追加 `%x09%b` 或分次用 `--pretty=format:'%H%n%B%n---'`。
+
+辅助命令：
+- 列出可用 tag（确认版本区间是否存在）：`git --no-pager tag --sort=-creatordate | head -20`
+- 上一个 tag：`git describe --tags --abbrev=0`
+- 首次提交（无上一 tag 时兜底范围）：`git --no-pager log --pretty=format:'%h %ad %s' --date=short`
+- 统计文件改动辅助判断影响面：`git --no-pager log <range> --stat`
+
+若范围内无提交或 tag 不存在，明确告知用户并请其确认范围，不要静默产出空文档。
+
+### 步骤 3：解析与归类
+
+逐条解析 commit subject，优先识别 Conventional Commits 前缀，映射到用户友好的分组：
+
+| commit 前缀 | 分组 | Emoji |
+| --- | --- | --- |
+| `feat` | 新功能 | ✨ |
+| `fix` | 问题修复 | 🐛 |
+| `perf` | 性能优化 | ⚡ |
+| `refactor` / `style` / `chore` / `build` / `ci` | 内部改进（多数对用户不可见，视读者决定是否收录或合并为一句） | 🔧 |
+| `docs` | 文档 | 📝 |
+| `revert` | 回滚 | ⏪ |
+| 含 `BREAKING CHANGE` 或 `!`（如 `feat!:`） | 破坏性变更（单独置顶章节） | ⚠️ |
+
+处理原则：
+- **破坏性变更最重要**，永远放在最前，说明改了什么、为何、如何迁移。
+- 面向终端用户时，`chore`/`refactor`/`ci`/`test` 等纯工程提交通常**不进入**正文，或合并成一句"底层稳定性与性能改进"。
+- 面向开发者集成方时，API 变更、依赖升级要保留并标注。
+- 不带规范前缀的 commit：读 subject 语义自行归类；实在无法判断的归到"其他变更"。
+- 合并重复：同一功能的多次提交（`wip`、`fix typo`、`address review`）合并为一条有意义的条目，不逐条罗列。
+- 过滤噪音：`Merge branch`、纯格式化、版本号 bump 等一般剔除。
+
+### 步骤 4：面向读者改写
+
+这是最关键的一步。把每条选中的 commit 改写成读者视角：
+
+- **讲结果，不讲实现**："重构了 X 模块"→"提升了 X 的加载速度"。
+- **讲价值**：说明这个变更给用户带来什么好处或解决了什么困扰。
+- **去术语**：终端用户文档避免 `middleware`、`race condition`、`refactor` 等词；开发者文档可保留。
+- **动词开头、简洁**：每条一句话，句式统一（如统一用"新增/优化/修复"开头）。
+- **不确定语义时不编造**：若 commit 信息太简略无法判断用户可见影响，保留原意并标注 `[待确认：此项面向用户的表述]`，请用户核对，不要臆造功能。
+
+### 步骤 5：组装文档
+
+按目标格式拼装（见下）。破坏性变更置顶，其余按重要性排序（新功能 > 修复 > 改进）。
+
+## 输出格式约定
+
+**标准 changelog / release notes（Markdown）：**
+
+```
+# [产品名] [版本号] — [日期或日期范围]
+
+> [可选：一句话概述本次更新亮点]
+
+## ⚠️ 破坏性变更
+- [改了什么]。迁移方式：[如何适配]
+
+## ✨ 新功能
+- [用户视角的功能描述]
+
+## ⚡ 性能优化
+- [优化点]
+
+## 🐛 问题修复
+- [修了什么问题]
+
+## 🔧 其他改进
+- [底层改进合并描述]
+```
+
+- 遵循 [Keep a Changelog] 惯例：分组标题稳定、条目以动词开头、最新版本在最上。
+- **应用商店描述**：不用分组标题，写成 150~200 字的连贯段落，突出 1~3 个最重要的新功能，语言生动、避免技术词，末尾可加一句好评引导。
+- 空的分组不输出（没有 perf 就不放性能章节）。
+- 交付方式：短内容直接贴在对话中；用户要求成文或内容较长时，用 `Write` 保存为 `CHANGELOG.md` 或 `RELEASE_NOTES.md`。若项目已有 `CHANGELOG.md`，先 `Read` 读取，把新版本**追加到顶部**，保留历史条目，不要覆盖。
+- 每条可选择性附上 commit 短哈希便于溯源（`(a1b2c3d)`），面向终端用户时通常省略。
+
+## 边界
+
+- **只读取，不改写历史**：仅执行 `git log`、`git tag`、`git describe` 等只读命令，绝不执行 commit、push、tag、rebase 等修改仓库的操作。
+- **不编造变更**：文档内容严格来自真实 commit；无法判断的表述标注待确认，不虚构功能或数据。
+- **范围为空要报告**：区间无提交、tag 不存在、非 git 目录等情况，明确告知并请用户修正，不产出空壳文档。
+- **不做版本决策**：是否发布、版本号怎么定（semver 判断可给建议）由用户决定。
+- **敏感信息**：若 commit 信息里出现内部代号、未公开客户名、密钥等，改写时剔除或提示用户。

apps/desktop/resources/bundled-skills/competitive-ads-extractor/SKILL.md

@@ -0,0 +1,85 @@
+---
+name: 竞品广告拆解
+description: 当用户想研究竞争对手的广告与投放策略时使用。典型问法："帮我分析 X 竞品在 Facebook / 各渠道的广告"、"拆解这几个对手的广告卖点和落地页"、"看看同行都用什么钩子和 CTA"、"整理一份竞品广告对比，找可借鉴的打法"。
+category: 研究与分析
+allowed-tools:
+ - Read
+ - WebSearch
+---
+
+# 竞品广告拆解
+
+## 目标
+
+系统性拆解竞争对手的广告与落地页，把零散的广告素材转化为**结构化、可对比、能落地借鉴**的营销情报。产出不是"看到了哪些广告"，而是"对手在用什么打法、为什么有效、我方可以借鉴或差异化什么"。
+
+拆解维度贯穿从广告创意到转化路径的全链路：钩子（hook）、核心卖点、目标受众、创意角度、行动号召（CTA）、落地页设计与转化逻辑。适用场景：投放前的竞品调研、找新的创意角度、诊断自身广告为何转化差、进入新市场前摸清同行打法。
+
+## 工作流步骤
+
+### 1. 明确分析目标与范围
+
+先与用户确认这次拆解要服务什么决策，避免漫无目的地收集：
+
+- **分析目的**：找新创意角度、优化现有广告文案、研究定价与卖点、还是全面摸底一个新市场？
+- **竞品清单**：直接竞品（同品类）与间接/参照竞品（打同一人群）分别列出；如用户只给了行业，先帮其识别主要玩家。
+- **渠道范围**：Facebook/Instagram、Google、TikTok、LinkedIn、YouTube、落地页、邮件等，聚焦用户目标客群实际所在的渠道。
+- **分析维度侧重**：文案钩子、视觉创意、受众定位、卖点、优惠机制、落地页转化，明确重点，不必每维都同等深挖。
+
+把界定后的范围复述确认，作为后续拆解的锚点。
+
+### 2. 收集竞品广告与落地页素材
+
+用 WebSearch 系统性收集可公开获取的广告与营销素材：
+
+- **公开广告库**：Facebook/Meta Ad Library、TikTok Creative Center、Google Ads Transparency 等平台会公开展示投放中的广告，是一手素材的主要来源；检索时定位到具体品牌/主页。
+- **落地页**：从广告指向的落地页或官网营销页收集，关注首屏主张、卖点排布、社会证明、CTA、定价与优惠。
+- **多渠道多角度**：换关键词（品牌名、产品名、slogan、品类词）多轮检索；覆盖官方投放、媒体报道、用户讨论、营销分析文章等不同来源。
+- **记录元信息**：为每条素材记下来源、渠道、大致投放时间、广告形式（图文/视频/轮播）、可见的互动或投放持续情况，作为"是否是主推/长青广告"的旁证。
+
+注意：只收集平台公开展示的广告与营销信息；无法获取的（如真实投放预算、精确受众设置、内部数据）不臆测，标注为不可得。
+
+### 3. 结构化提取
+
+对每一条（或每一组）广告，按统一维度拆解，保证可横向对比：
+
+- **钩子（Hook）**：开头 3 秒/首行如何抓注意力——痛点、提问、反常识、数字、身份认同、好奇缺口等。
+- **核心卖点**：主打的价值主张是什么（省钱/省时/效果/身份/风险规避），一条广告的主卖点通常只有一个。
+- **目标受众**：从文案口吻、场景、痛点反推其瞄准的人群画像（身份、阶段、痛点、动机）。
+- **创意角度（Angle）**：切入同一卖点的叙事框架——恐惧诉求、before/after、用户证言、权威背书、对比竞品、稀缺/紧迫等。
+- **CTA**：行动号召的措辞与强度（立即购买 / 免费试用 / 领取优惠 / 了解更多），以及配套的优惠或紧迫感设计。
+- **创意形式**：图文/短视频/UGC 风格/达人口播等表现形式与视觉调性。
+- **落地页衔接**：广告承诺与落地页首屏是否一致，落地页如何承接并推进转化（表单/购买/预约），转化路径长短。
+
+对拿不准的推断（如受众、投放意图）标注为"推测"，与可直接观察到的事实区分开。
+
+### 4. 对比分析与洞察
+
+把结构化提取的结果汇总成对比，从中提炼可行动的洞察：
+
+- **横向对比**：把各竞品放在同一张表里，对比钩子类型、主卖点、角度、CTA、优惠机制，一眼看出各家打法异同。
+- **模式识别**：找出反复出现的共性打法（多家都在用的钩子/角度/卖点），这通常是被市场验证过的有效套路。
+- **空白与差异化**：识别无人主打的卖点、无人覆盖的人群、无人用的角度——这是差异化机会。
+- **可借鉴 vs 需规避**：明确哪些打法值得测试借鉴（并说明如何适配到自身产品），哪些是踩坑或不适合自身定位的。
+- **落地建议**：给出具体、可执行的下一步，如"可测试的 3 个新钩子""建议补强的落地页首屏主张""值得抢占的差异化卖点"。
+
+洞察要落到"我方能做什么"，而非停留在描述对手。
+
+## 输出格式
+
+默认交付**对比表 + 洞察小结**两部分：
+
+- **竞品广告对比表**：每行一个竞品（或一条代表性广告），列为 渠道 / 钩子 / 核心卖点 / 目标受众 / 创意角度 / CTA / 落地页要点 / 备注（来源与投放线索）。
+- **模式与洞察**：分点总结共性打法、市场空白、差异化机会。
+- **可借鉴清单**：按优先级列出可测试的具体动作，每条说明借鉴点与适配方式。
+- **来源附录**：列出所收集素材的来源/链接与观察时间，保证可追溯。
+
+如用户需要，可对单个重点竞品做深度拆解（逐条广告 + 落地页），或输出为可复用的分析模板。
+
+## 边界与注意事项
+
+- **只用公开信息**：仅分析平台公开展示的广告与营销页；不获取、不臆测竞品的内部数据（真实预算、精确受众、后台配置、转化率），此类信息标注为不可得。
+- **区分事实与推测**：可直接观察到的（文案、CTA、形式）为事实；受众、投放意图等反推内容明确标为推测。
+- **不编造**：无法找到素材时如实说明，不虚构广告内容或数据；缺口用占位符标注（如 `[未找到该品牌 TikTok 投放素材]`）。
+- **合规借鉴**：借鉴的是策略与创意角度，不照抄受版权/商标保护的文案与素材；提醒用户避免误导性宣传与侵权。
+- **时效性**：广告投放变化快，标注素材的观察时间，说明结论反映的是某一时点的情况。

apps/desktop/resources/bundled-skills/brand-guidelines/SKILL.md

@@ -0,0 +1,118 @@
+---
+name: 品牌规范
+description: 梳理品牌定位与调性，定义 logo 用法、主辅色、字体、图形语言与语气，输出可分发的品牌规范文档（Markdown 或单文件 HTML，含色值与用法示例）
+category: 设计与UI
+allowed-tools:
+ - Read
+ - Write
+---
+
+# 品牌规范
+
+## 目标
+
+为一个企业、产品或个人品牌产出一份**可分发、可执行的品牌规范文档（Brand Guidelines）**：把品牌的定位、调性、logo 用法、配色、字体、图形语言、语气统一成一套明确规则，让不同的人（设计、市场、外包、AI）在做官网、宣传册、PPT、社媒、邮件时都能做出**风格一致**的东西。
+
+品牌规范的价值在于**约束**：不是罗列"我们有蓝色和白色"，而是明确"主色是 #1B3A6B，用在标题和主按钮；辅色橙 #FF7A45，只做点缀，占比不超过 10%；正文永远用中性灰，不用主色"。规则越具体，一致性越强。
+
+## 工作流
+
+### 第 1 步：梳理品牌定位与调性
+
+先收敛品牌的"人格"，这是所有视觉决策的根：
+
+- **品牌是什么**：一句话定位、核心价值主张、与竞品的差异。
+- **给谁看**：目标人群、行业、To B / To C，决定专业度与温度。
+- **品牌人格**：用形容词或对立轴定位——专业⇄亲和、稳重⇄先锋、极简⇄丰富、理性⇄感性、高端⇄普惠。挑 3–5 个关键词。
+- **参考与禁忌**：欣赏哪些品牌的观感、绝对不想要的感觉。
+
+若用户已有 logo、现用色、现用字体或既有物料，用 Read 读取用户提供的相关文件（品牌简报、现有文档、色值表）作为输入，在其基础上系统化，而不是推倒重来。
+
+### 第 2 步：定义视觉与语言规范
+
+逐项定义，每一项都要给**规则 + 数值 + 该用/不该用**：
+
+**Logo 用法**
+- 主 logo、副标（横版/竖版/纯图标）各自的使用场景。
+- **安全边距（clear space）**：logo 四周留白不小于某个基准（如 logo 高度的 0.5 倍）。
+- **最小尺寸**：小于多少像素/毫米不得使用，保证清晰。
+- **禁用示范**：不得拉伸变形、不得改色、不得加阴影/描边、不得置于杂乱或低对比背景上。
+
+**配色系统**
+- **主色（Primary）**：1–2 个，给 HEX + RGB，说明用途（标题、主按钮、品牌标识）。
+- **辅助色（Secondary）**：支撑主色的邻近色/深浅变体。
+- **强调色（Accent）**：1 个，只做点缀（CTA、高亮），并规定占比上限。
+- **中性色（Neutral）**：文字、背景、分隔线用的黑白灰阶梯。
+- **语义色**（如需）：成功/警告/错误。
+- 给每个色标注**无障碍对比**建议（正文与背景对比度尽量 ≥ 4.5:1）。
+
+**字体系统（Typography）**
+- 中文主字体 + 英文主字体（如思源黑体 / Roboto），及备用（fallback）字体。
+- **字阶（type scale）**：H1/H2/H3/正文/注释的字号、字重、行高，给一套具体数值。
+- 用途规则：标题用什么字重、正文永远不用某某色等。
+
+**图形语言（Graphics）**
+- 圆角还是直角、线条粗细、图标风格（线性/面性）、插画/摄影的调性、间距节奏、常用版式栅格。
+
+**语气（Voice & Tone）**
+- 品牌怎么说话：专业 vs 亲切、是否用"你"、是否用 emoji、术语深浅。
+- 给 **Do / Don't 例句**：同一句话"品牌腔"怎么写、"不要"怎么写。
+
+### 第 3 步：配用法示例
+
+每条规则尽量配一个**正例 + 反例**，让读者一眼看懂边界。如配色给色块 + 十六进制；字体给排版样张；logo 给"正确留白"与"禁止拉伸"对照。示例是品牌规范里最被反复查阅的部分。
+
+### 第 4 步：输出可分发文档
+
+把上述内容组织成一份完整文档，用 Write 保存。两种格式按用户需要选择：
+
+- **Markdown**：便于纳入代码仓 / wiki / 协作文档，纯文本可 diff。
+- **单文件 HTML**：自包含、内联 CSS，可直接在浏览器打开演示，能用真实色块、真实字体样张把规范"演出来"，观感更接近成品。适合对外分发或给非技术同事看。
+
+若选 HTML，直接用 CSS 变量把品牌色/字体定义在 `:root`，让文档本身就是品牌的一次示范。
+
+## 输出格式
+
+文档结构建议如下：
+
+```markdown
+# <品牌名> 品牌规范 Brand Guidelines
+
+## 1. 品牌定位与调性
+- 一句话定位 / 价值主张 / 人格关键词（3–5 个）
+
+## 2. Logo 用法
+- 主/副标 · 使用场景
+- 安全边距 · 最小尺寸
+- ✅ 正确用法 / ❌ 禁用示范
+
+## 3. 配色系统
+| 角色 | 名称 | HEX | RGB | 用途 | 占比/对比建议 |
+|------|------|-----|-----|------|--------------|
+| 主色 | … | #1B3A6B | … | 标题/主按钮 | 对比≥4.5 |
+| 强调 | … | #FF7A45 | … | 仅 CTA 点缀 | ≤10% |
+| 中性 | … | #2B2B2B / #F5F7FA | … | 文字/背景 | — |
+
+## 4. 字体系统
+- 中文 / 英文主字体 + fallback
+- 字阶表：H1…正文（字号/字重/行高）
+
+## 5. 图形语言
+- 圆角 · 线条 · 图标风格 · 版式栅格
+
+## 6. 语气 Voice & Tone
+- 人格描述 + Do / Don't 例句
+
+## 7. 应用示例
+- 名片 / PPT / 社媒 / 邮件签名 的示范
+```
+
+HTML 版则把上述各节渲染为带真实色块、真实字体样张、对照示例的页面，内联所有样式，单文件可直接打开。
+
+## 边界
+
+- **基于用户素材系统化**，不凭空替品牌重定方向；有既有 logo/色值/字体时用 Read 读入并沿用。
+- **不生成 logo 图形本身**：本 skill 定义 logo 的**用法规则**，不绘制/生成 logo 图像；若无 logo，提示用户先确定标识。
+- **不复刻他人品牌**：可参考某种"风格气质"，但不得直接照搬受版权/商标保护的品牌资产（配色体系、logo）。用户举例的知名品牌风格仅作调性参考。
+- **色值与字体要可落地**：优先给可获取的字体（系统字体 / 开源字体如思源系列 / Google Fonts），避免规范无法执行。
+- 规则要**具体到可执行**——给数值、给占比、给 Do/Don't，而不是含糊的形容词堆砌。

apps/desktop/resources/bundled-skills/changelog-generator/SKILL.md

@@ -0,0 +1,131 @@
+---
+name: Changelog 生成
+description: 从 git 提交历史生成结构化 changelog 或 release notes，按 feat/fix/breaking 分类，并把技术描述改写成面向用户的语言。当用户需要生成更新日志、发布说明、版本变更记录时使用。
+category: 文档与写作
+allowed-tools:
+ - Bash
+ - Read
+ - Write
+---
+
+# Changelog 生成
+
+## 目标
+
+从项目的 git 提交历史中提取变更，生成**结构化、面向读者**的 changelog 或 release notes。核心工作是两步转换：先把散乱的 commit 归类（新功能 / 改进 / 修复 / 破坏性变更等），再把工程师视角的技术描述改写成目标读者（终端用户、集成方开发者、或应用商店审核）看得懂、关心的语言。
+
+一条 commit `fix: null check in auth middleware` 对开发者有意义，但用户想看到的是"修复了部分场景下登录失败的问题"。本 skill 就是完成这层翻译，并按版本 / 时间范围组织成规范文档。
+
+## 工作流步骤
+
+### 步骤 1：确认输入参数
+
+动手前明确以下信息，缺失的先问用户或用合理默认：
+
+- **仓库位置**：默认当前工作目录；若用户给了路径则 `cd` 到对应目录操作。
+- **范围**：三选一
+ - 版本区间：如 `v2.4.0..v2.5.0` 或 `v2.4.0..HEAD`
+ - 时间范围：如 `2024-03-01` 到 `2024-03-15`
+ - 相对范围：如"本周""最近 20 次提交"
+- **目标读者**：终端用户（弱化技术）/ 开发者集成方（保留 API 细节）/ 应用商店（简短生动、≤200 字）。读者不同，改写力度完全不同。
+- **输出格式与语言**：Markdown（默认）/ 纯文本；中文 / 英文。
+- **产品名与版本号**：用于标题。
+
+### 步骤 2：用 Bash 抓取提交历史
+
+用 `git log` 拉取范围内的提交。**不要用 `git log` 的分页交互**，加 `--no-pager` 或管道处理。推荐命令（按范围二选一）：
+
+版本区间：
+```
+git --no-pager log v2.4.0..v2.5.0 --pretty=format:'%h%x09%an%x09%ad%x09%s' --date=short
+```
+
+时间范围：
+```
+git --no-pager log --since='2024-03-01' --until='2024-03-15' --pretty=format:'%h%x09%an%x09%ad%x09%s' --date=short
+```
+
+需要正文（含 BREAKING CHANGE 说明、多行描述）时追加 `%x09%b` 或分次用 `--pretty=format:'%H%n%B%n---'`。
+
+辅助命令：
+- 列出可用 tag（确认版本区间是否存在）：`git --no-pager tag --sort=-creatordate | head -20`
+- 上一个 tag：`git describe --tags --abbrev=0`
+- 首次提交（无上一 tag 时兜底范围）：`git --no-pager log --pretty=format:'%h %ad %s' --date=short`
+- 统计文件改动辅助判断影响面：`git --no-pager log <range> --stat`
+
+若范围内无提交或 tag 不存在，明确告知用户并请其确认范围，不要静默产出空文档。
+
+### 步骤 3：解析与归类
+
+逐条解析 commit subject，优先识别 Conventional Commits 前缀，映射到用户友好的分组：
+
+| commit 前缀 | 分组 | Emoji |
+| --- | --- | --- |
+| `feat` | 新功能 | ✨ |
+| `fix` | 问题修复 | 🐛 |
+| `perf` | 性能优化 | ⚡ |
+| `refactor` / `style` / `chore` / `build` / `ci` | 内部改进（多数对用户不可见，视读者决定是否收录或合并为一句） | 🔧 |
+| `docs` | 文档 | 📝 |
+| `revert` | 回滚 | ⏪ |
+| 含 `BREAKING CHANGE` 或 `!`（如 `feat!:`） | 破坏性变更（单独置顶章节） | ⚠️ |
+
+处理原则：
+- **破坏性变更最重要**，永远放在最前，说明改了什么、为何、如何迁移。
+- 面向终端用户时，`chore`/`refactor`/`ci`/`test` 等纯工程提交通常**不进入**正文，或合并成一句"底层稳定性与性能改进"。
+- 面向开发者集成方时，API 变更、依赖升级要保留并标注。
+- 不带规范前缀的 commit：读 subject 语义自行归类；实在无法判断的归到"其他变更"。
+- 合并重复：同一功能的多次提交（`wip`、`fix typo`、`address review`）合并为一条有意义的条目，不逐条罗列。
+- 过滤噪音：`Merge branch`、纯格式化、版本号 bump 等一般剔除。
+
+### 步骤 4：面向读者改写
+
+这是最关键的一步。把每条选中的 commit 改写成读者视角：
+
+- **讲结果，不讲实现**："重构了 X 模块"→"提升了 X 的加载速度"。
+- **讲价值**：说明这个变更给用户带来什么好处或解决了什么困扰。
+- **去术语**：终端用户文档避免 `middleware`、`race condition`、`refactor` 等词；开发者文档可保留。
+- **动词开头、简洁**：每条一句话，句式统一（如统一用"新增/优化/修复"开头）。
+- **不确定语义时不编造**：若 commit 信息太简略无法判断用户可见影响，保留原意并标注 `[待确认：此项面向用户的表述]`，请用户核对，不要臆造功能。
+
+### 步骤 5：组装文档
+
+按目标格式拼装（见下）。破坏性变更置顶，其余按重要性排序（新功能 > 修复 > 改进）。
+
+## 输出格式约定
+
+**标准 changelog / release notes（Markdown）：**
+
+```
+# [产品名] [版本号] — [日期或日期范围]
+
+> [可选：一句话概述本次更新亮点]
+
+## ⚠️ 破坏性变更
+- [改了什么]。迁移方式：[如何适配]
+
+## ✨ 新功能
+- [用户视角的功能描述]
+
+## ⚡ 性能优化
+- [优化点]
+
+## 🐛 问题修复
+- [修了什么问题]
+
+## 🔧 其他改进
+- [底层改进合并描述]
+```
+
+- 遵循 [Keep a Changelog] 惯例：分组标题稳定、条目以动词开头、最新版本在最上。
+- **应用商店描述**：不用分组标题，写成 150~200 字的连贯段落，突出 1~3 个最重要的新功能，语言生动、避免技术词，末尾可加一句好评引导。
+- 空的分组不输出（没有 perf 就不放性能章节）。
+- 交付方式：短内容直接贴在对话中；用户要求成文或内容较长时，用 `Write` 保存为 `CHANGELOG.md` 或 `RELEASE_NOTES.md`。若项目已有 `CHANGELOG.md`，先 `Read` 读取，把新版本**追加到顶部**，保留历史条目，不要覆盖。
+- 每条可选择性附上 commit 短哈希便于溯源（`(a1b2c3d)`），面向终端用户时通常省略。
+
+## 边界
+
+- **只读取，不改写历史**：仅执行 `git log`、`git tag`、`git describe` 等只读命令，绝不执行 commit、push、tag、rebase 等修改仓库的操作。
+- **不编造变更**：文档内容严格来自真实 commit；无法判断的表述标注待确认，不虚构功能或数据。
+- **范围为空要报告**：区间无提交、tag 不存在、非 git 目录等情况，明确告知并请用户修正，不产出空壳文档。
+- **不做版本决策**：是否发布、版本号怎么定（semver 判断可给建议）由用户决定。
+- **敏感信息**：若 commit 信息里出现内部代号、未公开客户名、密钥等，改写时剔除或提示用户。

apps/desktop/resources/bundled-skills/competitive-ads-extractor/SKILL.md

@@ -0,0 +1,85 @@
+---
+name: 竞品广告拆解
+description: 当用户想研究竞争对手的广告与投放策略时使用。典型问法："帮我分析 X 竞品在 Facebook / 各渠道的广告"、"拆解这几个对手的广告卖点和落地页"、"看看同行都用什么钩子和 CTA"、"整理一份竞品广告对比，找可借鉴的打法"。
+category: 研究与分析
+allowed-tools:
+ - Read
+ - WebSearch
+---
+
+# 竞品广告拆解
+
+## 目标
+
+系统性拆解竞争对手的广告与落地页，把零散的广告素材转化为**结构化、可对比、能落地借鉴**的营销情报。产出不是"看到了哪些广告"，而是"对手在用什么打法、为什么有效、我方可以借鉴或差异化什么"。
+
+拆解维度贯穿从广告创意到转化路径的全链路：钩子（hook）、核心卖点、目标受众、创意角度、行动号召（CTA）、落地页设计与转化逻辑。适用场景：投放前的竞品调研、找新的创意角度、诊断自身广告为何转化差、进入新市场前摸清同行打法。
+
+## 工作流步骤
+
+### 1. 明确分析目标与范围
+
+先与用户确认这次拆解要服务什么决策，避免漫无目的地收集：
+
+- **分析目的**：找新创意角度、优化现有广告文案、研究定价与卖点、还是全面摸底一个新市场？
+- **竞品清单**：直接竞品（同品类）与间接/参照竞品（打同一人群）分别列出；如用户只给了行业，先帮其识别主要玩家。
+- **渠道范围**：Facebook/Instagram、Google、TikTok、LinkedIn、YouTube、落地页、邮件等，聚焦用户目标客群实际所在的渠道。
+- **分析维度侧重**：文案钩子、视觉创意、受众定位、卖点、优惠机制、落地页转化，明确重点，不必每维都同等深挖。
+
+把界定后的范围复述确认，作为后续拆解的锚点。
+
+### 2. 收集竞品广告与落地页素材
+
+用 WebSearch 系统性收集可公开获取的广告与营销素材：
+
+- **公开广告库**：Facebook/Meta Ad Library、TikTok Creative Center、Google Ads Transparency 等平台会公开展示投放中的广告，是一手素材的主要来源；检索时定位到具体品牌/主页。
+- **落地页**：从广告指向的落地页或官网营销页收集，关注首屏主张、卖点排布、社会证明、CTA、定价与优惠。
+- **多渠道多角度**：换关键词（品牌名、产品名、slogan、品类词）多轮检索；覆盖官方投放、媒体报道、用户讨论、营销分析文章等不同来源。
+- **记录元信息**：为每条素材记下来源、渠道、大致投放时间、广告形式（图文/视频/轮播）、可见的互动或投放持续情况，作为"是否是主推/长青广告"的旁证。
+
+注意：只收集平台公开展示的广告与营销信息；无法获取的（如真实投放预算、精确受众设置、内部数据）不臆测，标注为不可得。
+
+### 3. 结构化提取
+
+对每一条（或每一组）广告，按统一维度拆解，保证可横向对比：
+
+- **钩子（Hook）**：开头 3 秒/首行如何抓注意力——痛点、提问、反常识、数字、身份认同、好奇缺口等。
+- **核心卖点**：主打的价值主张是什么（省钱/省时/效果/身份/风险规避），一条广告的主卖点通常只有一个。
+- **目标受众**：从文案口吻、场景、痛点反推其瞄准的人群画像（身份、阶段、痛点、动机）。
+- **创意角度（Angle）**：切入同一卖点的叙事框架——恐惧诉求、before/after、用户证言、权威背书、对比竞品、稀缺/紧迫等。
+- **CTA**：行动号召的措辞与强度（立即购买 / 免费试用 / 领取优惠 / 了解更多），以及配套的优惠或紧迫感设计。
+- **创意形式**：图文/短视频/UGC 风格/达人口播等表现形式与视觉调性。
+- **落地页衔接**：广告承诺与落地页首屏是否一致，落地页如何承接并推进转化（表单/购买/预约），转化路径长短。
+
+对拿不准的推断（如受众、投放意图）标注为"推测"，与可直接观察到的事实区分开。
+
+### 4. 对比分析与洞察
+
+把结构化提取的结果汇总成对比，从中提炼可行动的洞察：
+
+- **横向对比**：把各竞品放在同一张表里，对比钩子类型、主卖点、角度、CTA、优惠机制，一眼看出各家打法异同。
+- **模式识别**：找出反复出现的共性打法（多家都在用的钩子/角度/卖点），这通常是被市场验证过的有效套路。
+- **空白与差异化**：识别无人主打的卖点、无人覆盖的人群、无人用的角度——这是差异化机会。
+- **可借鉴 vs 需规避**：明确哪些打法值得测试借鉴（并说明如何适配到自身产品），哪些是踩坑或不适合自身定位的。
+- **落地建议**：给出具体、可执行的下一步，如"可测试的 3 个新钩子""建议补强的落地页首屏主张""值得抢占的差异化卖点"。
+
+洞察要落到"我方能做什么"，而非停留在描述对手。
+
+## 输出格式
+
+默认交付**对比表 + 洞察小结**两部分：
+
+- **竞品广告对比表**：每行一个竞品（或一条代表性广告），列为 渠道 / 钩子 / 核心卖点 / 目标受众 / 创意角度 / CTA / 落地页要点 / 备注（来源与投放线索）。
+- **模式与洞察**：分点总结共性打法、市场空白、差异化机会。
+- **可借鉴清单**：按优先级列出可测试的具体动作，每条说明借鉴点与适配方式。
+- **来源附录**：列出所收集素材的来源/链接与观察时间，保证可追溯。
+
+如用户需要，可对单个重点竞品做深度拆解（逐条广告 + 落地页），或输出为可复用的分析模板。
+
+## 边界与注意事项
+
+- **只用公开信息**：仅分析平台公开展示的广告与营销页；不获取、不臆测竞品的内部数据（真实预算、精确受众、后台配置、转化率），此类信息标注为不可得。
+- **区分事实与推测**：可直接观察到的（文案、CTA、形式）为事实；受众、投放意图等反推内容明确标为推测。
+- **不编造**：无法找到素材时如实说明，不虚构广告内容或数据；缺口用占位符标注（如 `[未找到该品牌 TikTok 投放素材]`）。
+- **合规借鉴**：借鉴的是策略与创意角度，不照抄受版权/商标保护的文案与素材；提醒用户避免误导性宣传与侵权。
+- **时效性**：广告投放变化快，标注素材的观察时间，说明结论反映的是某一时点的情况。

apps/desktop/resources/bundled-skills/brand-guidelines/SKILL.md

@@ -0,0 +1,118 @@
+---
+name: 品牌规范
+description: 梳理品牌定位与调性，定义 logo 用法、主辅色、字体、图形语言与语气，输出可分发的品牌规范文档（Markdown 或单文件 HTML，含色值与用法示例）
+category: 设计与UI
+allowed-tools:
+ - Read
+ - Write
+---
+
+# 品牌规范
+
+## 目标
+
+为一个企业、产品或个人品牌产出一份**可分发、可执行的品牌规范文档（Brand Guidelines）**：把品牌的定位、调性、logo 用法、配色、字体、图形语言、语气统一成一套明确规则，让不同的人（设计、市场、外包、AI）在做官网、宣传册、PPT、社媒、邮件时都能做出**风格一致**的东西。
+
+品牌规范的价值在于**约束**：不是罗列"我们有蓝色和白色"，而是明确"主色是 #1B3A6B，用在标题和主按钮；辅色橙 #FF7A45，只做点缀，占比不超过 10%；正文永远用中性灰，不用主色"。规则越具体，一致性越强。
+
+## 工作流
+
+### 第 1 步：梳理品牌定位与调性
+
+先收敛品牌的"人格"，这是所有视觉决策的根：
+
+- **品牌是什么**：一句话定位、核心价值主张、与竞品的差异。
+- **给谁看**：目标人群、行业、To B / To C，决定专业度与温度。
+- **品牌人格**：用形容词或对立轴定位——专业⇄亲和、稳重⇄先锋、极简⇄丰富、理性⇄感性、高端⇄普惠。挑 3–5 个关键词。
+- **参考与禁忌**：欣赏哪些品牌的观感、绝对不想要的感觉。
+
+若用户已有 logo、现用色、现用字体或既有物料，用 Read 读取用户提供的相关文件（品牌简报、现有文档、色值表）作为输入，在其基础上系统化，而不是推倒重来。
+
+### 第 2 步：定义视觉与语言规范
+
+逐项定义，每一项都要给**规则 + 数值 + 该用/不该用**：
+
+**Logo 用法**
+- 主 logo、副标（横版/竖版/纯图标）各自的使用场景。
+- **安全边距（clear space）**：logo 四周留白不小于某个基准（如 logo 高度的 0.5 倍）。
+- **最小尺寸**：小于多少像素/毫米不得使用，保证清晰。
+- **禁用示范**：不得拉伸变形、不得改色、不得加阴影/描边、不得置于杂乱或低对比背景上。
+
+**配色系统**
+- **主色（Primary）**：1–2 个，给 HEX + RGB，说明用途（标题、主按钮、品牌标识）。
+- **辅助色（Secondary）**：支撑主色的邻近色/深浅变体。
+- **强调色（Accent）**：1 个，只做点缀（CTA、高亮），并规定占比上限。
+- **中性色（Neutral）**：文字、背景、分隔线用的黑白灰阶梯。
+- **语义色**（如需）：成功/警告/错误。
+- 给每个色标注**无障碍对比**建议（正文与背景对比度尽量 ≥ 4.5:1）。
+
+**字体系统（Typography）**
+- 中文主字体 + 英文主字体（如思源黑体 / Roboto），及备用（fallback）字体。
+- **字阶（type scale）**：H1/H2/H3/正文/注释的字号、字重、行高，给一套具体数值。
+- 用途规则：标题用什么字重、正文永远不用某某色等。
+
+**图形语言（Graphics）**
+- 圆角还是直角、线条粗细、图标风格（线性/面性）、插画/摄影的调性、间距节奏、常用版式栅格。
+
+**语气（Voice & Tone）**
+- 品牌怎么说话：专业 vs 亲切、是否用"你"、是否用 emoji、术语深浅。
+- 给 **Do / Don't 例句**：同一句话"品牌腔"怎么写、"不要"怎么写。
+
+### 第 3 步：配用法示例
+
+每条规则尽量配一个**正例 + 反例**，让读者一眼看懂边界。如配色给色块 + 十六进制；字体给排版样张；logo 给"正确留白"与"禁止拉伸"对照。示例是品牌规范里最被反复查阅的部分。
+
+### 第 4 步：输出可分发文档
+
+把上述内容组织成一份完整文档，用 Write 保存。两种格式按用户需要选择：
+
+- **Markdown**：便于纳入代码仓 / wiki / 协作文档，纯文本可 diff。
+- **单文件 HTML**：自包含、内联 CSS，可直接在浏览器打开演示，能用真实色块、真实字体样张把规范"演出来"，观感更接近成品。适合对外分发或给非技术同事看。
+
+若选 HTML，直接用 CSS 变量把品牌色/字体定义在 `:root`，让文档本身就是品牌的一次示范。
+
+## 输出格式
+
+文档结构建议如下：
+
+```markdown
+# <品牌名> 品牌规范 Brand Guidelines
+
+## 1. 品牌定位与调性
+- 一句话定位 / 价值主张 / 人格关键词（3–5 个）
+
+## 2. Logo 用法
+- 主/副标 · 使用场景
+- 安全边距 · 最小尺寸
+- ✅ 正确用法 / ❌ 禁用示范
+
+## 3. 配色系统
+| 角色 | 名称 | HEX | RGB | 用途 | 占比/对比建议 |
+|------|------|-----|-----|------|--------------|
+| 主色 | … | #1B3A6B | … | 标题/主按钮 | 对比≥4.5 |
+| 强调 | … | #FF7A45 | … | 仅 CTA 点缀 | ≤10% |
+| 中性 | … | #2B2B2B / #F5F7FA | … | 文字/背景 | — |
+
+## 4. 字体系统
+- 中文 / 英文主字体 + fallback
+- 字阶表：H1…正文（字号/字重/行高）
+
+## 5. 图形语言
+- 圆角 · 线条 · 图标风格 · 版式栅格
+
+## 6. 语气 Voice & Tone
+- 人格描述 + Do / Don't 例句
+
+## 7. 应用示例
+- 名片 / PPT / 社媒 / 邮件签名 的示范
+```
+
+HTML 版则把上述各节渲染为带真实色块、真实字体样张、对照示例的页面，内联所有样式，单文件可直接打开。
+
+## 边界
+
+- **基于用户素材系统化**，不凭空替品牌重定方向；有既有 logo/色值/字体时用 Read 读入并沿用。
+- **不生成 logo 图形本身**：本 skill 定义 logo 的**用法规则**，不绘制/生成 logo 图像；若无 logo，提示用户先确定标识。
+- **不复刻他人品牌**：可参考某种"风格气质"，但不得直接照搬受版权/商标保护的品牌资产（配色体系、logo）。用户举例的知名品牌风格仅作调性参考。
+- **色值与字体要可落地**：优先给可获取的字体（系统字体 / 开源字体如思源系列 / Google Fonts），避免规范无法执行。
+- 规则要**具体到可执行**——给数值、给占比、给 Do/Don't，而不是含糊的形容词堆砌。

apps/desktop/resources/bundled-skills/changelog-generator/SKILL.md

@@ -0,0 +1,131 @@
+---
+name: Changelog 生成
+description: 从 git 提交历史生成结构化 changelog 或 release notes，按 feat/fix/breaking 分类，并把技术描述改写成面向用户的语言。当用户需要生成更新日志、发布说明、版本变更记录时使用。
+category: 文档与写作
+allowed-tools:
+ - Bash
+ - Read
+ - Write
+---
+
+# Changelog 生成
+
+## 目标
+
+从项目的 git 提交历史中提取变更，生成**结构化、面向读者**的 changelog 或 release notes。核心工作是两步转换：先把散乱的 commit 归类（新功能 / 改进 / 修复 / 破坏性变更等），再把工程师视角的技术描述改写成目标读者（终端用户、集成方开发者、或应用商店审核）看得懂、关心的语言。
+
+一条 commit `fix: null check in auth middleware` 对开发者有意义，但用户想看到的是"修复了部分场景下登录失败的问题"。本 skill 就是完成这层翻译，并按版本 / 时间范围组织成规范文档。
+
+## 工作流步骤
+
+### 步骤 1：确认输入参数
+
+动手前明确以下信息，缺失的先问用户或用合理默认：
+
+- **仓库位置**：默认当前工作目录；若用户给了路径则 `cd` 到对应目录操作。
+- **范围**：三选一
+ - 版本区间：如 `v2.4.0..v2.5.0` 或 `v2.4.0..HEAD`
+ - 时间范围：如 `2024-03-01` 到 `2024-03-15`
+ - 相对范围：如"本周""最近 20 次提交"
+- **目标读者**：终端用户（弱化技术）/ 开发者集成方（保留 API 细节）/ 应用商店（简短生动、≤200 字）。读者不同，改写力度完全不同。
+- **输出格式与语言**：Markdown（默认）/ 纯文本；中文 / 英文。
+- **产品名与版本号**：用于标题。
+
+### 步骤 2：用 Bash 抓取提交历史
+
+用 `git log` 拉取范围内的提交。**不要用 `git log` 的分页交互**，加 `--no-pager` 或管道处理。推荐命令（按范围二选一）：
+
+版本区间：
+```
+git --no-pager log v2.4.0..v2.5.0 --pretty=format:'%h%x09%an%x09%ad%x09%s' --date=short
+```
+
+时间范围：
+```
+git --no-pager log --since='2024-03-01' --until='2024-03-15' --pretty=format:'%h%x09%an%x09%ad%x09%s' --date=short
+```
+
+需要正文（含 BREAKING CHANGE 说明、多行描述）时追加 `%x09%b` 或分次用 `--pretty=format:'%H%n%B%n---'`。
+
+辅助命令：
+- 列出可用 tag（确认版本区间是否存在）：`git --no-pager tag --sort=-creatordate | head -20`
+- 上一个 tag：`git describe --tags --abbrev=0`
+- 首次提交（无上一 tag 时兜底范围）：`git --no-pager log --pretty=format:'%h %ad %s' --date=short`
+- 统计文件改动辅助判断影响面：`git --no-pager log <range> --stat`
+
+若范围内无提交或 tag 不存在，明确告知用户并请其确认范围，不要静默产出空文档。
+
+### 步骤 3：解析与归类
+
+逐条解析 commit subject，优先识别 Conventional Commits 前缀，映射到用户友好的分组：
+
+| commit 前缀 | 分组 | Emoji |
+| --- | --- | --- |
+| `feat` | 新功能 | ✨ |
+| `fix` | 问题修复 | 🐛 |
+| `perf` | 性能优化 | ⚡ |
+| `refactor` / `style` / `chore` / `build` / `ci` | 内部改进（多数对用户不可见，视读者决定是否收录或合并为一句） | 🔧 |
+| `docs` | 文档 | 📝 |
+| `revert` | 回滚 | ⏪ |
+| 含 `BREAKING CHANGE` 或 `!`（如 `feat!:`） | 破坏性变更（单独置顶章节） | ⚠️ |
+
+处理原则：
+- **破坏性变更最重要**，永远放在最前，说明改了什么、为何、如何迁移。
+- 面向终端用户时，`chore`/`refactor`/`ci`/`test` 等纯工程提交通常**不进入**正文，或合并成一句"底层稳定性与性能改进"。
+- 面向开发者集成方时，API 变更、依赖升级要保留并标注。
+- 不带规范前缀的 commit：读 subject 语义自行归类；实在无法判断的归到"其他变更"。
+- 合并重复：同一功能的多次提交（`wip`、`fix typo`、`address review`）合并为一条有意义的条目，不逐条罗列。
+- 过滤噪音：`Merge branch`、纯格式化、版本号 bump 等一般剔除。
+
+### 步骤 4：面向读者改写
+
+这是最关键的一步。把每条选中的 commit 改写成读者视角：
+
+- **讲结果，不讲实现**："重构了 X 模块"→"提升了 X 的加载速度"。
+- **讲价值**：说明这个变更给用户带来什么好处或解决了什么困扰。
+- **去术语**：终端用户文档避免 `middleware`、`race condition`、`refactor` 等词；开发者文档可保留。
+- **动词开头、简洁**：每条一句话，句式统一（如统一用"新增/优化/修复"开头）。
+- **不确定语义时不编造**：若 commit 信息太简略无法判断用户可见影响，保留原意并标注 `[待确认：此项面向用户的表述]`，请用户核对，不要臆造功能。
+
+### 步骤 5：组装文档
+
+按目标格式拼装（见下）。破坏性变更置顶，其余按重要性排序（新功能 > 修复 > 改进）。
+
+## 输出格式约定
+
+**标准 changelog / release notes（Markdown）：**
+
+```
+# [产品名] [版本号] — [日期或日期范围]
+
+> [可选：一句话概述本次更新亮点]
+
+## ⚠️ 破坏性变更
+- [改了什么]。迁移方式：[如何适配]
+
+## ✨ 新功能
+- [用户视角的功能描述]
+
+## ⚡ 性能优化
+- [优化点]
+
+## 🐛 问题修复
+- [修了什么问题]
+
+## 🔧 其他改进
+- [底层改进合并描述]
+```
+
+- 遵循 [Keep a Changelog] 惯例：分组标题稳定、条目以动词开头、最新版本在最上。
+- **应用商店描述**：不用分组标题，写成 150~200 字的连贯段落，突出 1~3 个最重要的新功能，语言生动、避免技术词，末尾可加一句好评引导。
+- 空的分组不输出（没有 perf 就不放性能章节）。
+- 交付方式：短内容直接贴在对话中；用户要求成文或内容较长时，用 `Write` 保存为 `CHANGELOG.md` 或 `RELEASE_NOTES.md`。若项目已有 `CHANGELOG.md`，先 `Read` 读取，把新版本**追加到顶部**，保留历史条目，不要覆盖。
+- 每条可选择性附上 commit 短哈希便于溯源（`(a1b2c3d)`），面向终端用户时通常省略。
+
+## 边界
+
+- **只读取，不改写历史**：仅执行 `git log`、`git tag`、`git describe` 等只读命令，绝不执行 commit、push、tag、rebase 等修改仓库的操作。
+- **不编造变更**：文档内容严格来自真实 commit；无法判断的表述标注待确认，不虚构功能或数据。
+- **范围为空要报告**：区间无提交、tag 不存在、非 git 目录等情况，明确告知并请用户修正，不产出空壳文档。
+- **不做版本决策**：是否发布、版本号怎么定（semver 判断可给建议）由用户决定。
+- **敏感信息**：若 commit 信息里出现内部代号、未公开客户名、密钥等，改写时剔除或提示用户。

apps/desktop/resources/bundled-skills/competitive-ads-extractor/SKILL.md

@@ -0,0 +1,85 @@
+---
+name: 竞品广告拆解
+description: 当用户想研究竞争对手的广告与投放策略时使用。典型问法："帮我分析 X 竞品在 Facebook / 各渠道的广告"、"拆解这几个对手的广告卖点和落地页"、"看看同行都用什么钩子和 CTA"、"整理一份竞品广告对比，找可借鉴的打法"。
+category: 研究与分析
+allowed-tools:
+ - Read
+ - WebSearch
+---
+
+# 竞品广告拆解
+
+## 目标
+
+系统性拆解竞争对手的广告与落地页，把零散的广告素材转化为**结构化、可对比、能落地借鉴**的营销情报。产出不是"看到了哪些广告"，而是"对手在用什么打法、为什么有效、我方可以借鉴或差异化什么"。
+
+拆解维度贯穿从广告创意到转化路径的全链路：钩子（hook）、核心卖点、目标受众、创意角度、行动号召（CTA）、落地页设计与转化逻辑。适用场景：投放前的竞品调研、找新的创意角度、诊断自身广告为何转化差、进入新市场前摸清同行打法。
+
+## 工作流步骤
+
+### 1. 明确分析目标与范围
+
+先与用户确认这次拆解要服务什么决策，避免漫无目的地收集：
+
+- **分析目的**：找新创意角度、优化现有广告文案、研究定价与卖点、还是全面摸底一个新市场？
+- **竞品清单**：直接竞品（同品类）与间接/参照竞品（打同一人群）分别列出；如用户只给了行业，先帮其识别主要玩家。
+- **渠道范围**：Facebook/Instagram、Google、TikTok、LinkedIn、YouTube、落地页、邮件等，聚焦用户目标客群实际所在的渠道。
+- **分析维度侧重**：文案钩子、视觉创意、受众定位、卖点、优惠机制、落地页转化，明确重点，不必每维都同等深挖。
+
+把界定后的范围复述确认，作为后续拆解的锚点。
+
+### 2. 收集竞品广告与落地页素材
+
+用 WebSearch 系统性收集可公开获取的广告与营销素材：
+
+- **公开广告库**：Facebook/Meta Ad Library、TikTok Creative Center、Google Ads Transparency 等平台会公开展示投放中的广告，是一手素材的主要来源；检索时定位到具体品牌/主页。
+- **落地页**：从广告指向的落地页或官网营销页收集，关注首屏主张、卖点排布、社会证明、CTA、定价与优惠。
+- **多渠道多角度**：换关键词（品牌名、产品名、slogan、品类词）多轮检索；覆盖官方投放、媒体报道、用户讨论、营销分析文章等不同来源。
+- **记录元信息**：为每条素材记下来源、渠道、大致投放时间、广告形式（图文/视频/轮播）、可见的互动或投放持续情况，作为"是否是主推/长青广告"的旁证。
+
+注意：只收集平台公开展示的广告与营销信息；无法获取的（如真实投放预算、精确受众设置、内部数据）不臆测，标注为不可得。
+
+### 3. 结构化提取
+
+对每一条（或每一组）广告，按统一维度拆解，保证可横向对比：
+
+- **钩子（Hook）**：开头 3 秒/首行如何抓注意力——痛点、提问、反常识、数字、身份认同、好奇缺口等。
+- **核心卖点**：主打的价值主张是什么（省钱/省时/效果/身份/风险规避），一条广告的主卖点通常只有一个。
+- **目标受众**：从文案口吻、场景、痛点反推其瞄准的人群画像（身份、阶段、痛点、动机）。
+- **创意角度（Angle）**：切入同一卖点的叙事框架——恐惧诉求、before/after、用户证言、权威背书、对比竞品、稀缺/紧迫等。
+- **CTA**：行动号召的措辞与强度（立即购买 / 免费试用 / 领取优惠 / 了解更多），以及配套的优惠或紧迫感设计。
+- **创意形式**：图文/短视频/UGC 风格/达人口播等表现形式与视觉调性。
+- **落地页衔接**：广告承诺与落地页首屏是否一致，落地页如何承接并推进转化（表单/购买/预约），转化路径长短。
+
+对拿不准的推断（如受众、投放意图）标注为"推测"，与可直接观察到的事实区分开。
+
+### 4. 对比分析与洞察
+
+把结构化提取的结果汇总成对比，从中提炼可行动的洞察：
+
+- **横向对比**：把各竞品放在同一张表里，对比钩子类型、主卖点、角度、CTA、优惠机制，一眼看出各家打法异同。
+- **模式识别**：找出反复出现的共性打法（多家都在用的钩子/角度/卖点），这通常是被市场验证过的有效套路。
+- **空白与差异化**：识别无人主打的卖点、无人覆盖的人群、无人用的角度——这是差异化机会。
+- **可借鉴 vs 需规避**：明确哪些打法值得测试借鉴（并说明如何适配到自身产品），哪些是踩坑或不适合自身定位的。
+- **落地建议**：给出具体、可执行的下一步，如"可测试的 3 个新钩子""建议补强的落地页首屏主张""值得抢占的差异化卖点"。
+
+洞察要落到"我方能做什么"，而非停留在描述对手。
+
+## 输出格式
+
+默认交付**对比表 + 洞察小结**两部分：
+
+- **竞品广告对比表**：每行一个竞品（或一条代表性广告），列为 渠道 / 钩子 / 核心卖点 / 目标受众 / 创意角度 / CTA / 落地页要点 / 备注（来源与投放线索）。
+- **模式与洞察**：分点总结共性打法、市场空白、差异化机会。
+- **可借鉴清单**：按优先级列出可测试的具体动作，每条说明借鉴点与适配方式。
+- **来源附录**：列出所收集素材的来源/链接与观察时间，保证可追溯。
+
+如用户需要，可对单个重点竞品做深度拆解（逐条广告 + 落地页），或输出为可复用的分析模板。
+
+## 边界与注意事项
+
+- **只用公开信息**：仅分析平台公开展示的广告与营销页；不获取、不臆测竞品的内部数据（真实预算、精确受众、后台配置、转化率），此类信息标注为不可得。
+- **区分事实与推测**：可直接观察到的（文案、CTA、形式）为事实；受众、投放意图等反推内容明确标为推测。
+- **不编造**：无法找到素材时如实说明，不虚构广告内容或数据；缺口用占位符标注（如 `[未找到该品牌 TikTok 投放素材]`）。
+- **合规借鉴**：借鉴的是策略与创意角度，不照抄受版权/商标保护的文案与素材；提醒用户避免误导性宣传与侵权。
+- **时效性**：广告投放变化快，标注素材的观察时间，说明结论反映的是某一时点的情况。

apps/desktop/resources/bundled-skills/brand-guidelines/SKILL.md

@@ -0,0 +1,118 @@
+---
+name: 品牌规范
+description: 梳理品牌定位与调性，定义 logo 用法、主辅色、字体、图形语言与语气，输出可分发的品牌规范文档（Markdown 或单文件 HTML，含色值与用法示例）
+category: 设计与UI
+allowed-tools:
+ - Read
+ - Write
+---
+
+# 品牌规范
+
+## 目标
+
+为一个企业、产品或个人品牌产出一份**可分发、可执行的品牌规范文档（Brand Guidelines）**：把品牌的定位、调性、logo 用法、配色、字体、图形语言、语气统一成一套明确规则，让不同的人（设计、市场、外包、AI）在做官网、宣传册、PPT、社媒、邮件时都能做出**风格一致**的东西。
+
+品牌规范的价值在于**约束**：不是罗列"我们有蓝色和白色"，而是明确"主色是 #1B3A6B，用在标题和主按钮；辅色橙 #FF7A45，只做点缀，占比不超过 10%；正文永远用中性灰，不用主色"。规则越具体，一致性越强。
+
+## 工作流
+
+### 第 1 步：梳理品牌定位与调性
+
+先收敛品牌的"人格"，这是所有视觉决策的根：
+
+- **品牌是什么**：一句话定位、核心价值主张、与竞品的差异。
+- **给谁看**：目标人群、行业、To B / To C，决定专业度与温度。
+- **品牌人格**：用形容词或对立轴定位——专业⇄亲和、稳重⇄先锋、极简⇄丰富、理性⇄感性、高端⇄普惠。挑 3–5 个关键词。
+- **参考与禁忌**：欣赏哪些品牌的观感、绝对不想要的感觉。
+
+若用户已有 logo、现用色、现用字体或既有物料，用 Read 读取用户提供的相关文件（品牌简报、现有文档、色值表）作为输入，在其基础上系统化，而不是推倒重来。
+
+### 第 2 步：定义视觉与语言规范
+
+逐项定义，每一项都要给**规则 + 数值 + 该用/不该用**：
+
+**Logo 用法**
+- 主 logo、副标（横版/竖版/纯图标）各自的使用场景。
+- **安全边距（clear space）**：logo 四周留白不小于某个基准（如 logo 高度的 0.5 倍）。
+- **最小尺寸**：小于多少像素/毫米不得使用，保证清晰。
+- **禁用示范**：不得拉伸变形、不得改色、不得加阴影/描边、不得置于杂乱或低对比背景上。
+
+**配色系统**
+- **主色（Primary）**：1–2 个，给 HEX + RGB，说明用途（标题、主按钮、品牌标识）。
+- **辅助色（Secondary）**：支撑主色的邻近色/深浅变体。
+- **强调色（Accent）**：1 个，只做点缀（CTA、高亮），并规定占比上限。
+- **中性色（Neutral）**：文字、背景、分隔线用的黑白灰阶梯。
+- **语义色**（如需）：成功/警告/错误。
+- 给每个色标注**无障碍对比**建议（正文与背景对比度尽量 ≥ 4.5:1）。
+
+**字体系统（Typography）**
+- 中文主字体 + 英文主字体（如思源黑体 / Roboto），及备用（fallback）字体。
+- **字阶（type scale）**：H1/H2/H3/正文/注释的字号、字重、行高，给一套具体数值。
+- 用途规则：标题用什么字重、正文永远不用某某色等。
+
+**图形语言（Graphics）**
+- 圆角还是直角、线条粗细、图标风格（线性/面性）、插画/摄影的调性、间距节奏、常用版式栅格。
+
+**语气（Voice & Tone）**
+- 品牌怎么说话：专业 vs 亲切、是否用"你"、是否用 emoji、术语深浅。
+- 给 **Do / Don't 例句**：同一句话"品牌腔"怎么写、"不要"怎么写。
+
+### 第 3 步：配用法示例
+
+每条规则尽量配一个**正例 + 反例**，让读者一眼看懂边界。如配色给色块 + 十六进制；字体给排版样张；logo 给"正确留白"与"禁止拉伸"对照。示例是品牌规范里最被反复查阅的部分。
+
+### 第 4 步：输出可分发文档
+
+把上述内容组织成一份完整文档，用 Write 保存。两种格式按用户需要选择：
+
+- **Markdown**：便于纳入代码仓 / wiki / 协作文档，纯文本可 diff。
+- **单文件 HTML**：自包含、内联 CSS，可直接在浏览器打开演示，能用真实色块、真实字体样张把规范"演出来"，观感更接近成品。适合对外分发或给非技术同事看。
+
+若选 HTML，直接用 CSS 变量把品牌色/字体定义在 `:root`，让文档本身就是品牌的一次示范。
+
+## 输出格式
+
+文档结构建议如下：
+
+```markdown
+# <品牌名> 品牌规范 Brand Guidelines
+
+## 1. 品牌定位与调性
+- 一句话定位 / 价值主张 / 人格关键词（3–5 个）
+
+## 2. Logo 用法
+- 主/副标 · 使用场景
+- 安全边距 · 最小尺寸
+- ✅ 正确用法 / ❌ 禁用示范
+
+## 3. 配色系统
+| 角色 | 名称 | HEX | RGB | 用途 | 占比/对比建议 |
+|------|------|-----|-----|------|--------------|
+| 主色 | … | #1B3A6B | … | 标题/主按钮 | 对比≥4.5 |
+| 强调 | … | #FF7A45 | … | 仅 CTA 点缀 | ≤10% |
+| 中性 | … | #2B2B2B / #F5F7FA | … | 文字/背景 | — |
+
+## 4. 字体系统
+- 中文 / 英文主字体 + fallback
+- 字阶表：H1…正文（字号/字重/行高）
+
+## 5. 图形语言
+- 圆角 · 线条 · 图标风格 · 版式栅格
+
+## 6. 语气 Voice & Tone
+- 人格描述 + Do / Don't 例句
+
+## 7. 应用示例
+- 名片 / PPT / 社媒 / 邮件签名 的示范
+```
+
+HTML 版则把上述各节渲染为带真实色块、真实字体样张、对照示例的页面，内联所有样式，单文件可直接打开。
+
+## 边界
+
+- **基于用户素材系统化**，不凭空替品牌重定方向；有既有 logo/色值/字体时用 Read 读入并沿用。
+- **不生成 logo 图形本身**：本 skill 定义 logo 的**用法规则**，不绘制/生成 logo 图像；若无 logo，提示用户先确定标识。
+- **不复刻他人品牌**：可参考某种"风格气质"，但不得直接照搬受版权/商标保护的品牌资产（配色体系、logo）。用户举例的知名品牌风格仅作调性参考。
+- **色值与字体要可落地**：优先给可获取的字体（系统字体 / 开源字体如思源系列 / Google Fonts），避免规范无法执行。
+- 规则要**具体到可执行**——给数值、给占比、给 Do/Don't，而不是含糊的形容词堆砌。

apps/desktop/resources/bundled-skills/changelog-generator/SKILL.md

@@ -0,0 +1,131 @@
+---
+name: Changelog 生成
+description: 从 git 提交历史生成结构化 changelog 或 release notes，按 feat/fix/breaking 分类，并把技术描述改写成面向用户的语言。当用户需要生成更新日志、发布说明、版本变更记录时使用。
+category: 文档与写作
+allowed-tools:
+ - Bash
+ - Read
+ - Write
+---
+
+# Changelog 生成
+
+## 目标
+
+从项目的 git 提交历史中提取变更，生成**结构化、面向读者**的 changelog 或 release notes。核心工作是两步转换：先把散乱的 commit 归类（新功能 / 改进 / 修复 / 破坏性变更等），再把工程师视角的技术描述改写成目标读者（终端用户、集成方开发者、或应用商店审核）看得懂、关心的语言。
+
+一条 commit `fix: null check in auth middleware` 对开发者有意义，但用户想看到的是"修复了部分场景下登录失败的问题"。本 skill 就是完成这层翻译，并按版本 / 时间范围组织成规范文档。
+
+## 工作流步骤
+
+### 步骤 1：确认输入参数
+
+动手前明确以下信息，缺失的先问用户或用合理默认：
+
+- **仓库位置**：默认当前工作目录；若用户给了路径则 `cd` 到对应目录操作。
+- **范围**：三选一
+ - 版本区间：如 `v2.4.0..v2.5.0` 或 `v2.4.0..HEAD`
+ - 时间范围：如 `2024-03-01` 到 `2024-03-15`
+ - 相对范围：如"本周""最近 20 次提交"
+- **目标读者**：终端用户（弱化技术）/ 开发者集成方（保留 API 细节）/ 应用商店（简短生动、≤200 字）。读者不同，改写力度完全不同。
+- **输出格式与语言**：Markdown（默认）/ 纯文本；中文 / 英文。
+- **产品名与版本号**：用于标题。
+
+### 步骤 2：用 Bash 抓取提交历史
+
+用 `git log` 拉取范围内的提交。**不要用 `git log` 的分页交互**，加 `--no-pager` 或管道处理。推荐命令（按范围二选一）：
+
+版本区间：
+```
+git --no-pager log v2.4.0..v2.5.0 --pretty=format:'%h%x09%an%x09%ad%x09%s' --date=short
+```
+
+时间范围：
+```
+git --no-pager log --since='2024-03-01' --until='2024-03-15' --pretty=format:'%h%x09%an%x09%ad%x09%s' --date=short
+```
+
+需要正文（含 BREAKING CHANGE 说明、多行描述）时追加 `%x09%b` 或分次用 `--pretty=format:'%H%n%B%n---'`。
+
+辅助命令：
+- 列出可用 tag（确认版本区间是否存在）：`git --no-pager tag --sort=-creatordate | head -20`
+- 上一个 tag：`git describe --tags --abbrev=0`
+- 首次提交（无上一 tag 时兜底范围）：`git --no-pager log --pretty=format:'%h %ad %s' --date=short`
+- 统计文件改动辅助判断影响面：`git --no-pager log <range> --stat`
+
+若范围内无提交或 tag 不存在，明确告知用户并请其确认范围，不要静默产出空文档。
+
+### 步骤 3：解析与归类
+
+逐条解析 commit subject，优先识别 Conventional Commits 前缀，映射到用户友好的分组：
+
+| commit 前缀 | 分组 | Emoji |
+| --- | --- | --- |
+| `feat` | 新功能 | ✨ |
+| `fix` | 问题修复 | 🐛 |
+| `perf` | 性能优化 | ⚡ |
+| `refactor` / `style` / `chore` / `build` / `ci` | 内部改进（多数对用户不可见，视读者决定是否收录或合并为一句） | 🔧 |
+| `docs` | 文档 | 📝 |
+| `revert` | 回滚 | ⏪ |
+| 含 `BREAKING CHANGE` 或 `!`（如 `feat!:`） | 破坏性变更（单独置顶章节） | ⚠️ |
+
+处理原则：
+- **破坏性变更最重要**，永远放在最前，说明改了什么、为何、如何迁移。
+- 面向终端用户时，`chore`/`refactor`/`ci`/`test` 等纯工程提交通常**不进入**正文，或合并成一句"底层稳定性与性能改进"。
+- 面向开发者集成方时，API 变更、依赖升级要保留并标注。
+- 不带规范前缀的 commit：读 subject 语义自行归类；实在无法判断的归到"其他变更"。
+- 合并重复：同一功能的多次提交（`wip`、`fix typo`、`address review`）合并为一条有意义的条目，不逐条罗列。
+- 过滤噪音：`Merge branch`、纯格式化、版本号 bump 等一般剔除。
+
+### 步骤 4：面向读者改写
+
+这是最关键的一步。把每条选中的 commit 改写成读者视角：
+
+- **讲结果，不讲实现**："重构了 X 模块"→"提升了 X 的加载速度"。
+- **讲价值**：说明这个变更给用户带来什么好处或解决了什么困扰。
+- **去术语**：终端用户文档避免 `middleware`、`race condition`、`refactor` 等词；开发者文档可保留。
+- **动词开头、简洁**：每条一句话，句式统一（如统一用"新增/优化/修复"开头）。
+- **不确定语义时不编造**：若 commit 信息太简略无法判断用户可见影响，保留原意并标注 `[待确认：此项面向用户的表述]`，请用户核对，不要臆造功能。
+
+### 步骤 5：组装文档
+
+按目标格式拼装（见下）。破坏性变更置顶，其余按重要性排序（新功能 > 修复 > 改进）。
+
+## 输出格式约定
+
+**标准 changelog / release notes（Markdown）：**
+
+```
+# [产品名] [版本号] — [日期或日期范围]
+
+> [可选：一句话概述本次更新亮点]
+
+## ⚠️ 破坏性变更
+- [改了什么]。迁移方式：[如何适配]
+
+## ✨ 新功能
+- [用户视角的功能描述]
+
+## ⚡ 性能优化
+- [优化点]
+
+## 🐛 问题修复
+- [修了什么问题]
+
+## 🔧 其他改进
+- [底层改进合并描述]
+```
+
+- 遵循 [Keep a Changelog] 惯例：分组标题稳定、条目以动词开头、最新版本在最上。
+- **应用商店描述**：不用分组标题，写成 150~200 字的连贯段落，突出 1~3 个最重要的新功能，语言生动、避免技术词，末尾可加一句好评引导。
+- 空的分组不输出（没有 perf 就不放性能章节）。
+- 交付方式：短内容直接贴在对话中；用户要求成文或内容较长时，用 `Write` 保存为 `CHANGELOG.md` 或 `RELEASE_NOTES.md`。若项目已有 `CHANGELOG.md`，先 `Read` 读取，把新版本**追加到顶部**，保留历史条目，不要覆盖。
+- 每条可选择性附上 commit 短哈希便于溯源（`(a1b2c3d)`），面向终端用户时通常省略。
+
+## 边界
+
+- **只读取，不改写历史**：仅执行 `git log`、`git tag`、`git describe` 等只读命令，绝不执行 commit、push、tag、rebase 等修改仓库的操作。
+- **不编造变更**：文档内容严格来自真实 commit；无法判断的表述标注待确认，不虚构功能或数据。
+- **范围为空要报告**：区间无提交、tag 不存在、非 git 目录等情况，明确告知并请用户修正，不产出空壳文档。
+- **不做版本决策**：是否发布、版本号怎么定（semver 判断可给建议）由用户决定。
+- **敏感信息**：若 commit 信息里出现内部代号、未公开客户名、密钥等，改写时剔除或提示用户。

apps/desktop/resources/bundled-skills/competitive-ads-extractor/SKILL.md

@@ -0,0 +1,85 @@
+---
+name: 竞品广告拆解
+description: 当用户想研究竞争对手的广告与投放策略时使用。典型问法："帮我分析 X 竞品在 Facebook / 各渠道的广告"、"拆解这几个对手的广告卖点和落地页"、"看看同行都用什么钩子和 CTA"、"整理一份竞品广告对比，找可借鉴的打法"。
+category: 研究与分析
+allowed-tools:
+ - Read
+ - WebSearch
+---
+
+# 竞品广告拆解
+
+## 目标
+
+系统性拆解竞争对手的广告与落地页，把零散的广告素材转化为**结构化、可对比、能落地借鉴**的营销情报。产出不是"看到了哪些广告"，而是"对手在用什么打法、为什么有效、我方可以借鉴或差异化什么"。
+
+拆解维度贯穿从广告创意到转化路径的全链路：钩子（hook）、核心卖点、目标受众、创意角度、行动号召（CTA）、落地页设计与转化逻辑。适用场景：投放前的竞品调研、找新的创意角度、诊断自身广告为何转化差、进入新市场前摸清同行打法。
+
+## 工作流步骤
+
+### 1. 明确分析目标与范围
+
+先与用户确认这次拆解要服务什么决策，避免漫无目的地收集：
+
+- **分析目的**：找新创意角度、优化现有广告文案、研究定价与卖点、还是全面摸底一个新市场？
+- **竞品清单**：直接竞品（同品类）与间接/参照竞品（打同一人群）分别列出；如用户只给了行业，先帮其识别主要玩家。
+- **渠道范围**：Facebook/Instagram、Google、TikTok、LinkedIn、YouTube、落地页、邮件等，聚焦用户目标客群实际所在的渠道。
+- **分析维度侧重**：文案钩子、视觉创意、受众定位、卖点、优惠机制、落地页转化，明确重点，不必每维都同等深挖。
+
+把界定后的范围复述确认，作为后续拆解的锚点。
+
+### 2. 收集竞品广告与落地页素材
+
+用 WebSearch 系统性收集可公开获取的广告与营销素材：
+
+- **公开广告库**：Facebook/Meta Ad Library、TikTok Creative Center、Google Ads Transparency 等平台会公开展示投放中的广告，是一手素材的主要来源；检索时定位到具体品牌/主页。
+- **落地页**：从广告指向的落地页或官网营销页收集，关注首屏主张、卖点排布、社会证明、CTA、定价与优惠。
+- **多渠道多角度**：换关键词（品牌名、产品名、slogan、品类词）多轮检索；覆盖官方投放、媒体报道、用户讨论、营销分析文章等不同来源。
+- **记录元信息**：为每条素材记下来源、渠道、大致投放时间、广告形式（图文/视频/轮播）、可见的互动或投放持续情况，作为"是否是主推/长青广告"的旁证。
+
+注意：只收集平台公开展示的广告与营销信息；无法获取的（如真实投放预算、精确受众设置、内部数据）不臆测，标注为不可得。
+
+### 3. 结构化提取
+
+对每一条（或每一组）广告，按统一维度拆解，保证可横向对比：
+
+- **钩子（Hook）**：开头 3 秒/首行如何抓注意力——痛点、提问、反常识、数字、身份认同、好奇缺口等。
+- **核心卖点**：主打的价值主张是什么（省钱/省时/效果/身份/风险规避），一条广告的主卖点通常只有一个。
+- **目标受众**：从文案口吻、场景、痛点反推其瞄准的人群画像（身份、阶段、痛点、动机）。
+- **创意角度（Angle）**：切入同一卖点的叙事框架——恐惧诉求、before/after、用户证言、权威背书、对比竞品、稀缺/紧迫等。
+- **CTA**：行动号召的措辞与强度（立即购买 / 免费试用 / 领取优惠 / 了解更多），以及配套的优惠或紧迫感设计。
+- **创意形式**：图文/短视频/UGC 风格/达人口播等表现形式与视觉调性。
+- **落地页衔接**：广告承诺与落地页首屏是否一致，落地页如何承接并推进转化（表单/购买/预约），转化路径长短。
+
+对拿不准的推断（如受众、投放意图）标注为"推测"，与可直接观察到的事实区分开。
+
+### 4. 对比分析与洞察
+
+把结构化提取的结果汇总成对比，从中提炼可行动的洞察：
+
+- **横向对比**：把各竞品放在同一张表里，对比钩子类型、主卖点、角度、CTA、优惠机制，一眼看出各家打法异同。
+- **模式识别**：找出反复出现的共性打法（多家都在用的钩子/角度/卖点），这通常是被市场验证过的有效套路。
+- **空白与差异化**：识别无人主打的卖点、无人覆盖的人群、无人用的角度——这是差异化机会。
+- **可借鉴 vs 需规避**：明确哪些打法值得测试借鉴（并说明如何适配到自身产品），哪些是踩坑或不适合自身定位的。
+- **落地建议**：给出具体、可执行的下一步，如"可测试的 3 个新钩子""建议补强的落地页首屏主张""值得抢占的差异化卖点"。
+
+洞察要落到"我方能做什么"，而非停留在描述对手。
+
+## 输出格式
+
+默认交付**对比表 + 洞察小结**两部分：
+
+- **竞品广告对比表**：每行一个竞品（或一条代表性广告），列为 渠道 / 钩子 / 核心卖点 / 目标受众 / 创意角度 / CTA / 落地页要点 / 备注（来源与投放线索）。
+- **模式与洞察**：分点总结共性打法、市场空白、差异化机会。
+- **可借鉴清单**：按优先级列出可测试的具体动作，每条说明借鉴点与适配方式。
+- **来源附录**：列出所收集素材的来源/链接与观察时间，保证可追溯。
+
+如用户需要，可对单个重点竞品做深度拆解（逐条广告 + 落地页），或输出为可复用的分析模板。
+
+## 边界与注意事项
+
+- **只用公开信息**：仅分析平台公开展示的广告与营销页；不获取、不臆测竞品的内部数据（真实预算、精确受众、后台配置、转化率），此类信息标注为不可得。
+- **区分事实与推测**：可直接观察到的（文案、CTA、形式）为事实；受众、投放意图等反推内容明确标为推测。
+- **不编造**：无法找到素材时如实说明，不虚构广告内容或数据；缺口用占位符标注（如 `[未找到该品牌 TikTok 投放素材]`）。
+- **合规借鉴**：借鉴的是策略与创意角度，不照抄受版权/商标保护的文案与素材；提醒用户避免误导性宣传与侵权。
+- **时效性**：广告投放变化快，标注素材的观察时间，说明结论反映的是某一时点的情况。

apps/desktop/resources/bundled-skills/brand-guidelines/SKILL.md

@@ -0,0 +1,118 @@
+---
+name: 品牌规范
+description: 梳理品牌定位与调性，定义 logo 用法、主辅色、字体、图形语言与语气，输出可分发的品牌规范文档（Markdown 或单文件 HTML，含色值与用法示例）
+category: 设计与UI
+allowed-tools:
+ - Read
+ - Write
+---
+
+# 品牌规范
+
+## 目标
+
+为一个企业、产品或个人品牌产出一份**可分发、可执行的品牌规范文档（Brand Guidelines）**：把品牌的定位、调性、logo 用法、配色、字体、图形语言、语气统一成一套明确规则，让不同的人（设计、市场、外包、AI）在做官网、宣传册、PPT、社媒、邮件时都能做出**风格一致**的东西。
+
+品牌规范的价值在于**约束**：不是罗列"我们有蓝色和白色"，而是明确"主色是 #1B3A6B，用在标题和主按钮；辅色橙 #FF7A45，只做点缀，占比不超过 10%；正文永远用中性灰，不用主色"。规则越具体，一致性越强。
+
+## 工作流
+
+### 第 1 步：梳理品牌定位与调性
+
+先收敛品牌的"人格"，这是所有视觉决策的根：
+
+- **品牌是什么**：一句话定位、核心价值主张、与竞品的差异。
+- **给谁看**：目标人群、行业、To B / To C，决定专业度与温度。
+- **品牌人格**：用形容词或对立轴定位——专业⇄亲和、稳重⇄先锋、极简⇄丰富、理性⇄感性、高端⇄普惠。挑 3–5 个关键词。
+- **参考与禁忌**：欣赏哪些品牌的观感、绝对不想要的感觉。
+
+若用户已有 logo、现用色、现用字体或既有物料，用 Read 读取用户提供的相关文件（品牌简报、现有文档、色值表）作为输入，在其基础上系统化，而不是推倒重来。
+
+### 第 2 步：定义视觉与语言规范
+
+逐项定义，每一项都要给**规则 + 数值 + 该用/不该用**：
+
+**Logo 用法**
+- 主 logo、副标（横版/竖版/纯图标）各自的使用场景。
+- **安全边距（clear space）**：logo 四周留白不小于某个基准（如 logo 高度的 0.5 倍）。
+- **最小尺寸**：小于多少像素/毫米不得使用，保证清晰。
+- **禁用示范**：不得拉伸变形、不得改色、不得加阴影/描边、不得置于杂乱或低对比背景上。
+
+**配色系统**
+- **主色（Primary）**：1–2 个，给 HEX + RGB，说明用途（标题、主按钮、品牌标识）。
+- **辅助色（Secondary）**：支撑主色的邻近色/深浅变体。
+- **强调色（Accent）**：1 个，只做点缀（CTA、高亮），并规定占比上限。
+- **中性色（Neutral）**：文字、背景、分隔线用的黑白灰阶梯。
+- **语义色**（如需）：成功/警告/错误。
+- 给每个色标注**无障碍对比**建议（正文与背景对比度尽量 ≥ 4.5:1）。
+
+**字体系统（Typography）**
+- 中文主字体 + 英文主字体（如思源黑体 / Roboto），及备用（fallback）字体。
+- **字阶（type scale）**：H1/H2/H3/正文/注释的字号、字重、行高，给一套具体数值。
+- 用途规则：标题用什么字重、正文永远不用某某色等。
+
+**图形语言（Graphics）**
+- 圆角还是直角、线条粗细、图标风格（线性/面性）、插画/摄影的调性、间距节奏、常用版式栅格。
+
+**语气（Voice & Tone）**
+- 品牌怎么说话：专业 vs 亲切、是否用"你"、是否用 emoji、术语深浅。
+- 给 **Do / Don't 例句**：同一句话"品牌腔"怎么写、"不要"怎么写。
+
+### 第 3 步：配用法示例
+
+每条规则尽量配一个**正例 + 反例**，让读者一眼看懂边界。如配色给色块 + 十六进制；字体给排版样张；logo 给"正确留白"与"禁止拉伸"对照。示例是品牌规范里最被反复查阅的部分。
+
+### 第 4 步：输出可分发文档
+
+把上述内容组织成一份完整文档，用 Write 保存。两种格式按用户需要选择：
+
+- **Markdown**：便于纳入代码仓 / wiki / 协作文档，纯文本可 diff。
+- **单文件 HTML**：自包含、内联 CSS，可直接在浏览器打开演示，能用真实色块、真实字体样张把规范"演出来"，观感更接近成品。适合对外分发或给非技术同事看。
+
+若选 HTML，直接用 CSS 变量把品牌色/字体定义在 `:root`，让文档本身就是品牌的一次示范。
+
+## 输出格式
+
+文档结构建议如下：
+
+```markdown
+# <品牌名> 品牌规范 Brand Guidelines
+
+## 1. 品牌定位与调性
+- 一句话定位 / 价值主张 / 人格关键词（3–5 个）
+
+## 2. Logo 用法
+- 主/副标 · 使用场景
+- 安全边距 · 最小尺寸
+- ✅ 正确用法 / ❌ 禁用示范
+
+## 3. 配色系统
+| 角色 | 名称 | HEX | RGB | 用途 | 占比/对比建议 |
+|------|------|-----|-----|------|--------------|
+| 主色 | … | #1B3A6B | … | 标题/主按钮 | 对比≥4.5 |
+| 强调 | … | #FF7A45 | … | 仅 CTA 点缀 | ≤10% |
+| 中性 | … | #2B2B2B / #F5F7FA | … | 文字/背景 | — |
+
+## 4. 字体系统
+- 中文 / 英文主字体 + fallback
+- 字阶表：H1…正文（字号/字重/行高）
+
+## 5. 图形语言
+- 圆角 · 线条 · 图标风格 · 版式栅格
+
+## 6. 语气 Voice & Tone
+- 人格描述 + Do / Don't 例句
+
+## 7. 应用示例
+- 名片 / PPT / 社媒 / 邮件签名 的示范
+```
+
+HTML 版则把上述各节渲染为带真实色块、真实字体样张、对照示例的页面，内联所有样式，单文件可直接打开。
+
+## 边界
+
+- **基于用户素材系统化**，不凭空替品牌重定方向；有既有 logo/色值/字体时用 Read 读入并沿用。
+- **不生成 logo 图形本身**：本 skill 定义 logo 的**用法规则**，不绘制/生成 logo 图像；若无 logo，提示用户先确定标识。
+- **不复刻他人品牌**：可参考某种"风格气质"，但不得直接照搬受版权/商标保护的品牌资产（配色体系、logo）。用户举例的知名品牌风格仅作调性参考。
+- **色值与字体要可落地**：优先给可获取的字体（系统字体 / 开源字体如思源系列 / Google Fonts），避免规范无法执行。
+- 规则要**具体到可执行**——给数值、给占比、给 Do/Don't，而不是含糊的形容词堆砌。

apps/desktop/resources/bundled-skills/changelog-generator/SKILL.md

@@ -0,0 +1,131 @@
+---
+name: Changelog 生成
+description: 从 git 提交历史生成结构化 changelog 或 release notes，按 feat/fix/breaking 分类，并把技术描述改写成面向用户的语言。当用户需要生成更新日志、发布说明、版本变更记录时使用。
+category: 文档与写作
+allowed-tools:
+ - Bash
+ - Read
+ - Write
+---
+
+# Changelog 生成
+
+## 目标
+
+从项目的 git 提交历史中提取变更，生成**结构化、面向读者**的 changelog 或 release notes。核心工作是两步转换：先把散乱的 commit 归类（新功能 / 改进 / 修复 / 破坏性变更等），再把工程师视角的技术描述改写成目标读者（终端用户、集成方开发者、或应用商店审核）看得懂、关心的语言。
+
+一条 commit `fix: null check in auth middleware` 对开发者有意义，但用户想看到的是"修复了部分场景下登录失败的问题"。本 skill 就是完成这层翻译，并按版本 / 时间范围组织成规范文档。
+
+## 工作流步骤
+
+### 步骤 1：确认输入参数
+
+动手前明确以下信息，缺失的先问用户或用合理默认：
+
+- **仓库位置**：默认当前工作目录；若用户给了路径则 `cd` 到对应目录操作。
+- **范围**：三选一
+ - 版本区间：如 `v2.4.0..v2.5.0` 或 `v2.4.0..HEAD`
+ - 时间范围：如 `2024-03-01` 到 `2024-03-15`
+ - 相对范围：如"本周""最近 20 次提交"
+- **目标读者**：终端用户（弱化技术）/ 开发者集成方（保留 API 细节）/ 应用商店（简短生动、≤200 字）。读者不同，改写力度完全不同。
+- **输出格式与语言**：Markdown（默认）/ 纯文本；中文 / 英文。
+- **产品名与版本号**：用于标题。
+
+### 步骤 2：用 Bash 抓取提交历史
+
+用 `git log` 拉取范围内的提交。**不要用 `git log` 的分页交互**，加 `--no-pager` 或管道处理。推荐命令（按范围二选一）：
+
+版本区间：
+```
+git --no-pager log v2.4.0..v2.5.0 --pretty=format:'%h%x09%an%x09%ad%x09%s' --date=short
+```
+
+时间范围：
+```
+git --no-pager log --since='2024-03-01' --until='2024-03-15' --pretty=format:'%h%x09%an%x09%ad%x09%s' --date=short
+```
+
+需要正文（含 BREAKING CHANGE 说明、多行描述）时追加 `%x09%b` 或分次用 `--pretty=format:'%H%n%B%n---'`。
+
+辅助命令：
+- 列出可用 tag（确认版本区间是否存在）：`git --no-pager tag --sort=-creatordate | head -20`
+- 上一个 tag：`git describe --tags --abbrev=0`
+- 首次提交（无上一 tag 时兜底范围）：`git --no-pager log --pretty=format:'%h %ad %s' --date=short`
+- 统计文件改动辅助判断影响面：`git --no-pager log <range> --stat`
+
+若范围内无提交或 tag 不存在，明确告知用户并请其确认范围，不要静默产出空文档。
+
+### 步骤 3：解析与归类
+
+逐条解析 commit subject，优先识别 Conventional Commits 前缀，映射到用户友好的分组：
+
+| commit 前缀 | 分组 | Emoji |
+| --- | --- | --- |
+| `feat` | 新功能 | ✨ |
+| `fix` | 问题修复 | 🐛 |
+| `perf` | 性能优化 | ⚡ |
+| `refactor` / `style` / `chore` / `build` / `ci` | 内部改进（多数对用户不可见，视读者决定是否收录或合并为一句） | 🔧 |
+| `docs` | 文档 | 📝 |
+| `revert` | 回滚 | ⏪ |
+| 含 `BREAKING CHANGE` 或 `!`（如 `feat!:`） | 破坏性变更（单独置顶章节） | ⚠️ |
+
+处理原则：
+- **破坏性变更最重要**，永远放在最前，说明改了什么、为何、如何迁移。
+- 面向终端用户时，`chore`/`refactor`/`ci`/`test` 等纯工程提交通常**不进入**正文，或合并成一句"底层稳定性与性能改进"。
+- 面向开发者集成方时，API 变更、依赖升级要保留并标注。
+- 不带规范前缀的 commit：读 subject 语义自行归类；实在无法判断的归到"其他变更"。
+- 合并重复：同一功能的多次提交（`wip`、`fix typo`、`address review`）合并为一条有意义的条目，不逐条罗列。
+- 过滤噪音：`Merge branch`、纯格式化、版本号 bump 等一般剔除。
+
+### 步骤 4：面向读者改写
+
+这是最关键的一步。把每条选中的 commit 改写成读者视角：
+
+- **讲结果，不讲实现**："重构了 X 模块"→"提升了 X 的加载速度"。
+- **讲价值**：说明这个变更给用户带来什么好处或解决了什么困扰。
+- **去术语**：终端用户文档避免 `middleware`、`race condition`、`refactor` 等词；开发者文档可保留。
+- **动词开头、简洁**：每条一句话，句式统一（如统一用"新增/优化/修复"开头）。
+- **不确定语义时不编造**：若 commit 信息太简略无法判断用户可见影响，保留原意并标注 `[待确认：此项面向用户的表述]`，请用户核对，不要臆造功能。
+
+### 步骤 5：组装文档
+
+按目标格式拼装（见下）。破坏性变更置顶，其余按重要性排序（新功能 > 修复 > 改进）。
+
+## 输出格式约定
+
+**标准 changelog / release notes（Markdown）：**
+
+```
+# [产品名] [版本号] — [日期或日期范围]
+
+> [可选：一句话概述本次更新亮点]
+
+## ⚠️ 破坏性变更
+- [改了什么]。迁移方式：[如何适配]
+
+## ✨ 新功能
+- [用户视角的功能描述]
+
+## ⚡ 性能优化
+- [优化点]
+
+## 🐛 问题修复
+- [修了什么问题]
+
+## 🔧 其他改进
+- [底层改进合并描述]
+```
+
+- 遵循 [Keep a Changelog] 惯例：分组标题稳定、条目以动词开头、最新版本在最上。
+- **应用商店描述**：不用分组标题，写成 150~200 字的连贯段落，突出 1~3 个最重要的新功能，语言生动、避免技术词，末尾可加一句好评引导。
+- 空的分组不输出（没有 perf 就不放性能章节）。
+- 交付方式：短内容直接贴在对话中；用户要求成文或内容较长时，用 `Write` 保存为 `CHANGELOG.md` 或 `RELEASE_NOTES.md`。若项目已有 `CHANGELOG.md`，先 `Read` 读取，把新版本**追加到顶部**，保留历史条目，不要覆盖。
+- 每条可选择性附上 commit 短哈希便于溯源（`(a1b2c3d)`），面向终端用户时通常省略。
+
+## 边界
+
+- **只读取，不改写历史**：仅执行 `git log`、`git tag`、`git describe` 等只读命令，绝不执行 commit、push、tag、rebase 等修改仓库的操作。
+- **不编造变更**：文档内容严格来自真实 commit；无法判断的表述标注待确认，不虚构功能或数据。
+- **范围为空要报告**：区间无提交、tag 不存在、非 git 目录等情况，明确告知并请用户修正，不产出空壳文档。
+- **不做版本决策**：是否发布、版本号怎么定（semver 判断可给建议）由用户决定。
+- **敏感信息**：若 commit 信息里出现内部代号、未公开客户名、密钥等，改写时剔除或提示用户。

apps/desktop/resources/bundled-skills/competitive-ads-extractor/SKILL.md

@@ -0,0 +1,85 @@
+---
+name: 竞品广告拆解
+description: 当用户想研究竞争对手的广告与投放策略时使用。典型问法："帮我分析 X 竞品在 Facebook / 各渠道的广告"、"拆解这几个对手的广告卖点和落地页"、"看看同行都用什么钩子和 CTA"、"整理一份竞品广告对比，找可借鉴的打法"。
+category: 研究与分析
+allowed-tools:
+ - Read
+ - WebSearch
+---
+
+# 竞品广告拆解
+
+## 目标
+
+系统性拆解竞争对手的广告与落地页，把零散的广告素材转化为**结构化、可对比、能落地借鉴**的营销情报。产出不是"看到了哪些广告"，而是"对手在用什么打法、为什么有效、我方可以借鉴或差异化什么"。
+
+拆解维度贯穿从广告创意到转化路径的全链路：钩子（hook）、核心卖点、目标受众、创意角度、行动号召（CTA）、落地页设计与转化逻辑。适用场景：投放前的竞品调研、找新的创意角度、诊断自身广告为何转化差、进入新市场前摸清同行打法。
+
+## 工作流步骤
+
+### 1. 明确分析目标与范围
+
+先与用户确认这次拆解要服务什么决策，避免漫无目的地收集：
+
+- **分析目的**：找新创意角度、优化现有广告文案、研究定价与卖点、还是全面摸底一个新市场？
+- **竞品清单**：直接竞品（同品类）与间接/参照竞品（打同一人群）分别列出；如用户只给了行业，先帮其识别主要玩家。
+- **渠道范围**：Facebook/Instagram、Google、TikTok、LinkedIn、YouTube、落地页、邮件等，聚焦用户目标客群实际所在的渠道。
+- **分析维度侧重**：文案钩子、视觉创意、受众定位、卖点、优惠机制、落地页转化，明确重点，不必每维都同等深挖。
+
+把界定后的范围复述确认，作为后续拆解的锚点。
+
+### 2. 收集竞品广告与落地页素材
+
+用 WebSearch 系统性收集可公开获取的广告与营销素材：
+
+- **公开广告库**：Facebook/Meta Ad Library、TikTok Creative Center、Google Ads Transparency 等平台会公开展示投放中的广告，是一手素材的主要来源；检索时定位到具体品牌/主页。
+- **落地页**：从广告指向的落地页或官网营销页收集，关注首屏主张、卖点排布、社会证明、CTA、定价与优惠。
+- **多渠道多角度**：换关键词（品牌名、产品名、slogan、品类词）多轮检索；覆盖官方投放、媒体报道、用户讨论、营销分析文章等不同来源。
+- **记录元信息**：为每条素材记下来源、渠道、大致投放时间、广告形式（图文/视频/轮播）、可见的互动或投放持续情况，作为"是否是主推/长青广告"的旁证。
+
+注意：只收集平台公开展示的广告与营销信息；无法获取的（如真实投放预算、精确受众设置、内部数据）不臆测，标注为不可得。
+
+### 3. 结构化提取
+
+对每一条（或每一组）广告，按统一维度拆解，保证可横向对比：
+
+- **钩子（Hook）**：开头 3 秒/首行如何抓注意力——痛点、提问、反常识、数字、身份认同、好奇缺口等。
+- **核心卖点**：主打的价值主张是什么（省钱/省时/效果/身份/风险规避），一条广告的主卖点通常只有一个。
+- **目标受众**：从文案口吻、场景、痛点反推其瞄准的人群画像（身份、阶段、痛点、动机）。
+- **创意角度（Angle）**：切入同一卖点的叙事框架——恐惧诉求、before/after、用户证言、权威背书、对比竞品、稀缺/紧迫等。
+- **CTA**：行动号召的措辞与强度（立即购买 / 免费试用 / 领取优惠 / 了解更多），以及配套的优惠或紧迫感设计。
+- **创意形式**：图文/短视频/UGC 风格/达人口播等表现形式与视觉调性。
+- **落地页衔接**：广告承诺与落地页首屏是否一致，落地页如何承接并推进转化（表单/购买/预约），转化路径长短。
+
+对拿不准的推断（如受众、投放意图）标注为"推测"，与可直接观察到的事实区分开。
+
+### 4. 对比分析与洞察
+
+把结构化提取的结果汇总成对比，从中提炼可行动的洞察：
+
+- **横向对比**：把各竞品放在同一张表里，对比钩子类型、主卖点、角度、CTA、优惠机制，一眼看出各家打法异同。
+- **模式识别**：找出反复出现的共性打法（多家都在用的钩子/角度/卖点），这通常是被市场验证过的有效套路。
+- **空白与差异化**：识别无人主打的卖点、无人覆盖的人群、无人用的角度——这是差异化机会。
+- **可借鉴 vs 需规避**：明确哪些打法值得测试借鉴（并说明如何适配到自身产品），哪些是踩坑或不适合自身定位的。
+- **落地建议**：给出具体、可执行的下一步，如"可测试的 3 个新钩子""建议补强的落地页首屏主张""值得抢占的差异化卖点"。
+
+洞察要落到"我方能做什么"，而非停留在描述对手。
+
+## 输出格式
+
+默认交付**对比表 + 洞察小结**两部分：
+
+- **竞品广告对比表**：每行一个竞品（或一条代表性广告），列为 渠道 / 钩子 / 核心卖点 / 目标受众 / 创意角度 / CTA / 落地页要点 / 备注（来源与投放线索）。
+- **模式与洞察**：分点总结共性打法、市场空白、差异化机会。
+- **可借鉴清单**：按优先级列出可测试的具体动作，每条说明借鉴点与适配方式。
+- **来源附录**：列出所收集素材的来源/链接与观察时间，保证可追溯。
+
+如用户需要，可对单个重点竞品做深度拆解（逐条广告 + 落地页），或输出为可复用的分析模板。
+
+## 边界与注意事项
+
+- **只用公开信息**：仅分析平台公开展示的广告与营销页；不获取、不臆测竞品的内部数据（真实预算、精确受众、后台配置、转化率），此类信息标注为不可得。
+- **区分事实与推测**：可直接观察到的（文案、CTA、形式）为事实；受众、投放意图等反推内容明确标为推测。
+- **不编造**：无法找到素材时如实说明，不虚构广告内容或数据；缺口用占位符标注（如 `[未找到该品牌 TikTok 投放素材]`）。
+- **合规借鉴**：借鉴的是策略与创意角度，不照抄受版权/商标保护的文案与素材；提醒用户避免误导性宣传与侵权。
+- **时效性**：广告投放变化快，标注素材的观察时间，说明结论反映的是某一时点的情况。