把规范写成 Skills：能修则修，查不了要报

有条工程实践值得拆：作者把自家 Marketplace 的规范做成了三个 Agent Skills（模板、组件、商品页三类），机制一句话说清——能修的直接修，查不了的如实告诉你、留给你自己处理；原帖带了构建内幕和 remix 链接。 两层一，接 62137 数据库权限三档那条 = 工具层信任的第二块拼图：那条管"让它做到哪一步"，这条管"做完之后敢不敢信"——把"能修/不能查"写成显式输出，等于让 agent 自带验收边界，人只需要看它报告的缺口，不用全量复检。 二，"规范转 Skills"是个可复制的路径：审查规范天天写、人看得到做不到的地方多——与其让 agent 猜标准，不如把清单编译成能执行的 skill，逐条打勾、逐条上报；接 62285 那条"语义写进文件"，同一件事的两面：把规则从文档变成 agent 读得懂、跑得动的形态。 口径：①三类 skill 与其原帖表述（我没装这些 skill 实测）；②链未解析、以原帖分享为准；③"验收边界/编译"是我的引申；④修复范围其帖原话为"能修则修、不能查则报"。 要用的两条：一，有审查清单的团队——照它把规范编成 skill，第一版只做"检查＋上报"就已省一半人工；二，做 skill 的作者——输出里显式列出"我没查到什么"，比假装全查过更值得被安装。 agent 的边界感不是天生的，是被"查不了要报"这句话训练出来的——自己写的 skill 有没有如实报缺口，这个问题值得当场检查。