Skill创作发明家

Skill创建与质量门控，含55项10层审计模型。触发词：创建skill、skill创建、skill审计、质量审计。不适用：skill发布、生态体检（用mu-skill-auditor）

IRON LAW:1改完 Skill 必须完成全面审计（55项10层逐项确认；skill-audit.sh 仅是其中的脚本核验步骤），任何脚本绿灯、目测或专项复核均不得替代全面审计；2description 只给 Agent 读(触发器),intro 只给人看(Skill 市场简介),两者不可混用;3安全扫描未通过禁止交付,人员/组织/薪酬/职级信息禁止进任何 Skill 文件;4IRON LAW 必须是该 Skill 的业务专属约束,禁止只写行数/凭据等通用套话;5行数以效果为第一原则,≤300行是预算上限不是拆分目标——禁止为了让数字好看而拆分,只有"拆分后仍能一次执行不降级"才可以拆,拆完必须验证拆分后指令仍可被完整执行,做不到就保留超行数也不拆(L1-5行数项优先级低于L2-1逻辑闭环/L10-1可验证性)。

§1 Motivation：为什么需要这个 Skill

Skill 质量劣化有三个系统性失效模式，所有规则都针对它们：

1. 规则遗忘——小改动不检查→质量劣化在缝隙中发生。根因：没有强制审计闭环，"目测没问题"成了默认行为。
2. 规则冲突——新增规则与旧规则矛盾→Agent 执行时选错。根因：规则分散无全局校验，改一处忘同步另一处。
3. 规则膨胀——什么都想管→300行溢出→有效指令被挤出 context。根因：缺少拆分约束和优先级判断，"写了=管了"的幻觉。

三条共同根因：缺少工程脚手架，不是 Agent 能力不足。每条规则都应可追溯到「哪次事故催生了它」。

§2 生态分工

Skill	职责	何时用它
mu-skill-auditor	诊断：六模块体检 + 降本决策	skill体检/预算/僵尸/description超胖
mu-skill-creator	创作：新建/优化 Skill 内容	要写新 Skill 或改 SKILL.md 正文
mu-skill-shrimp	发布：Skill 市场上架/安装/卸载	要发布、安装、更新 Skill
mu-skill-hunter	搜索：外部 GitHub/ClawHub 发现	要找外部没安装过的 Skill
mu-self-tuning	策略：整体 token 降本 + 工作区养护	要制定降本计划/全局评分

§3 核心设计决策

三决策解释了「为什么用这个架构」，每条对抗至少一个失效模式：

1. 三层模型 > 单文件——L1(description)始终加载、L2(SKILL.md≤300行)激活时加载、L3(references/)按需加载。WHY：控制 context 膨胀，对抗规则膨胀（失效3）。

层级	内容	预算	加载时机
L1	触发词 + 使用/跳过条件	~100词	始终
L2	工作流、原则、速查表	≤300行	激活时
L3	详细文档、schema、示例	不限	按需read

L1：唯一触发机制，倾向"宁多触发别漏"(漏触发=Skill不存在，误触发可纠正) L2：≤300行(官方建议500，取300留余量)，引用仅一级(WHY:超注意力预算→指令被挤出)。⚠️行数是预算上限不是拆分目标，拆分用对刀:效果不减才可拆——需多一次read才能执行=拆分即质量降级。禁止为了单纯让行数好看而拆分；判断标准不是"数字降下来了没"，而是"拆完之后 Agent 能不能一次把该做的事做完不降级"，做不到就宁可保留超行数(见IRON LAW 5) L3：每主题一文件，超100行加索引

2. 阶段门控 > 线性流程——每个阶段有独立入口/出口条件，未满足不可跳过。WHY：对抗规则遗忘（失效1），门控是结构约束不是"建议"。

3. 全面审计 > 目测或单项核验——55项10层逐项确认，脚本核验与内容核验共同构成一次不可拆分的全面审计。WHY：目测会遗漏，脚本可重复但覆盖有限；任何单一检查都不能验证跨章节语义和执行质量。对抗规则遗忘+规则冲突（失效1+2）。

§4 设计原则

分正向（怎么做好）和防御（怎么防坏）两个视角，适用于所有 Skill。每条原则下方标注对应的 AP 反模式。

