菜单
Author-triggered fresh-context scan of PR diff before formal review. Finding generator, NOT approval authority. Use when: quality-gate 通过、PR 非 trivial、想降低正式 reviewer 认知负荷。 Not for: 正式 review verdict、approval、merge decision。 Output: Finding list（附在 review request 中）。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | fresh-context-review |
| description | Author-triggered fresh-context scan of PR diff before formal review. Finding generator, NOT approval authority. Use when: quality-gate 通过、PR 非 trivial、想降低正式 reviewer 认知负荷。 Not for: 正式 review verdict、approval、merge decision。 Output: Finding list（附在 review request 中）。 |
| triggers | ["fresh context","pre-review scan","找新眼看看"] |
SOP 位置: 可选步骤，在
quality-gate(Step ②) 之后、request-review(Step ③a) 之前。 SOP definition:sop-definitions/development.yamlstagefresh_context（optional）。 上一步:quality-gate| 下一步:request-review
在正式 cross-cat review 前，用一个 fresh-context session（没参与开发的猫或 author 的新 session）扫一遍 PR diff，产出 finding list。目的是降低正式 reviewer 的认知负荷——reviewer 可以先看 fresh-context findings 再看 diff，节约时间聚焦深层问题。
This is a FINDING GENERATOR, not an approval authority.
| PR 类型 | 触发？ | 理由 |
|---|---|---|
| 多文件代码改动（≥3 files, ≥50 行 diff） | ✅ 推荐 | 正式 reviewer 认知负荷高 |
| shared/ 或跨包改动 | ✅ 推荐 | 影响面广，early detection 价值高 |
| 状态机 / 生命周期对象改动 | ✅ 推荐 | 转移边容易漏（F229 教训） |
| 纯文档 / ≤10 行 / typo | ❌ 跳过 | 认知负荷已经很低 |
| SKILL.md-only | ❌ 跳过 | 轻量改动，正式 reviewer 足以覆盖 |
| 紧急 hotfix | ❌ 跳过 | 时间约束优先 |
决策权在 author：表格是建议，不是硬规则。Author 自判是否需要 fresh context。
不同模型族有不同的系统性盲点：
| 条件 | 检查方式 | 未满足时 |
|---|---|---|
quality-gate 已通过 | 有本轮 gate report | 先跑 quality-gate |
| PR diff 存在 | git diff origin/main...HEAD 有输出 | 没改东西不需要 review |
| Author 判断需要 | 查触发决策表 | 跳过，直接进 request-review |
1. Author 完成开发，quality-gate ✅
2. Author 判断是否需要 fresh-context（查触发决策表）
3. 需要 → Author 触发 fresh-context session（见下方 "如何触发"）
4. 不需要 → 直接进 request-review
方式 A: @ 另一只猫（推荐 — 盲点正交性更高）
在当前 thread @ 一只没参与开发的猫，附上 diff 和 spec：
@{reviewer-handle}
请帮忙做一次 fresh-context pre-review scan：
Branch: {branch-name}
Diff: `git diff origin/main...HEAD`
Spec: `docs/features/F{NNN}-xxx.md`
Plan: `feature-specs/YYYY-MM-DD-xxx.md`
只需要产出 finding list，不需要 verdict。
格式见 cat-cafe-skills/fresh-context-review/SKILL.md "Finding List 格式"。
优先跨 family（Ragdoll写的 → @ Maine Coon扫）。 同 family 不同个体也可（opus 写的 → @ sonnet 扫）。
方式 B: Author 自己的新 session（降级方案）
如果没有其他猫可用，author 可以在一个全新的 session 中自己扫——关键是 fresh context（新 session 没有开发过程的上下文污染）。
注意：方式 B 的盲点正交性为零（同 model 同 prompt），finding yield 预期低于方式 A。
收到 author 请求后：
git diff origin/main...HEAD）## Fresh-Context Findings
Agent: {cat signature}
SHA: {HEAD short sha}
Scope: {N} files, {M} lines changed
| # | File | Line | Category | Finding | Severity |
|---|------|------|----------|---------|----------|
| FC-1 | src/foo.ts | 42 | correctness | 边界条件未处理：`n < 0` 时返回 undefined | P2 |
| FC-2 | src/bar.ts | 18 | naming | 变量 `ctx` 与 spec 中的 `context` 不一致 | P3 |
| FC-3 | test/baz.test.ts | — | missing-test | 新增 `processItem()` 但无 error path 测试 | P2 |
Total: {X} findings ({Y} P1, {Z} P2, {W} P3)
---
*Finding generator only — not an approval authority. 正式 review verdict 由 request-review 流程中的 named reviewer 产出。*
Category 枚举: correctness / performance / naming / style / security / spec-mismatch / missing-test / doc
Severity 规则:
Author 收到 finding list 后：
fixed (commit {sha})dismissed: {理由}| 维度 | Fresh-Context | 正式 Review（request-review / receive-review） |
|---|---|---|
| 角色 | Finding generator | Approval authority |
| 产出 | Finding list | APPROVE / BLOCK verdict |
| 权力 | 零（建议性） | 完全（merge-gate 可识别） |
| 触发 | Author 主动 | request-review 流程 |
| Ownership | Author | Reviewer |
| 对 merge-gate | 不可见 | localPeerReviewSha / cloudReviewSha |
| Delta metric | 被度量方 | 度量方（标注 FC:covered / FC:new） |
| 错误 | 正确 |
|---|---|
| 把 fresh-context 当正式 review，跳过 request-review | fresh-context 只是预扫，正式 review 仍必须走 |
| Fresh-context agent 给 APPROVE verdict | 只给 finding list，不给 verdict |
| Reviewer 因为 fresh-context "已看过" 就简化 review | Reviewer 独立判断，fresh-context 是参考不是替代 |
| 所有 PR 都跑 fresh-context | 按触发决策表判断，trivial 跳过 |
| Fresh-context findings 产生 follow-up / TD / debt | Author 有最终决定权，dismissed = closed |
| Fresh-context scan 记入 Review Provenance Matrix | 不记入——它不是 review source |
Fresh-context findings 处理完 → 直接进 request-review（SOP Step ③a）。
在 review request 中附上 fresh-context findings 摘要（见 refs/review-request-template.md 的 "Fresh-Context Findings" section）。正式 reviewer 会用 FC:covered / FC:new 标注自己的 findings（见 receive-review skill "Reviewer Delta Annotation"）。
AI 生成动画短片生产线：图（关键帧锁确定性）→ 视频（i2v 给活气）→ 后期（剪辑做节奏）。 Use when: 做动画短剧/角色 IP 短片、猫咖日记系列新集、图生视频管线、剧情类 AI 视频。 Not for: 录屏/教程/showcase 视频（用 video-forge）、单张图生成（用 image-generation）、PPT（用 ppt-forge）。 Output: charter+分镜+prompt book+素材账本+EDL 驱动的成片，全程可复现可重渲。
富媒体消息发送：语音、图片、卡片、清单、代码 diff、交互选择。 Use when: 发语音、发图、发卡片、展示结构化信息、长结构化汇报、想发一堆文字/日志/步骤、庆祝、给我听听、给我看看、让用户选、确认操作。 Not for: 纯文字聊天、技术讨论、日常回复。 Output: rich block 附着在消息上。
视频制作全链路：素材入库 → 剧本冻结 → 全局配音 → 对齐 → 渲染 → 审查 → 交付。 Use when: 做视频、做 showcase、做教程视频、录屏剪辑、video review、节奏审查。 Not for: 纯代码开发（用 worktree/tdd）、纯文档写作（直接写）、PPT（用 ppt-forge）。 Output: schema 驱动的视频成片 + 多猫审查通过 + 可发布。
通过 Limb 体系操作微信公众号：发布文章、上传图片、管理草稿。 Use when: 需要发布内容到微信公众号、查看草稿、检查公众号连接状态。 Not for: 其他平台的发布、纯文本聊天、非公众号相关操作。 Output: 微信公众号操作结果（发布ID、草稿列表、图片URL等）。
Feature 立项、讨论、完成的全生命周期管理。 Use when: 开个新功能、new feature、F0xx、立项、feature 完成、验收通过、讨论新功能需求。 Not for: 代码实现、review、merge（那些有专门的 skill）。 Output: Feature 聚合文件 + BACKLOG 索引 + 真相源同步。
合入 main 的完整流程：门禁检查 → PR → remote review → Feature Doc Truth 核对(pre-merge) → squash merge → 记录已合入(post-merge) → 清理。 Use when: reviewer 放行后准备合入、开 PR、触发remote review、准备 merge。 Not for: 开发中、review 未通过、自检未完成。 Output: PR merged + worktree cleaned。