菜单
代码品味提炼工作流。系统性地审查项目代码，按业务重要度、复杂度、可扩展性、性能要求 四个维度分优先级分组，引导用户 review 后提炼出个人代码品味和编程偏好。 当用户提到"代码品味"、"code taste"、"提炼品味"、"review代码品味"、 "梳理代码理念"、"总结编码偏好"、"记录代码审美"时触发。 即使用户只是说"帮我 review 一下代码质量"或"看看这代码写得怎么样"， 如果语境偏向品味和偏好而非找 bug，也应使用此技能。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | code-taste-review |
| description | 代码品味提炼工作流。系统性地审查项目代码，按业务重要度、复杂度、可扩展性、性能要求 四个维度分优先级分组，引导用户 review 后提炼出个人代码品味和编程偏好。 当用户提到"代码品味"、"code taste"、"提炼品味"、"review代码品味"、 "梳理代码理念"、"总结编码偏好"、"记录代码审美"时触发。 即使用户只是说"帮我 review 一下代码质量"或"看看这代码写得怎么样"， 如果语境偏向品味和偏好而非找 bug，也应使用此技能。 |
通过多轮 review 会话，逐步提炼用户在编码风格、架构选择、抽象层次等方面的个人品味。 品味不是一次性产出的——每次 review 沉淀一小部分，最终积累成完整的编码哲学。
~/.codetaste/
├── essence.md # 跨语言根本原则（四条元原则）
├── <lang>/
│ ├── taste.md # 按语言沉淀的品味索引（原则/偏好/反模式）
│ ├── principles.md # 原则详细描述
│ ├── preferences.md # 偏好详细描述
│ ├── anti-patterns.md # 反模式详细描述
│ └── lint/ # 自动化检查脚本
│ ├── check.sh # 总入口
│ ├── init-lint.sh # 项目集成脚本
│ └── rules/ # 具体规则脚本
├── review/
│ └── <yyyy-MM-dd>/ # 每次会话一个目录
│ ├── session.json # 会话元数据
│ ├── file_inventory.md # 项目文件清单 + review 状态
│ ├── groups.md # TOP 3 分组索引
│ ├── my_review.md # 用户 review 记录（用户填写）
│ └── taste_extracted.md # 本次提炼结果
└── bin/ # 工具脚本
├── update-inventory.sh # 从 session.json 更新 file_inventory.md
└── migrate.sh # 旧路径迁移工具
以下模板位于 skill 目录下的 templates/ 中，创建新会话时参照：
用户触发此技能时，先判断当前处于哪个阶段：
my_review.md扫描当前项目目录的所有源代码文件。
包含：src/、lib/、app/、internal/、cmd/、pkg/ 等业务代码目录下的源文件。
排除：node_modules/、dist/、build/、vendor/、.git/、__pycache__/、测试 fixture、生成的代码（如 *.generated.*、*.pb.go）、锁文件、配置文件（如 webpack.config.*）。
对每个文件记录：相对路径、语言、行数（大致）。
扫描 ~/.codetaste/review/ 下所有已有目录，读取每个 session.json 和 file_inventory.md，汇总哪些文件已被 review 过以及最后 review 日期。
日期冲突处理：如果今天日期的目录已存在，追加序号 -2、-3。
创建 review 目录，参照 session.json 模板 写入 session.json。
参照 file_inventory.md 模板 生成文件清单。
对 未 review 的文件 按 4 个维度评分（1-5 分）：
| 维度 | 权重 | 评估依据 |
|---|---|---|
| 业务重要程度 | 0.3 | 模块在核心请求链路中的位置、被依赖的数量 |
| 代码复杂程度 | 0.2 | 逻辑分支密度、函数长度、嵌套深度 |
| 可扩展性要求 | 0.3 | 未来变更的可能性、配置化程度、接口抽象度 |
| 性能要求 | 0.2 | I/O 密集度、数据处理量、延迟敏感度 |
综合得分 = Σ(维度分数 × 权重)，按得分降序排列。
选出 TOP 3 分组，每组 4-5 个文件。分组时考虑文件的逻辑关联性（同模块、同层的文件归为一组），而非单纯按分数切割。
参照 groups.md 模板 写入。
完成步骤 4 后，进入阶段二。
将 groups.md 的内容呈现给用户。告知用户：
my_review.md，写入 review 意见Review 文件路径约定：用户可以逐组写 review，也可以全部写在一个文件中。支持的写法：
my_review.md 中group1.md、group2.md、group3.md，再加上 my_review.md（额外 review 的文件）my_review.md 是自由格式的文档。用户可以写任何想说的，例如：
等待用户明确表示"写完了"、"提炼品味"后再进入阶段三。
my_review.md、group*.md 等）| 品味维度 | 关注点 |
|---|---|
| 结构与组织 | 文件组织、模块划分、依赖方向、层次分离 |
| 命名品味 | 变量、函数、类的命名风格，语义表达力 |
| 错误处理哲学 | 异常策略、错误传播、降级方案、日志记录 |
| 抽象层次 | 何时抽象、抽象粒度、接口设计 |
| 性能意识 | 在何处关注性能、如何权衡性能与可读性 |
| 可读性标准 | 注释风格、代码密度、表达力、一致性 |
| 测试态度 | 测试策略、覆盖偏好、mock 与真实的选择 |
按三级分类组织：
标注理由和来源
读取 ~/.codetaste/<lang>/taste.md（以及 principles.md、preferences.md、anti-patterns.md），将提取结果与已有条目交叉比对：
在 taste_extracted.md 底部增加去重检查表，记录每条提取结果与已有品味的对比。
读取 ~/.codetaste/essence.md，验证本次提取的所有品味条目能否归入已有的元原则（通常为四条）。
四条元原则：
对每条品味条目：
将验证结果追加到 taste_extracted.md。
同步更新 essence.md：
将去重后的新品味合并到 ~/.codetaste/<lang>/ 下的对应文件：
taste.md — 更新索引（添加新条目，更新 Lint 列链接）principles.md — 新增原则preferences.md — 新增偏好anti-patterns.md — 新增反模式品味文档格式：
# <Language> 代码品味
> 最后更新：yyyy-MM-dd | 累计 review 次数：N
## 原则
### [P1: 原则名称]
**来源**: review/<date> | **强度**: 不可违背
<原则描述>
**正例**: <代码片段>
**反例**: <代码片段>（如果有）
## 偏好
### [B1: 偏好名称]
**来源**: review/<date> | **强度**: 推荐
<偏好描述>
**注意**: <例外情况>（如果有）
## 反模式
### [A1: 反模式名称]
**来源**: review/<date> | **强度**: 避免
<反模式描述>
**反面示例**: <代码片段>
对本次提炼的品味条目，评估自动化可行性。可自动化项的标准：
对可自动化项：
~/.codetaste/<lang>/lint/rules/ 下创建对应检测脚本~/.codetaste/<lang>/lint/check.sh 总入口，添加新规则taste.md 的对应条目中添加 Lint 列，链接到脚本脚本要求：
set -euo pipefail + export LC_ALL=C（确保 macOS 正则兼容）变量=$((变量 + 1)) 而非 ((变量++))（避免 set -e 误杀）--warn / --error 阈值参数LEVEL: file:line message提炼完成后更新状态：
{
"status": "completed",
"files_reviewed": ["src/proxy/openai.ts", "..."]
}
运行 bash ~/.codetaste/bin/update-inventory.sh <review目录> 自动更新 file_inventory.md。
当用户问进度时：
~/.codetaste/review/*/session.jsonfile_inventory.md垂直领域搜索和批量并行搜索。当通用搜索（tavily）无法满足时使用。 触发场景： 1. 金融数据——股票代码、汇率、行情（finance.us_stock / cn_stock / forex） 2. 学术检索——论文、DOI（academic.search / academic.biomedical） 3. 安全漏洞——CVE、文件哈希、IP/域名扫描（security.scan / security.cve） 4. 法律、专利、教育、健康等其他垂直领域 5. 批量并行搜索——同时查 2-5 个独立问题 6. 中国国内信息——A 股、国内资讯（需 zone=cn） 触发词："股票"、"行情"、"汇率"、"CVE"、"漏洞"、"论文"、"DOI"、 "学术"、"专利"、"批量搜索"、"A股"、"anysearch"。 不触发场景：通用 web 搜索、新闻浏览、代码搜索、网页内容提取、网站爬取—— 这些由 tavily skill 处理。
Use when starting a new Remotion video project, adding scenes to an existing video, or converting a script into a video. Handles creative direction, script review, scene planning, pronunciation pre-check, segment-based voiceover generation, subtitle-based timeline calculation, and produces a complete design spec. Required before remotion-video-development. Also handles voiceover generation and timeline alignment via remotion-tools scripts.
Use when implementing Remotion video scenes from an approved design spec. Executes scene-by-scene with flex-first layout, subtitle-based timing, multi-segment audio playback, and per-scene verification. Requires completed design from remotion-video-design. Also use when regenerating voiceover segments, fixing pronunciation, or re-aligning timeline.
思维框架，帮助跳出局部修补的循环。两种触发模式。 模式一（用户主动）：当用户说"rethink"、"重新思考"、 "跳出来看"、"全局视角"、"这个问题我们是不是想错了"时加载， 直接进入完整分析。 模式二（AI 提议）：当你检测到以下信号时， 在回复末尾加一句提议 "我觉得我们可能在局部修补，要不要退一步重新看？"： 你对同一个文件做了 3 次以上修改仍未解决， 或用户连续 2 次否定你的方案， 或你发现方案里 workaround 和 edge case 越来越多。 用户同意后再执行完整分析。用户说不用则继续正常工作。
本地语义代码搜索。当需要按意图定位代码、查找实现、理解代码结构时使用，优先于 grep/read 用于探索性搜索。触发词："搜代码"、"code search"、"find implementation"、"理解代码实现"、"semble"、"语义搜索"、"search code"。
通用 Web 搜索、URL 内容提取、网站爬取。这是默认的搜索工具。 当用户需要：快速查事实、搜索新闻、fact-checking、提取网页内容、 爬取网站、深度研究（advanced 模式）时使用。 触发词："搜索"、"查一下"、"搜一下"、"lookup"、"search"、"research"、 "fact-check"、"联网搜索"、"查资料"、"提取网页"、"爬取网站"、 "tavily"、"网页内容"。 不触发场景：股票/金融数据查询、学术论文检索、CVE/安全漏洞查询、 批量并行搜索——这些场景由 anysearch skill 处理。