正向设计

1. 状态外置优于上下文累积：进度写文件不写对话，fresh session 注入状态（WHY:上下文累积=认知死循环主因 | 对应:AP-12循环无终止）
2. 执行与评估分离：干活的不评判进度，编排层基于量化指标判断（WHY:自评=运动员兼裁判 | 对应:AP-5无完成门控）
3. 方向差异化优先于深度挖掘：多候选方向时优先增加多样性（WHY:多样性是逃出局部最优的唯一路径 | 对应:AP-12循环无终止——同一方向反复=停滞）
4. 每次迭代必须有可验证产出：不是「做了」而是「产出了什么、能验证什么」（WHY:无产出=停滞前兆 | 对应:AP-6不可验证指令）

防御设计

5. 规则必附事故来源：IRON LAW/Gotcha/AP 每条补「来自XX事故」（WHY:理解事故>死记禁止令 | 对应:AP-19规则只有MUST没WHY）
6. 职责隔离靠约束不靠自律：不该做X是让结构上做不了，不是写「别做」（根因:Guardian越界→上下文污染 | 对应:AP-7无Confirmation Gate——用门控而非"建议确认"）
7. 假设每层都会失败：单点可能挂，确保有独立恢复路径（根因:Cron超时无人知 | 对应:AP-12循环无终止——无终止条件=单点失败无恢复）
8. 停滞检测用量化指标：用可度量信号判断卡住，不靠主观判断（根因:6/17串行超时 | 对应:AP-12循环无终止——stale_count是量化终止条件）
9. 已知局限只列硬伤：SKILL.md加## 已知局限段，每条含三要素（能力边界≤30字→触发条件≤20字→降级路径），同类合并标注[P/D/E]，按重要性降序排列，条目上限3条。判据：能通过改设计消除的≠硬伤（那是设计取舍或待办），只有无论怎么改设计都无法消除的才是硬伤。重要性三维评价：①不可逆性(撞到后能否挽回:不可逆>可逆需成本>完全可逆) ②发生概率(每次必撞>特定条件>极端边缘) ③影响范围(核心安全门控>子路径流程>非关键质量)。入选Top3须在不可逆性或影响范围至少一个为高且发生概率≥中；可逆+低频→下沉到工作流预检步骤（WHY:局限≠免责清单,3条逼作者只留真正绕不过去的硬伤 | 对应:AP-37 | 根因:mu-github-publisher 21条6756字→实际硬伤仅3条）
10. 事故闭环而非仅记录(ICE-5)：满足任一条件强制闭环——同类失败第二次、对外交付/发布事故、不可逆或静默降级风险、伪成功(文件齐全内容假)。五字段：触发步骤/强制点/失败行为/运行证据/失败后动作。修复必须落进工作流/脚本/checklist，不只是references。定性/知识引导类默认豁免(WHY:记录≠修复，未闭环事故必复发 | 对应:AP-35)

停滞检测规则

适用于所有含循环/迭代/Cron的 Skill。

信号	规则
单次迭代0新产出	stale_count+1
stale_count≥2	换结构约束（不是调参数）
stale_count≥4	上报人类
单阶段超过15轮或30分钟	强制换方向
Cron连续2次失败	自动降级（如切备用API）
Cron连续4次失败	停止+上报人类

"换结构不是调参数"：当任务在同一框架内反复停滞，决定性收益来自修正环境/结构约束本身，不是在现有框架里更用力调参。

§5 创作工作流

自动触发：新建Skill→完整流程(阶段1→8) | 修改核心流程、规则库、引用架构或安全边界→全面审计（55项10层） | 发布前→全面审计+安全扫描 禁止：改完未完成全面审计就提交 | 把脚本绿灯、目测或专项复核说成审计完成 | 用系统自带版/app/skills/skill-creator/替代本Skill

阶段 1:理解需求

入口：收到Skill创建/优化需求

操作：

• 从对话中提取：若当前对话已包含完整工作流，优先从聊天历史提取——工具链、步骤、纠正点、I/O格式，提取后请用户确认
• 收集 3+ 输入→输出示例(真实场景,不是假设)
• 明确 Skill 类型：工具封装 / 流程引导 / 知识编码 / 检阅类
• 确认不适用场景(description 里必须写)

