Skill Lint

6. Harness 可靠性审查

创建预检、重大改造和正式验收必须读取 references/harness-reliability-standards.md，逐层检查 Contract / Producer / Verifier / Evidence Binding / Fault Injection / Closure / Composition。旧版、多维审阅、视觉生产或用户反馈“反复漏项/产出漂移”时还必须读取 references/instruction-stability-standards.md。

先运行不执行候选代码的具体失效审查。单 Skill：

python3 scripts/harness_failure_audit.py audit \
  --candidate-root /path/to/skill

Skill 集合或 monorepo：

python3 scripts/harness_failure_audit.py batch \
  --root /path/to/skills

该审查器递归发现包含 SKILL.md 的最小单元，输出带文件、行号、证据、影响和修正建议的稳定 JSON；hard finding 返回 1，范围错误或集合中零 Skill 返回 2。规则 ID 与边界见 references/harness-reliability-standards.md。默认只做静态审查，不执行、安装或联网。

旧版结构性稳定性审查：

python3 scripts/instruction_stability_gate.py assess \
  --candidate-root /path/to/skill

缺少 config/instruction-stability-contract.json 时，assess 返回退出码 2 和 INSTRUCTION_STABILITY_NOT_VERIFIED，同时给出 ISG 结构性 finding 与 HFA/HRA 具体实现 finding。视觉/几何语义只从 SKILL.md 和 references/**/*.md 的规范性上下文识别，TASKS/DECISIONS/CHANGELOG 的历史讨论不触发视觉模态。此模式不执行候选代码，适合旧版和未知第三方 Skill。

ISG-002 会列出触发视觉/几何要求的规范来源和行号，但它只证明候选缺少合适模态的领域验证证据。不要据此声称已经检测出重叠、裁切或其他具体业务错误；应让目标 Skill 提供自己的 checker、最小违规反例与合法近似正例，再由正式门禁复算。

声称“指令遵循稳定”“多轮不漏项”前，目标 Skill 必须提供约束追踪合同。每条 hard constraint 在权威来源中使用唯一 <!-- skill-lint:constraint CONSTRAINT-ID --> 锚点；候选外 evaluator-signed 基线必须与全部锚点、规范行、合同和当前候选哈希一致。先取得当前候选可复算的 Harness 审查证据，再用相同输入/配置至少独立执行三轮；每轮保留唯一 execution nonce、evaluator-signed producer log 和独立目录内的真实产物。每条硬约束还必须有候选外 evaluator-signed held-out 正反例。完成静态安全审查、披露 checker 且用户确认候选为自有/可信代码后，运行：

python3 scripts/instruction_stability_gate.py verify \
  --candidate-root /path/to/skill \
  --evaluator-public-key /path/to/review/evaluator-public.pem \
  --requirements-baseline /path/to/review/requirements-baseline.json \
  --harness-evidence /path/to/review/harness-review.json \
  --held-out-cases /path/to/review/held-out-cases.json \
  --held-out-root /path/to/review/held-out \
  --run-evidence /path/to/review/runs.json \
  --runs-root /path/to/review/runs \
  --receipt /path/to/review/instruction-stability-receipt-draft.json \
  --confirm-trusted-candidate

该门禁固定使用当前受信 skill-lint 复算 HARNESS_REVIEW_VERIFIED，再逐轮重跑 active checker。它要求每条硬约束精确映射到显式来源锚点、自动发现并签名枚举的 requirements sources/exclusions、checker、正确验证模态、正确产物阶段、带类型/条件/阈值的 measurement、签名 hidden 正反例和已知历史回归；合同漏列规范行、签名无效、三轮复用路径、旧候选/旧 producer 日志重放、负向用例因其他约束失败、少报一个 constraint id、checker 修改产物或关键 observable 漂移都会阻塞。公开、隐藏和真实运行产物统一使用同类随机暂存路径，避免 checker 按样本类别分支。

verify 只生成 INSTRUCTION_STABILITY_EVIDENCE_READY 草稿。evaluator 必须在不执行候选代码的隔离环境用 Ed25519 私钥运行 sign-evidence --private-key ...，再用只持有候选外公钥的 verify-receipt 复验全部绑定；只有后一步输出 INSTRUCTION_STABILITY_VERIFIED 才能声明稳定。私钥不得出现在 producer/checker 的进程树、环境或可读工作区，完整命令见 references/instruction-stability-standards.md。

客观 Hard Fail 一律阻塞。正式验收应先用 scripts/harness_evidence_gate.py snapshot 固化候选与规则读集，填写候选内 checker、参数、超时和故障用例的预期失败码。完成静态安全审查并取得用户对自有/可信候选的确认后，再用 verify --confirm-trusted-candidate 亲自重跑。JSON 中不得填写或采信自报退出码、PASS 和日志。只有退出码为 0 且出现 HARNESS_REVIEW_VERIFIED，才能说“当前候选的 Harness 审查证据已验证”。该标记不替代目标 Skill 自己的 DOMAIN_VERIFIED，门禁也不是第三方代码沙箱。

完成标记不可互相替代：

