菜单
Use when independently reviewing retikz docs pages or docs diffs for page-type structure, reader clarity, source-backed API claims, demo coverage, bilingual parity, and navigation integrity.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
Use when changing any retikz apps/docs content, route data, i18n, demo, SourceLinks, or schema reference before loading the matching page-type skill.
Use when retikz needs multiple independent LLMs to review the same fixed code, ADR, implementation plan, test contract, commit, or working-tree snapshot before a gate or delivery decision.
Use when an Alpha ADR needs a pre-implementation capability gate, or a Beta milestone needs code-based completeness and package-boundary auditing.
Use when planning a retikz architecture direction, version roadmap, or alpha feature that may need a long-lived ADR before implementation.
Use when retikz work is primarily refactoring, reorganization, renaming cleanup, modularization, or internal simplification and should start from a reviewed implementation plan before code changes.
Use when retikz implementation, adversarial testing, and docs are complete, and an ADR or beta TODO needs changelog, contract consistency review, roadmap status updates, or final human acknowledgement.
| name | docs-doc-review |
| description | Use when independently reviewing retikz docs pages or docs diffs for page-type structure, reader clarity, source-backed API claims, demo coverage, bilingual parity, and navigation integrity. |
本 skill 是 retikz 文档站的独立审稿人。它不替代写作 skill，而是在写完之后从读者角度挑问题：页面是否好读、结构是否对、demo 是否足够、进阶内容是否放在该放的位置。
develop-document 阶段完成后，进入 wrapup 前docs-doc-principle / docs-doc-component / docs-doc-extension / docs-doc-example / docs-doc-group 产出初稿后普通文档审查可以由主 AI 直接执行。新增页面或命中 docs-doc-principle“大改”条件时，必须由一个新的只读 subagent 在改稿与机械验证完成后独立执行；主 agent 自评不能替代。默认只评审、不改文件；用户明确要求“顺手修掉”时，才按评审结果改稿。
至少给出一个：
apps/docs/src/modules/docs/contents/**/index.{zh,en}.mdxgit diff -- apps/docs/src/modules/docs/contents apps/docs/src/modules/docs/data apps/docs/src/i18n*.demo.tsx若评审的是功能性改动，先读相关现有文档，不只看新文件。读不到实际功能改动时，要把判断标成“基于文档本身”，不要假装验证了实现。
docs-doc-component 的 5 类 section 顺序：Usage / Examples / How it works / API Reference / Relateddocs-doc-extension：适用边界 / 定义 / 注入 / 执行机制 / 错误与限制 / API / 相关，并证明内置与自定义同路docs-doc-example 的 6 段结构：引言 hero / Prompt / 过程 / 能力 / Limitations / Relateddocs-doc-group：分组介绍 + 职责表 + LinkedCard 子页索引<ZodSchema> 是否用 descriptions 覆盖全部字段与匿名对象点路径；只有顶层 description、字段仍回退英文 .describe() 均不算完成.describe()，不重复维护 descriptions默认读者是初级前端工程师：会 React / TypeScript 基础，但不熟 TikZ、IR、Scene、编译器、几何算法和项目历史。
检查：
ComponentAlert / tip / How it works 标出，并提示初次阅读可跳过frontmatter.description 是否能脱离页面独立说明根问题与核心职责或使用入口，供 manifest / llms.txt 直接作为机器摘要使用<Comparison target="tikz"> 或页面支持的 reference / 对照组件，而不是散落在正文<ComponentPreview files="..." />docs-doc-control 的契约、取景、极值、Reset、caption、视觉层级和真实页面验证；本 skill 不复制其检查项ComponentPreview 按需契约<ComponentPreview hideCode />）contents/、data/、i18n/ 是否同步先运行 docs-doc-principle/scripts/check-doc-integrity.mjs --scope <scope>，不要人工重复可机械检查的双语配对、站内路由/锚点、demo 文件和 SourceLinks 行号。评审者继续负责脚本无法判断的部分：链接语义是否正确、SourceLinks 是否覆盖真正决策分支、HTTP(S) 目标是否仍匹配正文、zh/en 含义是否一致。
结构、内容和链接检查完成后，必须打开真实 docs 页面再下结论。运行在 Codex desktop 时，优先在应用内浏览器侧边栏打开目标路由，以实际侧栏宽度检查窄屏阅读；条件允许时再补常规桌面宽度。
检查：
根据真实效果判断是否继续优化：影响理解、遮挡内容、交互不可达或核心 demo 难以辨认记为 BLOCKING；层级、密度、留白或构图仍可改善但不妨碍使用记为 WARNING。不要只凭源码、截图尺寸或测试通过宣称视觉通过，也不要为没有读者收益的纯主观微调扩大范围。
若浏览器或本地 dev 环境不可用，明确写“视觉复核未执行”及原因；此时可以给出结构评审结论，但不能宣称完整视觉通过。
按严重度输出，先问题后总结：
BLOCKING（必须修）：
- [结构] apps/docs/src/modules/docs/contents/.../index.zh.mdx:42
问题：...
为什么影响读者：...
建议：...
WARNING（建议修）：
- [读者视角] ...
INFO（做得好的地方 / 可保留）：
- ...
建议补充的 demo / 图示：
- ...
视觉复核：
- 已执行：Codex 侧边栏 / 桌面宽度；通过 / 需优化
- 可继续优化：... / 无
结论：
- 通过 / 不通过
严重度判定：
<ZodSchema> 字段缺少翻译而回退英文、API / demo 与实际行为冲突、必要 demo 缺失、核心职责或边界缺失导致读者无法理解主线、链接 404 / 锚点失效 / 源码路径或行号错误每个读者视角问题都要定位到首次造成困难的位置，并给出可执行的替代表达、补充解释或章节移动建议；不要只写“术语太多”“顺序不好”。
<SourceLinks> 行号仍有效