出口：有明确输入输出示例清单≥3条

阶段 1.5:找实践案例(非工具封装类必做)

入口：阶段1完成,且非纯工具封装 操作：黄金案例3+/失败案例5+/有效-无效对比≥1组 出口：有案例清单,或"工具封装型,已跳过"

阶段 1.6:SSO 认证方案(涉及内部API必做)

如需内部 API 认证，参见组织内部规范

入口：Skill 需调用组织内部服务()

操作：确认client_id→选接入方式→硬规则:token禁明文落盘|Cookie禁硬编码client_id|frontmatter禁放凭据|audience≤5

出口：认证方案确定+通过合规检查，或标注"无需内部API,已跳过"

阶段 2:规划

入口：阶段 1(含1.5/1.6)完成

操作：

• 选意图模式：工具封装 / 生成器 / 检阅器 / 流水线 / 路由分发
• 选架构模式(可组合)：顺序工作流 / 多MCP协调 / 迭代精化 / 上下文路由 / 领域知识嵌入
• 列文件树(SKILL.md + references/ + scripts/ + assets/)
• 长流程Skill(≥4阶段)：定义 progress.json 字段（状态外置，对抗context压缩后丢失进度）

出口：文件树清单已确认,架构模式已选定

阶段 3:写 L1(description)

入口：阶段 2 完成

操作：

• 写触发词+使用/跳过条件,双引号单行≤1024字符
• 禁止：emoji、工作流描述、宣传语（放intro）(WHY:description是路由触发器不是广告)
• 必须：含"不适用"场景(WHY:明确边界防误触发)
• ⚡ Pushy 原则：AI 助手系统性偏向undertrigger，加「即使没提X，只要提到Y也要用」

格式："做什么功能。触发词:词1、词2、词3。不适用:场景描述(用哪个替代)。"

阶段 4:写 L2(SKILL.md)

入口：阶段 3 完成

操作：

• IRON LAW按需添加：有高频违规风险时才写，内容必须是业务专属约束，不写比写套话强(WHY:套话占行数不激活场景)。条数上限6条：超过6条需逐条审核是否真正"违反即出大问题"，非铁律级的规则下沉到工作流步骤或Gotchas中(WHY:条数膨胀→Agent注意力稀释→全部失效，来自mu-redskill-intro实战:新增3条经验被错误提升为IRON LAW)
• 如有IRON LAW，放frontmatter之后第一位(WHY:Agent第一眼=硬约束)
• 每个阶段：编号+入口条件+操作步骤+出口条件
• 改动类→Confirmation Gate(实施前用户确认)
• 输出前→Pre-Delivery Checklist(可逐项打勾)
• 行数≤300；超出优先判断"能否拆分而不降效果"，能则移到references/，不能则保留超行数不硬拆(WHY:超注意力预算→指令被忽略；但拆分本身若导致多跳read/执行链断裂，效果损失比行数超标更严重，见IRON LAW 5)
• Explain WHY：重要规则附WHY。纯MUST/NEVER/ALWAYS=yellow flag
• Gotchas section：环境里反直觉事实集中写，单位token价值高；但Gotchas是"速查结论"不是"事故日志"——单条超3-5行的现象/根因/修复叙述、或条目>10条/占全文>40%，必须按下方决策树分层处置(AP-34/L1-8)
  • Gotchas分层处置决策树(判据:常规执行时需读它吗?)：①删除——结论已被IRON LAW或工作流步骤覆盖→直接删(重复留存=AP-14冗余)；②上浮固化——是"该怎么做"的操作结论(字段规范/命名规则)→提炼一句进对应阶段步骤，删掉事故叙述；③下沉——是"某模板/某环境的实现坑"(CSS/超时/DOM顺序)→移到references/troubleshooting.md，主文件只留"症状→查阅条目"索引表
