用途：这是 PostHog Review（PostHog 的自动 PR 审查器）自定义技能的编写指南。PostHog Review 会把 PR 拆成多个 chunk，对每个 chunk 并行运行所有启用的 perspective（独立专家视角），随后做一次 blind-spot check（基于已发现问题的最终扫描），再用一个 validation criteria 技能判定每个候选发现，只有通过者才发布到 PR。发布后进入 resolution 阶段，对未解决的 review thread 逐一按 resolution criteria 判定，值得且安全的请求会在 PR 分支上实现，每个 thread 都会得到回复。
四类技能均为团队级 LLMSkill，审查代理在运行时通过 MCP 拉取。命名约定：perspective 为 review-hog-perspective-<slug>（可多启用，至少保留一个）；blind-spot check 为 review-hog-blind-spots-<slug>（仅一个生效，选择即替换）；validation criteria 为 review-hog-validation-<slug>（仅一个生效）；resolution criteria 为 review-hog-resolution-<slug>（仅一个生效）。
编写流程：先用 PostHog MCP 的 skill-list 列出团队的 review-hog-* 技能，并用 skill-get 获取对应类型的 canonical 作为结构与语气参考；perspective 还需浏览现有 perspective 描述以避免重复覆盖。随后访谈用户确定方向，再按各类型指引起草正文，并用 posthog:skill-create 实际创建团队 LLMSkill 行（不要交给用户复制粘贴），名称须符合上述约定。需要修改时用 posthog:skill-update 迭代。应全新编写，不要 skill-duplicate canonical 再编辑，因为种子元数据会随副本保留，canonical 同步可能覆盖或删除它。
激活：自定义技能默认对用户不激活。perspective 需在 Inbox → Code review → Perspectives 中开启；blind-spot check、validation criteria、resolution criteria 需在对应区域选择，同一时间只运行一个，选择会替换当前项。审查在运行开始时固定技能版本，因此审查中途的编辑从下一次运行生效。
正文写法：perspective 正文针对一个 PR chunk 做一次专家审查，包含 lane（职责一句话）、hunting grounds（若干具体检查点）、lane boundary（相邻关注点归属哪个 perspective）、finding bar（可发布发现需给出具体触发与后果，并以完成标准收尾）。blind-spot check 正文指导最终扫描，基于已覆盖发现利用负空间（错误路径、未处理输入、跨文件交互、假设），不限于单一专业，空结果优于凑数。validation criteria 定义发布前的保留/丢弃标准，默认精确优先于召回，需说明何为真实且值得关注、何为丢弃、如何处理不确定（默认丢弃），并要求基于实际代码库证据。resolution criteria 定义对未解决 thread 的判定标准：值得实现且可无人值守安全实现者才实现，其余给出理由拒绝或升级人工；硬性底线由框架负责，自定义技能只能收紧、不能放松。
限制：资料未提供具体收费、价格、平台支持范围或效果数据。