• HARNESS_REVIEW_VERIFIED：当前候选、规则、checker 和故障用例证据有效。
• INSTRUCTION_STABILITY_EVIDENCE_READY：动态复算已完成，但草稿尚未离线签名与验签，不能作为完成标记。
• INSTRUCTION_STABILITY_VERIFIED：evaluator Ed25519 签名回执已复验，外部硬约束基线/held-out、当前 Harness evidence、候选/producer 绑定和至少三轮真实产物逐约束通过，measurement/observable 未漂移。
• DOMAIN_VERIFIED：领域验证器确认具体业务产物正确。

只要 Skill 声称“稳定完成”，就必须同时满足前两项；若还声称业务结果正确，再加第三项。未运行的层一律写 NOT_VERIFIED。

7. 可评估性审查

确认 Skill 是否具备后续 eval 的基础：

• 是否声明评估范围
• 是否声明 Hard Fail
• 是否提供 benchmark case 或样例
• 是否提供输出验收标准
• 是否区分静态检查与动态评估
• 是否有逐约束追踪合同、验证模态和产物阶段
• 是否用至少三轮固定输入检查关键覆盖集合与历史回归
• 已知漏报是否有最小违规反例，已知误报是否有合法近似正例

缺少这些内容不一定阻塞发布，但应作为质量风险记录。

8. 生成审查报告

审查报告应优先列出问题，再给摘要。严重问题必须具体到文件和位置。

如用户需要最终交付件、发布前意见或正式质量结论，使用 templates/skill-quality-opinion-report.md 生成“Skill 质量意见报告”，报告中必须写明问题、影响、修正方式和复查标准。

对承载设计原理的结构性建议（拆解披露、触发边界、上下文聚焦、自由度匹配、可机判验收等），在 finding 的「设计理念」字段一句话讲清背后写作原理，可回查对应 standards 文件的「设计理念」小节，使报告同时具备 skill 写作教学价值；纯事实问题（文件缺失、引用断裂、命名大小写）可省。稳定性 finding 必须具体指出漏的是哪条 constraint、验证模态、产物阶段、case 或 run，不使用“遵循不稳定”这类无法复查的泛称。

生成正式质量意见报告后，按 references/archive-standards.md 判断是否归档。需要归档时，在本技能 archive/YYYYMMDD_HHMMSS_<target-slug>/ 下保存报告、元数据和证据索引；真实归档内容不提交到 Git。

问题分级

Hard Fail 一律按严重问题处理。

报告模板

正式质量意见报告模板见 templates/skill-quality-opinion-report.md。报告除原有结构、安全、业务流和可评估性外，必须单列 Harness 七层结论、证据等级和完成标记。

模板的设计理念要点（结构性建议必填「设计理念」字段，纯事实问题可省）：

• 严重问题：位置 + 依据 + 影响 + 修正方式 + 设计理念 + 最优设计 + 复查标准
• 警告问题：位置 + 影响 + 建议修正 + 设计理念 + 最优设计 + 优先级
• 安全评估：风险类别 + 安全级别 + 上下文（避免纯关键词误报）
• 复查清单：严重问题已关闭 + 警告问题处理或登记 + 文件引用可达 + 隐私脱敏 + 安全覆盖 + 发布治理同步

参考规则

• references/skill-standards.md：审查索引和模块路由
• references/repository-skill-discovery-standards.md：仓库类型识别、monorepo 单元发现和候选文档分级
• references/structure-standards.md：目录结构、文件可达性和 references 命名
• references/frontmatter-metadata-policy.md：Frontmatter 通用字段与项目发布字段分层策略
• references/trigger-description-standards.md：name 与 description 触发边界
• references/configuration-privacy-standards.md：配置模板、本地配置隔离和公开内容去具体化
• references/security-assessment-standards.md：危险执行、敏感访问、数据外传、凭证、依赖、MCP 和提示词安全
• references/publishing-standards.md：LICENSE、CHANGELOG、version 与发布索引
• references/workflow-output-standards.md：正文工作流、依赖、脚本、输出和可编排性
• references/business-flow-rubric.md：业务流深度和可评估性判则
• references/harness-reliability-standards.md：Harness 七层可靠性、Hard Fail、创建预检和候选绑定证据门禁
• references/instruction-stability-standards.md：旧版识别、约束追踪、模态/阶段匹配、多轮执行和产出漂移门禁
• references/reporting-standards.md：问题分级和审查报告模板
• references/archive-standards.md：正式审查报告的内部归档机制
• references/skill-dev-guide.md：Skill 开发规范参考
• references/skill-orchestration-guide.md：复杂编排规范参考
• config/review-profile.example.yaml：个人/项目审查配置模板
• config/instruction-stability-contract.example.json：目标 Skill 的约束追踪合同示例
• config/instruction-stability-requirements-baseline.example.json：候选外独立硬约束基线格式示例
• config/instruction-stability-held-out-cases.example.json：evaluator-signed 候选外隐藏正反例清单格式
• scripts/harness_evidence_gate.py：生成和复算候选绑定的 Harness 审查证据
• scripts/harness_failure_audit.py：单 Skill / Skill 集合的具体 Harness 失效模式静态审查
• scripts/instruction_stability_gate.py：静态识别旧版结构风险，并验证多轮真实产物的逐约束覆盖稳定性
• templates/skill-quality-opinion-report.md：最终 Skill 质量意见报告模板