• Specificity to fragility：越不可逆越精确(给命令/模板)；越灵活越说明意图让Agent自主发挥
• 子Agent执行规范(流水线/多步骤必做)：SKILL.md含## 子Agent最小执行规范(≤30行)：必读文件+硬Gate+格式约束+禁止行为
• 已知局限段：每条含三要素+分类标签，结构：[P/D/E] 能力边界(≤30字)→触发条件(≤20字)→降级路径(替代方案/人工复核什么/上报人类)。按重要性降序排列，上限3条。同类合并不拆场景（如多个平台CLI限制→1条）。判据：能改设计消除的≠硬伤→不收入；无论怎么改都绕不过去的→才收入。重要性三维评价：①不可逆性(不可逆>可逆需成本>完全可逆) ②发生概率(每次必撞>特定条件>极端边缘) ③影响范围(核心安全门控>子路径流程>非关键质量)。入选Top3须在不可逆性或影响范围至少一个为高且发生概率≥中；可逆+低频→下沉到工作流预检。只说"做不到"不附降级路径=AP-37
  • P类(Platform)：平台/API/外部工具能力边界
  • D类(Design)：设计取舍导致的能力边界
  • E类(Edge)：边缘输入/极端场景未覆盖
  • 超3条→逐条用三维评价审核:是硬伤还是待办？能合并还是删除？(WHY:3条逼聚焦,mu-github-publisher 21条压缩后实际硬伤仅3条)
• 版本历史不入SKILL.md：SKILL.md只留1行版本号+CHANGELOG.md链接(如当前版本 vX.X，完整历史见 references/CHANGELOG.md)。版本历史是溯源信息，不参与任何生成/路由/决策，占行数=纯浪费注意力预算(WHY:mu-visual-card曾用35行版本历史占615行中的5.7%，迁移后省至1行)
• AP清单用表格不用段落：主文件AP清单每条一行(反模式名 + 一句话修复 + 根因事故 + 对应原则)，完整描述(症状/后果/检查/修复细节/根因叙述)留references/quality-gates.md。AP-33/34管版本历史和Gotchas不要堆主文件，AP描述自身同理——AP清单是"索引"不是"百科全书"(WHY:mu-skill-creator v4.1 AP-33~37自身以大段blockquote写进主文件，违反AP-33/34精神)

出口：wc -l SKILL.md≤300，有Checklist(IRON LAW按需)

frontmatter字段：name(必填,小写+数字+连字符,与目录名一致) | description(必填,≤1024字符,含触发词+不适用+pushy) | compatibility(可选) | metadata(可选)

阶段 5:写 L3(references/)

入口：阶段 4 完成

操作：每主题一文件 | 引用仅一跳(禁A→B→C)(WHY:多跳=token膨胀+遗忘指令) | 底部建索引

出口：所有引用文件存在，SKILL.md有索引

阶段 6:可验证性审查

入口：阶段 5 完成

操作：逐条审查指令，确认可yes/no判断。❌"写高质量代码"→✅"lint通过无error"

• ICE-5适用判定：满足任一则强制——同类失败第二次/对外交付事故/不可逆或静默降级/伪成功。适用时frontmatter加ICE: required，scripts/须有closure_check.*或等价质量门且审计运行退出0（审计仅做静态检查：脚本存在性+shebang；执行验证由用户手动运行该脚本）。定性/知识引导类豁免，默认不适用无需标记

出口：无主观指令，全部可yes/no判断

阶段 6.5:Eval 测试(可选但推荐)

入口：阶段 6 完成

操作(详见references/quality-gates.md)：写2-3个prompt→evals/evals.json，spawn两组(cleanup=delete，最多4并发)，accuracy≥85%。⚠️定性类Skill(写作/面评/引导)豁免量化，改用人工审查(WHY:强行量化=造假断言)

出口：evals.json存在且accuracy≥85%；或标注"已跳过"/"定性类,人工审查"

阶段 7:触发词优化

入口：阶段 6.5 完成(或跳过)

操作(详见references/quality-gates.md)：扫禁止词(analyzer/helper/tools/assistant/单独skill/短动词/≤2字) | 中英文触发词5+种 | 测试10+10触发/不触发，accuracy≥85% | 调试:问Agent「什么时候用这个Skill?」——回答不准=description需优化

出口：无禁止词，中英文覆盖，accuracy≥85%

阶段 8:交付(组织四步)

入口：阶段7完成+负责人明确授权交付

⚠️ Confirmation Gate:交付前必须获得负责人明确的"可以交付"指令

交付四步：1.安全扫描(人员/凭证/内网/平台密钥)→ 2.frontmatter校验→ 3.打包+说明→ 4.移交专用发布工具（本 Skill 止步于交付门，不执行任何 push/上架动作，发布由外部工具完成）

