菜单
对 `versions/` 下已生成的简历版本做质量评审，从 STAR 完整度、量化比例、关键词对齐、长度、结构等维度给出具体、可操作的改进建议。使用场景：用户说「评审我的简历」「帮我看看这份简历」「这份还能怎么优化」「跟 JD 对照检查一下」「为什么这个简历一般」等。评审不直接改文件，只产出建议清单，由用户决定是否应用。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
管理本地 Markdown 简历素材库。帮用户在工作目录下收集、更新、整理简历原始材料（工作经历、项目、教育、技能、亮点）。使用场景：当用户提到「简历」「CV」「resume」「求职」「工作经历」「我在 X 公司做过」「我做过一个项目」「整理我的素材」等；或者用户希望把零散的职业信息结构化地存到本地 Markdown 以便后续生成不同版本的简历。**第一次在一个项目里被调用时会自动检测并引导用户初始化目录结构，用户无需显式调用 init**。
针对某个目标岗位，从本地素材库生成一份定制化的简历 Markdown，落到 `versions/` 下。使用场景：用户说「帮我针对这个岗位写简历」「给 Google SWE 生成一版」「根据这份 JD 定制简历」「基于 targets/xxx 生成」「做一版投递用的简历」等。前置依赖 `muicv-core` 维护的素材库；如果还没有素材或 target，应该先提示用户去 muicv-core 初始化 / 添加素材。
把 `versions/` 下的简历 Markdown 渲染成 PDF，调 Mui简历后端 API 完成渲染（后端跑 Cloudflare Container + Puppeteer）。使用场景：用户说「把简历导出 PDF」「渲染简历」「把这份版本变成 PDF」「下载一版投递用的 PDF」等。依赖 `muicv-generate` 生成的 version 文件；依赖网络（要调 HTTP API）。
把简历素材库放到用户自己的 git 仓库（GitHub / GitLab / 自建均可），用 git workflow 多端同步、留版本史、可分享。四个子任务：`init`（首次给素材库加 .git + .gitignore + 远程关联，**会问用户 public/private**）、`sync`（commit 当前改动并 push 到远程）、`clone`（换机器场景，把已有 repo 克隆到工作目录）、`status`（看本地状态）。使用场景：用户说「推到 GitHub」「git push 我的简历」「sync 到 GitLab」「从 GitHub 克隆我的素材」「换机器拉 git」「commit 一下」「git status」「我想用 git 管简历」「用 GitHub 当作品集」等。和 muicv-sync 是平行选项——后者是 muicv 平台 D1 黑盒（可加密）备份，本 skill 是用户掌控的 git workflow，可以同时用。
MuiCV 平台云同步——把本地素材库整体推到云端（push）或从云端拉回来覆盖本地（pull），默认走 zip 加密路径。两个子任务：`push` 把本地素材打包成 zip（用户给密码就 PKZip 加密、不给就明文）上传到 muicv 云端；`pull` 从云端把活动版下载到本地（自动备份冲突文件）。使用场景：用户说「同步到云端」「上传简历素材」「云同步」「备份到云端」「换了新机器，把素材拉回来」「从云端恢复」「下载我的简历」「pull 远程素材」等。需要在 https://muicv.com/dashboard 创建 mui_ API key 并 export 到 `MUICV_API_KEY`；需要网络；需要本地装有 `zip` / `unzip`（三大系统通常自带）。
录音复盘。用户拖一段已有录音（自己面试 / 客户沟通 / 演讲 / 答辩等）进 muicv，skill 调 STT 转写后按场景分析（STAR 完整度 / 表达冗余 / 填充词 / 时长 / 互动），把转写全文 + 分析写到 `audio-reviews/<source>-<date>.md`。触发词：录音复盘、分析这段录音、拖了一段音频、复盘音频、analyze recording、transcribe and review、聊天录音、客户沟通录音、演讲录音、答辩录音。仅 muicv 桌面 app 可用（需要本地文件读取）。
| name | muicv-critique |
| description | 对 `versions/` 下已生成的简历版本做质量评审，从 STAR 完整度、量化比例、关键词对齐、长度、结构等维度给出具体、可操作的改进建议。使用场景：用户说「评审我的简历」「帮我看看这份简历」「这份还能怎么优化」「跟 JD 对照检查一下」「为什么这个简历一般」等。评审不直接改文件，只产出建议清单，由用户决定是否应用。 |
对一份已经生成的简历做 结构化评审。核心产物是建议清单——不擅自改写用户的简历。
versions/ 里是否有简历？如果为空 → 提示先调 muicv-generate（路径相对素材库根）target？有 → 同时 Read 对应 target 做关键词对齐检查*.resume.json：只评 markdown 版本（JSON 跟 markdown 应该是同一份事实的两种格式）。
assertTemplateResumeData 在 render 阶段把关）按以下顺序评估，每个维度给出具体问题 + 建议。
P0 判定标准的唯一来源是 docs/p0-rules.md （三类 P0：SPEECH / FAB / KW-MISS）。本文件只负责评审输出格式和 P1 / P2 维度。 修改 P0 判定规则只改 docs/p0-rules.md，不要改这里。
muicv-generate 在写文件前已经跑过一轮 P0 自检（self_check: passed / partial）。 critique 的角色：
self_check: passed的版本：仍要复审（generate 自己评自己有 bias），重点在 P1 / P2self_check: partial的版本：generate 已经把无法自动修正的 P0 写在交付摘要里， critique 要确认这些条目并给出具体补素材建议
判定标准见 docs/p0-rules.md 的 SPEECH 章节。 扫每条 highlight：
修正建议直接套 docs/p0-rules.md 的"修正动作"小节里的实动词替换表。
「量化」= Action 之后产出的 outcome 指标（成果/效率/收益变化），不是 scope/编制/时长/件数。 ✅ 转化率 +12% · 退货率 8%→3% · P75 800ms→320ms · GMV ¥80k→¥260k · 排名 #1（绑结果） ❌ "覆盖 3 个站点" · "带 4 人团队" · "维护 30+ 仓库" · "做了 3 年"——这些是 scope，写进 Action，不要单独标"量化" 素材里没有 outcome 数字时，保留定性描述，不要为了凑量化而编数字、也不要把 scope 升格成量化。 完整定义见 docs/quantification-guideline.md。
P1 部分——量化比例统计：
P0 部分——编造检测（FAB），判定标准见 docs/p0-rules.md 的 FAB 章节：
source_files 比对，对不上 → P0检查每条 highlight 是否有：
常见问题：
判定标准见 docs/p0-rules.md 的 KW-MISS 章节。
missing_keywords，
在评审报告里复述并强调"未编造，符合规则"必须用 write_file 工具写到 critiques/<version-name>-<YYYY-MM-DD>.md
（相对素材库根，公约见 prelude）。<version-name> 取被评审 version 文件的
basename 不含扩展，例如评审 versions/google-l5-2026-04-24.md → 写到
critiques/google-l5-2026-04-24-2026-04-28.md。
不要在对话里粘整份评审报告——只在对话里给一句结论 + 路径，详情让用户去 右栏预览。
文件内容用这个结构：
---
type: critique
version: versions/<file>.md
target: targets/<file>.md # 如有
generated_at: <ISO>
---
# 评审报告：versions/<file>.md
**整体评估**：<🟢 良好 / 🟡 可改进 / 🔴 需要重做>（给出一句话理由）
## 维度评分
| 维度 | 评价 | 简评 |
|---|---|---|
| 事实完整度 | 🟢/🟡/🔴 | … |
| 量化比例 | 🟢/🟡/🔴 | X 条里 Y 条带数字 |
| STAR 结构 | 🟢/🟡/🔴 | … |
| 关键词对齐 | 🟢/🟡/🔴 | JD 要 A/B/C，简历覆盖 A；B 缺，C 有 |
| 长度密度 | 🟢/🟡/🔴 | 总长 ~ N 字，预估 ~ X 页 |
| 排序结构 | 🟢/🟡/🔴 | … |
| 表达质量 | 🟢/🟡/🔴 | … |
## 具体问题（按优先级）
### P0（影响录用决策）
1. **<问题简述>**
位置：`## 工作经历 > ACME Corp > 第 2 条`
现状："负责前端开发工作"
建议：这是典型的空话 highlight。考虑改成具体的动作 + 结果，比如你素材里写的 "主导 dashboard 重构"（见 `experience/acme-2023.md`）就更有力。
### P1（明显可改进）
…
### P2（润色）
…
## 可能需要补素材
如果以下内容在素材里找不到但对这个 JD 很重要，考虑用 `muicv-core` 补充：
- <关键词> — JD 里出现 N 次，素材里未找到
- …
## 下一步
- 如需我按上述建议修改简历，告诉我 "按 P0 改" 或具体说"改第 N 条"
- 如需重新生成整份，调 `muicv-generate`
- 如需补素材，切到 `muicv-core` 的 add-experience / add-project / update