使用方法
- 复制安装命令，在自己的智能体环境安装前先检查源码包。
- 从原始文档核对所需工具、凭据和支持的宿主。
- 说明输入材料与期望交付物，并对照来源检查输出。
npx skills add https://github.com/bostonaholic/skills --skill reviewing-design-docs开始前需了解
- 安装不包含模型订阅、API 额度或访问文件的权限。
- 仓库星数和安装量反映活跃情况，不等于独立质量或安全测试。
按源仓库内容呈现，保留标题、案例、代码、表格、链接以及原文引用的演示图片。
Engineering Design Doc Review
Input
$ARGUMENTS is the path to one design document. When it is a URL or pasted text, save it as Markdown in a scratch file outside the repository and review that path; when a fetch fails, report the URL and the error. When the argument is empty, names a directory, or names no readable file, ask for the path and wait. Never guess.
Reviewer
This session holds the author's conversation, so it cannot review the document (independent review rules). Run the design reviewer brief in a fresh-context subagent with read and search tools only, giving it the document's absolute path and the paths of the files the brief links: design template, finding format, and decision-record rules. Pass no author discussion. If no such subagent can run, stop and say so. Never review inline.
Verdict and relay
The report's first line must be exactly **Verdict: APPROVE**, **Verdict: REQUEST CHANGES**, or **Verdict: COMMENT**. When it is missing or wrong, run one new reviewer with the same inputs and name the failed contract. When the second report also fails, print it, name the failure, and stop. Never repair a verdict yourself.
Print the report verbatim. When the read-only restriction rested on the reviewer's prompt rather than its tool grants, say so in one line after the report. Do not revise the document; on REQUEST CHANGES the user decides how. Write no file beyond the scratch copy.