出口：交付包就绪且通过校验，发布动作由外部发布工具接管

§6 安全硬规则

禁止进任何Skill文件：人才标准/组织信息/角色指南/职级定义/人员信息(姓名/工号/账号ID)/高敏数据 受限系统黑名单(禁止调用API)：公司内部 HR/绩效/OKR/招聘等受限系统（域名运行时按环境配置，禁止硬编码进 Skill） 用户态数据隔离：本地已安装列表/用户偏好/快照/推荐历史等个性化文件禁止随Skill发布，必须.skillignore排除+SKILL.md声明"首次使用自动生成"(根因:发布者数据污染下载用户行为) 正确做法：Skill只写"运行时现读"指令(文档链接/ID)，内容不进Skill。违反=敏感信息泄露+发布拦截

§7 Anti-Pattern 清单(AP-1~38)

完整说明+修复示例见references/quality-gates.md。每条标注根因事故和对应的设计原则。

#	反模式	修复	根因事故	对应原则
1	>250行	效果优先判断能否拆(拆完仍可一次执行不降级才拆);做不到就不硬拆	猎手418行Agent忽略后半段	§3决策1
2	description写宣传语	description=仅触发条件	description写"高效便捷"无法触发	§4正向4
3	阶段无编号/出口	加编号+完成定义	子Agent跳步无法判进度	§3决策2
4	多跳引用A→B→C	仅一跳	面评虾3层嵌套Agent遗忘	§3决策1
5	无完成门控	加验证步骤	audit跑完不确认就交付	§4正向2
6	不可验证指令	改yes/no可判断	"高质量面评"Agent自认合格	§4正向4
7	无Confirmation Gate	改动前加用户确认	6/22未等确认自作主张发布	§4防御6
8	无Pre-Delivery Checklist	输出前加打勾清单	发布后才发现漏安全扫描	§4防御7
9	IRON LAW是套话	改专属约束;无风险则删	多个Skill写"shebang+行数"被忽略	§1失效3
10	无AP列表	加禁止行为清单	新Skill反复犯同类错误	§4防御5
11	无子Agent执行规范	加≤30行最小规范	子Agent跳步/自创格式	§4防御6
12	循环无终止条件	加max/超时退出	6/17串行CLI无上限超时	§4防御7+8
13	无数据量限制	加limit/截断/分页	小雷达91条串行查询超时	§3决策1
14	冗余重复提示	同一指令只写一处	SKILL.md+references两处写同一规则	§1失效2
15	大文件无截断	加字数/行数上限	read大文件context溢出	§3决策1
16	SKILL.md留intro	intro由平台CLI单独管理	修改SKILL.md的intro线上没同步	§1失效2
17	Shell无shebang/set-euo	加shebang+安全开关	脚本静默失败Agent以为成功	§4防御7
18	重复造轮子	bundle到scripts/复用	多Skill各自SSO换票改一处漏一处	§1失效2
19	规则只有MUST没WHY	附WHY解释意图	Agent死记禁止令遇边界选错	§4防御5
20	IRON LAW照搬通用模板	必须含业务专属约束	IRON LAW5条套话Agent全忽略	§1失效3
21	frontmatter含真实内部账号	删除metadata块	公开Skill暴露发布者账号	§6安全
22	_meta.json含凭据未排除	.skillignore排除	打包含真实平台密钥	§6安全
23	eval/exec执行用户输入	用AST白名单替代eval/exec	多个Skill代码评审	§1失效1
24	异常捕获过宽	捕获具体异常类型;re-raise或log	多个Skill代码评审	§1失效1
25	调试残留	删除pdb/breakpoint/if False	多个Skill代码评审	§1失效1
26	废弃API调用	替换为文档推荐新API	多个Skill代码评审	§1失效1
27	API契约不一致	校验调用方与定义方签名匹配	多个Skill代码评审	§1失效1
28	import与requirements不匹配	同步requirements.txt	多个Skill代码评审	§1失效1
29	可选依赖无fallback	try/except ImportError+降级方案	多个Skill代码评审	§1失效1
30	路径操作字符串替换	用os.path.splitext处理路径	多个Skill代码评审	§1失效1
31	资源遍历无上限	加max/分页/采样上限	多个Skill代码评审	§1失效1
32	.gitignore缺失	创建.gitignore排除产物	多个Skill代码评审	§1失效1
33	SKILL.md留版本历史	只留1行版本号+CHANGELOG链接	mu-visual-card版本历史35行	§3决策1
34	Gotchas堆积膨胀	分层处置:删/上浮/下沉	mu-redskill-intro踩坑段占66%	§3决策1
35	事故仅记录未闭环(ICE-5)	修复落进工作流/脚本/checklist	事故复发因仅记录未工程化	§4防御10
36	附件文档职责重叠	合并唯一权威,其余标DEPRECATED	templates/与references/重叠	§1失效2
37	已知局限膨胀/无降级路径	三要素+P/D/E+≤3条+三维重要性	21条局限仅3条为真硬伤	§4防御9
38	AP描述膨胀(段落代替索引)	表格每条一行,完整描述留references	AP清单自身用大段描述	§3决策1

失效模式→AP: 遗忘→3/5/8/17/25 | 冲突→4/14/16/18/27/36 | 膨胀→1/9/13/15/20/31/33/34/37/38 | 跨模式→6/7/10/11/12/19/23/24/26/28/29/30/32 | 闭环缺失→35

§8 全面审计：10层55项模型

全面审计是唯一的审计结论，必须逐项确认全部 55 项。bash scripts/skill-audit.sh <skill-name> 只执行其中可脚本核验的项目并提供证据，不产生“审计通过”的独立结论；脚本输出绿灯只能作为全面审计的一部分。支持环境变量 SKILL_BASE 指定 Skills 根目录（默认从脚本位置自动探测）。完整说明见 references/quality-gates.md。

层	审计目标	项数	脚本核验项	覆盖范围
L1	文档结构	8	5	frontmatter/desc/name/行数/refs索引/版本历史/Gotchas膨胀
L2	架构一致性	5	2	逻辑闭环/阶段编号/跨章节/交互/版本号
L3	代码质量	8	6	API契约/eval/异常/调试残留/废弃API/shebang/硬编码/退化（scripts/+assets/可执行文件）
L4	跨文件一致性	5	1	模板双源/信息冗余/共享模式/数值一致性/附件职责唯一
L5	文档↔代码对齐	3	2	参数表一致/功能路由完整/参考实现正确性
L6	依赖完整性	3	2	import↔requirements/技术栈/fallback
L7	文件卫生	6	5	僵尸/断链/孤儿/用户态/.gitignore/平台产物
L8	安全合规	4	3	安全扫描/SSO/内部账号/凭据
L9	健壮性&降级	7	1	降级链/确认门/子Agent/数据量/大文件/路径/遍历
L10	内容质量	6	2	可验证性/AP清零+ICE闭环/文案/已知局限(三要素+P/D/E+≤3条+重要性降序)/停滞/边缘输入
合计		55	29

全面审计逐项清单（🔍=需附脚本核验证据，👤=需附审计判断与证据；两类项目共同构成一次全面审计，不构成彼此独立的审计等级）

L1文档结构: 🔍L1-1 IRON LAW(frontmatter后,业务专属,≤6条——超6条逐条审核是否铁律级,非铁律下沉到工作流/Gotchas) | 🔍L1-2 desc(单行无emoji+触发词+不适用) | 🔍L1-3 intro(三段式≠desc,tags≥6) | 🔍L1-4 name(小写+连字符=目录名) | 🔍L1-5 行数≤300(脚本只报数字,超标不等于判红——需先按IRON LAW 5评估能否拆分而不降效果,做不到就标注"已评估-保留超行数"视为通过) | 👤L1-6 refs索引完整 | 🔍L1-7 版本历史不入SKILL.md(只留1行版本号+CHANGELOG链接,AP-33) | 🔍L1-8 Gotchas未膨胀(踩坑段条目≤10且占全文≤40%,超标按分层处置删除/上浮/下沉到troubleshooting.md,AP-34;同L1-5为信息告警不直接判红) L2架构一致性: 👤L2-1 逻辑冲突(新旧矛盾/因果闭环/约束可满足性:对同一度量的所有数值约束取数学交集，验证交集非空——如面积上限≤X%和下限≥Y%是否X≥Y；不同约束作用于有交集的集合时组合效果是否可行) | 🔍L2-2 阶段编号+入口/出口+可验证 | 👤L2-3 跨章节(原则↔AP↔事故) | 👤L2-4 交互一致(多模式无矛盾) | 👤L2-5 版本号匹配 L3代码质量(scripts/+assets/可执行文件): 🔍L3-1 API契约(签名↔调用) | 🔍L3-2 无eval/exec | 🔍L3-3 异常宽度(无bare except) | 🔍L3-4 无调试残留 | 🔍L3-5 无废弃API | 🔍L3-6 shebang+set-euo | 👤L3-7 硬编码已参数化 | 👤L3-8 功能退化 L4跨文件一致性: 👤L4-1 模板双源(不双存) | 👤L4-2 信息冗余(清单未被覆盖) | 👤L4-3 共享模式一致(utils用法) | 🔍L4-4 数值一致性(同一语义量的所有引用点——含同文件不同章节——尺寸/字号/坐标/色值/百分比统一；版本迭代后旧章节数值未同步=此项不通过) | 👤L4-5 附件职责唯一(同一主题不得在templates/和references/同时存在功能等价文件——有则合并或标DEPRECATED;references/内多文件定义同一规则的不同版本=此项不通过,AP-36) L5文档↔代码(scripts/+test-output参考实现): 🔍L5-1 参数表一致(SKILL↔CLI) | 🔍L5-2 功能路由完整(均有实现) | 👤L5-3 参考实现正确性(示例代码/模板/SVG语法正确且与文档对齐) L6依赖完整性(scripts/): 🔍L6-1 import↔requirements匹配 | 👤L6-2 技术栈表一致 | 🔍L6-3 可选依赖有fallback L7文件卫生: 🔍L7-1 僵尸文件(refs有引用) | 🔍L7-2 断链(引用均存在) | 👤L7-3 路径孤儿(改名同步) | 👤L7-4 用户态未混入 | 🔍L7-5 .gitignore(scripts/时) | 🔍L7-6 无平台产物 L8安全合规: 🔍L8-1 安全扫描(平台密钥/内部账号/高敏数据/受限系统) | 👤L8-2 SSO方案 | 🔍L8-3 frontmatter无内部账号(AP-21) | 🔍L8-4 _meta.json已排除(AP-22) L9健壮性&降级: 👤L9-1 降级链(外部依赖有处理) | 👤L9-2 改动类→Confirm Gate | 👤L9-3 流水线→子Agent规范 | 👤L9-4 数据量限制(AP-13) | 👤L9-5 大文件截断(AP-15) | 🔍L9-6 路径安全(splitext) | 🔍L9-7 遍历上限 L10内容质量: 👤L10-1 可验证性(yes/no) | 🔍L10-2 AP清零(无AP-1~38)+ICE闭环(标ICE: required时须有closure_check.*或等价质量门；静态检查存在性+shebang，执行验证由用户手动运行) | 👤L10-3 文案(无错别字) | 👤L10-4 已知局限(每条含三要素:能力边界→触发条件→降级路径;P/D/E分类标注;同类合并;≤3条;重要性降序;非硬伤不收入;AP-37) | 👤L10-5 停滞检测(stale_count) | 👤L10-6 边缘输入覆盖(极短/极长/空输入/非预期语言等边界条件是否有处理指引或在已知局限中声明)

§9 已知局限

1. [P] 全面审计无法量化设计品味与定性质量→审计通过≠产出优秀→对照黄金案例人工判断,无黄金案例则至少请2人独立review;L4(5项)+L10(6项)须逐项附判断依据,不得以脚本绿灯代替
2. [P] 触发词效果受Agent模型影响→跨模型使用时→用目标模型实测10+10触发/不触发样本,accuracy<85%则加补充触发词
3. [D] 状态外置非强制→短流程Skill可能跳过progress.json→≥4阶段的Skill强制启用,短流程标注"无需"即可

references/ 索引

文件	说明
quality-gates.md	AP-1~38完整说明+10层审计模型+Eval+触发词优化
collaboration-guide.md	推荐联动(mu-dev-workflow)
evals.json	Eval测试用例示范