harness-master

Harness Master

审计 AI harness 配置质量、使用情况和生态选项，然后在同一会话中应用已批准的配置修复。

**不适用于：**创建 Agent（agent-conventions）、构建 MCP 服务（mcp-creator）、通用应用遥测（observability-advisor），或不关注 harness/配置的通用代码审查（review）。

**输入：**harness 名称、级别或自然语言。模式：审计、发现（差距 + 有界研究）、使用情况、应用/安装、日志。当模式不明确时，运行 scripts/discovery/classify_intent.py --args "$ARGUMENTS" --json。

分派

$ARGUMENTS	模式	首要操作
Empty	接收请求	询问 harness 或 all，然后询问 project、global 或 both
all	接收请求	只询问级别
all <level> / <level> all	审核	按确定性顺序对所有受支持的 harness 执行试运行
<harness...>	接收请求	确定一个或多个 harness，然后只询问缺少的级别
<level>	接收请求	确定级别，然后只询问缺少的 harness
<harness...> <level> / <level> <harness...>	审核	对所选 harness 和级别执行试运行审查
grok-build both（在具备 rig 工作流功能的仓库中）	审核 + 回执	审核插件归属/冲突，并生成绑定哈希的已保存工作流投影预览；不要应用
apply approved	应用已批准项	仅当用户已在本会话中批准时，应用上一次匹配的试运行批次
apply <harness...> <level> / apply <level> <harness...>	应用已批准项	仅当本会话中已审查并批准相同范围时才应用；否则先重新运行审核
install <harness...>	安装指南	仅显示精确的 npx skills add ... 命令；不要编辑配置
discover	完整发现	按照 references/discovery-pipeline.md 执行 W0 扫描 → 侦察 → 构思 → 报告
discover audit / audit gaps	发现 W0	仅生成差距报告；不进行侦察
discover resume / discover list	日志	加载或列出 ~/.agents/harness-master/discovery/ 会话
usage <harness|all> [level] [days]	使用情况审查	收集安全的汇总使用情况/成本/令牌/工具信号；只读
NL：缺少技能 / 扩展 / 为 harness 查找最佳 X	发现（推断）	深度：完整、聚焦、候选或比较 — 参见 discovery-pipeline.md
自然语言：“review/audit/check/tune config”	审核	规范化 harness 和级别，然后执行试运行审查
自然语言：“review/analyze usage/cost/tokens/tools for ”	使用情况审查	规范化 harness 和级别，仅收集安全元数据，并报告优化方向
自然语言：“find/latest/best plugins/extensions/MCPs/skills for ”	聚焦发现	W0 + 类别侦察 + source_probe.py；只读
类似“approved”“do it”“apply those changes”的自然语言批准	应用已批准项	仅当紧接其前的 harness-master 审查与该范围匹配且仍为当前状态时继续
创建 Agent 或 MCP 服务的请求	拒绝并重定向	重定向到正确的专用技能
不受支持的 harness 名称	拒绝并澄清	列出受支持的 harness，并请用户从中选择

空参数处理程序

如果用户在没有参数的情况下调用 /harness-master：

1. 询问要审查哪些 harness，或是否使用 all。
2. 询问选择 project、global 还是 both。
3. 说明第一轮始终仅进行 dry-run。

输入规范化

• 支持的 harness：claude-code、claude-desktop、chatgpt、codex、cursor、cursor-cli、grok-build、opencode、perplexity-desktop、cherry-studio、lm-studio
• 支持的级别：project、global、both
• 支持的研究类别：config、plugin、extension、mcp、skill、all
• 支持的使用时间窗口：正整数天数，例如 7、14、30，或 days=14；未指定时默认为 14
• Harness 别名：
  • claude、claude-code -> claude-code
  • claude-desktop -> claude-desktop
  • chatgpt、chatgpt-desktop、openai-chatgpt -> chatgpt
  • codex -> codex
  • cursor、cursor-editor、cursor-desktop、cursor-web、cursor-cloud、cursor-cloud-agent、cursor-background-agent -> cursor
  • cursor-cli、cursor-agent、cursor-agent-cli、agent-cli、agent -> cursor-cli
  • grok、grok-build、grok-cli -> grok-build
  • opencode、open-code -> opencode
  • perplexity、perplexity-desktop、perplexity-mac -> perplexity-desktop
  • cherry、cherrystudio、cherry-ai、cherry-studio -> cherry-studio
  • lm-studio、lmstudio、lms -> lm-studio
• 级别别名：
  • project、repo、local -> project
  • global、user -> global
  • both、all-levels -> both
• 按逗号和空白拆分多个 harness。
• 如果用户同时提供 all 和具名 harness，询问他们想使用哪种形式。
• 确定性的 all 顺序：claude-code、claude-desktop、chatgpt、codex、cursor、cursor-cli、grok-build、opencode、perplexity-desktop、cherry-studio、lm-studio
• 绝不猜测未知标记。提出一个聚焦的澄清问题。

Grok Build（grok-build）

• 指令入口： AGENTS.md -> instructions/grok-global.md -> instructions/global.md
• 策略模板： 通过仓库 Grok 平台适配器同步，将 config/grok-config.toml 合并到 ~/.grok/config.toml
• 所有权： replace-owned（models、mcp_servers、plugins、compat、telemetry）与 blend-owned（ui、features、session、tools、toolset、subagents、memory）
• 仓库技能： 当规范化后的 ~/.grok/config.toml 中的 [plugins].paths 指向此有效仓库根目录时，插件是首选的非 CLI 所有者。不要为其仓库技能正文生成 Skills CLI、Claude 别名或 ~/.grok/skills 镜像。
• 外部技能： 没有原生 Skills CLI 适配器；精选外部安装/同步会保留 claude-code 别名，并镜像到 ~/.grok/skills。
• 冲突： ~/.agents/skills、~/.claude/skills 或 ~/.grok/skills 中由插件覆盖的名称都属于清理候选项，并会阻止声称已实现无冲突激活。
• 已保存的工作流： 仓库 .grok/workflows/*.rhai 仅为源文件。项目用户投影和已识别的旧版迁移使用 scripts/grok_workflow_projection.py、精确预览回执、新鲜 canary 和绑定回执的回滚。
• Plannotator： CLI + 技能 + hooks（没有 Grok npm 插件）。安装：grok plannotator install（仓库 CLI）。策略：config/grok-plannotator-hooks.json -> ~/.grok/hooks/plannotator.json；home shim 将 block 映射为 deny。精选内容位于 docs/src/authoring/skills/*.mdx。与 OpenCode 的 @plannotator/opencode@latest 对比。
• 环境变量（不在 TOML 中）： GROK_WEB_FETCH、GROK_MEMORY、GROK_SUBAGENTS、GROK_LSP_TOOLS——在 config/grok-env.sh 中记录；使用 /grok-delegate preflight 验证
• 跨 harness 委派： /grok-delegate — 原生无头 grok -p / -r / worktrees / leader，用于 Codex/OpenCode 任务图（不同步配置）
• 隔离同步： 使用 --platforms grok --targets home 同步仓库栈（跳过其他 harness 的 home 合并；包含 Plannotator hook 刷新）

Cursor Agent CLI（cursor-cli）

• 二进制文件：agent（也可以是 cursor-agent）。Skills CLI 适配器仍为 cursor（-a cursor）。
• 指令入口：AGENTS.md + CLAUDE.md + .cursor/rules + instructions/cursor-cli-global.md（精简的 .cursor/rules/cursor-cli.mdc 指针）
• 与编辑器共享的 SSOT：.cursor/hooks.json、.cursor/mcp.json、.cursor/skills、.cursor/agents、~/.cursor/{hooks,mcp,skills,agents} — 由 Cursor 适配器（harness="cursor"）一次性渲染
• **仅限 CLI：**项目级 .cursor/cli.json 权限；由用户管理的 ~/.cursor/cli-config.json（同步 SHALL NOT 写入该文件）。Doctor：仓库 CLI cursor-cli doctor
• 插件：--plugin-dir 和 agent plugin marketplace（由操作人员选择启用；绝不通过同步添加）
• **ACP / 工作树 / worker：**引用 cursor-acp；agent --worktree；agent worker 不属于仓库同步范围
• **Hooks：**使用共享的 hooks.json + 插件 hooks。不要将 cursor-cli 添加到 hook-registry 渲染列表。仅限用户目录的 Plannotator：通过 config/cursor-global-hooks.json → ~/.cursor/hooks.json + plannotator-plan-hook.py 配置 CreatePlan / SwitchMode。安装/同步：cursor-cli plannotator sync。绝不要放入 Git 跟踪的 .cursor/hooks.json。

分类门控

1. 将 $ARGUMENTS 解析为 harness、级别、all、安装意图、应用意图和未解析的标记。
2. 如果仍有未解析的标记，先提出一个澄清问题，再继续。
3. 如果请求是 discover ...、差距/缺失/扩展意图，或以自然语言查找最适合某个 harness 的内容，则运行 Discover（通过 classify_intent.py 或 discovery-pipeline.md 推断深度）。
4. 如果请求是 usage ...，则仅运行 Usage Review。
5. 如果请求是 install ...，则仅运行 Install Guidance。
6. 如果是临时请求“find skill for X”，则引导至 skill-router search 或 npx skills find。如果是系统性扩展 Skill/MCP，则继续执行 Discover。如果要创建 Skill，则引导至 skill-creator。如果是开放式的非 harness 研究，则引导至 /research。
7. 如果请求是 apply ... 或批准短语，则仅在本会话中已存在匹配的 dry-run 审查时运行 Apply Approved。否则先重新运行审计。
8. 如果请求包含不受支持的 harness，则明确拒绝并列出受支持的集合。
9. 如果未指定 harness 且未提供 all（审计/用量），则只询问 harness 或 all。
10. 如果未指定级别（审计/用量），则只询问 project、global 或 both。
11. 否则，以 dry-run 模式运行 Audit。

分类逻辑

1. 优先路由显式模式标记：discover、usage、install、apply、resume、list。
2. 将差距/缺失/扩展/查找最适合项的自然语言请求路由至 Discover 的相应深度（而非 Audit）。
3. 如果请求包含完整的 harness/级别范围，且意图是调整/修复配置，同时没有 Discover 信号，则路由至 Audit。
4. 将用量/成本/令牌相关的自然语言请求路由至 Usage Review。
5. 仅当紧接在前的 dry-run 审计与请求范围匹配时，才将批准请求路由至 Apply Approved。

工作流

模式 A：审计（默认，先试运行）

1. 关卡 0 — 发现各个界面

   • 运行：

     uv run python scripts/discover_surfaces.py --repo-root . --level <level> --harness <canonical-harness> [--harness ...]
     

   • 解析 JSON 输出，并将每个界面分类为 present、missing、generated、merged、repo-observed 或 blind-spot。
   • 如果脚本无法运行，则使用 Glob、Read 和 Grep 手动发现。

2. 关卡 1 — 提出修复建议前，先检查项目上下文

   • 首先阅读仓库的意图和运行模式：README.md、AGENTS.md、面向 harness 的项目文件、关键清单、CI/工作流信号，以及仓库原生的编排逻辑（如有）。
   • 在此仓库中，将仓库级 harness 同步脚本与 config/tooling-policy.json 和 config/sync-manifest.json 一并视为托管、生成和合并的 harness 界面的权威上下文。

3. 关卡 2 — 更新最新官方指南

   • 阅读 references/latest-doc-sources.md。
   • 优先使用 llms.txt（如有），然后查阅第一方文档、权威供应商仓库文档；仅在必要时使用网络搜索作为后备。
   • 如果无法获取官方文档，则进入降级模式并降低置信度。

4. 关卡 3 — 独立审计每个选定的 harness

   • 仅针对选定的 harness，有选择地加载 references/harness-surfaces.md、references/harness-checklists.md 和 references/evidence-boundaries.md。
   • 对于 both，在提出编辑建议前，比较项目级和全局级的优先顺序。
   • 明确标记生成的界面。优先修复权威来源，而不是直接编辑生成的输出。
   • 将缺失的原生界面视为需要评估的证据，而非自动判定为失败。
   • 对于 grok-build both，如果选定的仓库拥有 .grok/workflows/rig-ecosystem-index.rhai 和 skills/rig-ecosystem-refresh/SKILL.md，则验证配置路径中的插件归属 以及三个重复的技能根目录。根据当前任务上下文确定下游 dotfiles 根目录； 切勿对用户路径进行硬编码。
   • 在将回执视为符合审批条件之前，使用 Grok 原生工作流验证器验证权威工作流， 并验证已配置的插件来源。将这些结果作为独立证据，与回执的源哈希绑定。
   • 使用以下命令生成工作流预览：

     uv run python skills/harness-master/scripts/grok_workflow_projection.py preview \
       --repo-root <agents-repo> \
       --dotfiles-root <dotfiles-repo> \
       --receipt-out <user-state-receipt.json> \
       --format json
     

     回执路径必须位于 Grok 技能/工作流发现根目录之外。目标位置不一致、旧版哈希不一致、插件归属无效或技能重复暴露，都会阻止批次执行。插件归属要求可读取且可移植的 frontmatter，其中非空的 name 和 description 必须与技能目录名称相符。若存在事务所有者标记，也会阻止生成新的预览。

5. 关卡 4 — 报告试运行结果

   • 使用 references/output-format.md 中的结构。
   • 每项发现都必须包含严重性、受影响的界面、证据标签、该问题对本项目的重要性，以及正确的修复位置。
   • 如果正确的更改方案明确，则展示具体的补丁预览。
   • 试运行报告完成后停止，并等待用户明确批准。

模式 B：应用已批准的更改

1. 仅在明确的批准关卡之后应用。
2. 只有当同一会话中紧邻其前的 harness-master dry-run 审查已覆盖相同的 harness 集合和级别时，批准才有效。
3. 如果审查范围已过时、缺失、含糊不清，或与新证据矛盾，则在编辑前重新运行 Audit。
4. 在进行更改前，重述已批准的批次。
5. 仅应用最小的已批准批次。不得擅自扩大范围。
6. 如果已批准的修复措施是安装步骤，请使用 references/install-guidance.md 中的确切 npx skills add ... 指引。
7. 编辑后，重新运行表面发现和针对已触及 harness 的 dry-run 检查，然后总结剩余差距。
8. 对于已批准的 rig-ecosystem-index Grok 回执，不得使用跨 harness 的广泛 skill-sync apply。分阶段应用确切的回执摘要： 在运行以下命令前，重新确认原生工作流／插件验证证据仍覆盖回执中未更改的源哈希：

   uv run python skills/harness-master/scripts/grok_workflow_projection.py apply \
     --receipt <receipt.json> --receipt-sha256 <approved-sha256> --format json
   

   启动全新的 Grok 进程，验证一个由插件拥有且可由用户调用的 skill、确切的工作流字节、无副作用的帮助信息，以及工作流验证。只有所有 canary 均通过后，才能使用同一已批准的回执迁移已识别的旧版字节：

   uv run python skills/harness-master/scripts/grok_workflow_projection.py migrate \
     --receipt <receipt.json> --receipt-sha256 <approved-sha256> \
     --canaries-passed --format json
   

   如果失败，只运行同一回执的 rollback 命令。回滚会先恢复所有已验证的旧版备份，然后最后移除新投射的匹配字节，以避免恢复失败时 Grok 失去可用的工作流。 移除操作要求存在属于该确切回执摘要和事务的活动持久所有者标记。在丢弃由回执拥有的投射 inode 之前，回滚会将该标记转换为事务专属的 rolled-back 墓碑，并确保文件和目录均已同步。墓碑会永久保留，以防过期回执认领后续事务中内容相同的字节。若标记缺失、不同或已成为墓碑，则保留任何公开投射。旧版和投射内容的移除均使用绑定 inode 的防覆盖隔离；若出现相同哈希替换竞态，则安全失败。

模式 C：发现

只读地扩展差距并开展受 harness 范围约束的研究。加载 references/discovery-pipeline.md 和 references/discovery/coordinator-contract.md。

1. 分类深度（full、focused、candidate、compare、w0only、ideate、journal）。
2. 如果该深度需要查找差距，则在任何 scout 之前运行 W0 脚本。
3. 在 W2/W2b 内使用 source_probe.py 和 candidate_score.py，不得将其作为独立的面向用户模式。
4. 在用户确认前，禁止 apply/install；配置修复需要 Audit + apply approved。

模式 D：使用情况审查

使用此模式处理 usage，或以自然语言提出的令牌成本、配额、工具使用阻碍、MCP 使用情况、技能适配度、插件适配度、上下文健康状况、会话归属或运行框架遥测状况审查请求。

1. 将整个模式视为只读。不要编辑文件、安装软件包、创建任务、导出原始会话、打印原始提示词、打印原始跟踪记录，或修改运行框架配置。
2. 规范化运行框架、级别和使用时间窗口。若未指定时间窗口，默认设为 14 天。
3. 执行界面发现和安全使用情况探测：

   uv run python scripts/usage_probe.py --repo-root . --harness <canonical-harness> --level <level> --days <days> --json
   

4. 加载 references/usage-review.md、references/evidence-boundaries.md 和 references/output-format.md。
5. 仅在与请求的运行框架和隐私类别相匹配时，才使用 token_stats、token_history、token_export、insights_collect、agent_attribution、quota_status、gemini_quota、workspace-summary 和 git-smart-status 等运行时工具。
6. 将发现归纳为使用情况信号，并对来源覆盖率、隐私安全、成本／令牌状况、工具效率、MCP 卫生状况、技能适配度、插件适配度、上下文健康状况、审批安全性和建议可执行性进行评分。
7. 报告建议类别：keep、tune-config、tune-skill、tune-mcp、tune-plugin、tune-workflow、instrument、defer 或 do-not-change。
8. 如果用户要求应用使用情况审查建议，应阻止应用步骤，并要求先进行匹配的 Audit 试运行，再获得明确批准。

扩展策略

范围	策略
小型	1 个运行框架和 1 个级别：内联审查，并为每个运行框架生成一份报告
中型	2–3 个运行框架或一个 both 范围：分别审查每个运行框架，然后补充简短的综合结论
大型	4 个以上运行框架或 all：尽可能批量发现，严格保留各运行框架的独立章节，最后进行跨运行框架综合分析并按优先级排列清理顺序
Discover（完整／聚焦）	使用 Pattern F 语义：探索来源、为候选项评分、综合证据，并在应用更改前停止
支持团队协作的 Discover	使用 Pattern E 或嵌套波次来侦察来源类别，并核算每个已派出的侦察任务
使用情况审查	优先使用聚合探测和运行时摘要；避免读取原始记录、原始跟踪记录、机密文件和消息表

最新文档查找策略

使用当前可用的最新权威指南：

1. llms.txt 或等效的官方索引
2. 关于配置、指令、规则、MCP 和权限的第一方文档页面
3. 若第一方产品文档不完整，则使用规范的供应商代码仓库文档
4. 仅在上述来源不可用时使用网页备用来源

没有当前来源的证据时，绝不要声称内容是 latest。

各运行框架审查约定

• 撰写任何综合结论前，先独立审查每个运行框架。
• 将每项发现标记为 verified-file、verified-doc、repo-observed 或 blind-spot。
• 展示所选级别对应的权威、次级、生成和合并配置界面。
• 对于 both，在建议更改前报告项目级／全局冲突。
• 如果当前会话无法观察特定运行框架的原生界面，应将其标记为盲区，而非臆造其行为。

安装指南约定

• 仅当用户询问如何安装 harness-master，或缺少技能是实际根本原因时，才加载 references/install-guidance.md。
• 默认展示形式：

  npx skills add <source> --skill harness-master -y -g --agent claude-code --agent codex --agent crush --agent cursor --agent opencode
  

• 对于原生配置问题，不要推荐安装命令。
• 默认不要建议在项目本地安装。只有用户明确要求在项目本地安装时，才提及 python scripts/install_skills.py --local --execute。

验证约定

更改此技能后，运行：

python scripts/check.py
uv run python skills/skill-creator/scripts/audit.py skills/harness-master/
uv run python skills/skill-creator/scripts/package.py skills/harness-master/ --dry-run
uv run pytest tests/test_grok_workflow_projection.py tests/test_grok_doctor_json.py -q
uv run python scripts/usage_probe.py --repo-root . --harness opencode --level both --days 14 --json
uv run python scripts/discover_surfaces.py --repo-root . --level both --harness claude-code --harness claude-desktop --harness chatgpt --harness codex --harness cursor --harness cursor-cli --harness grok-build --harness opencode --harness perplexity-desktop --harness cherry-studio --harness lm-studio

完成标准：

• 元数据和评估清单通过验证
• 打包仍具备可移植性
• 表层发现冒烟检查接受每个规范 harness
• dry-run/apply 行为仍要求在编辑前获得批准
• Discover 仍为只读，并会阻止 apply，直到相匹配的审计获得批准
• 使用情况审查仍为只读，会对敏感来源进行脱敏，并会阻止 apply，直到相匹配的审计获得批准

跨 Harness 综合约定

完成所有针对各 harness 的审查后，综合以下内容：

• 各 harness 共有的问题
• 相互冲突的约定或优先级规则
• 重复的指令来源或 MCP 定义
• 生成内容与规范内容之间的偏差模式
• 如果用户希望后续批量应用更改，优先级最高的清理顺序

输出约定

每份针对单个 harness 的报告都必须包含：

1. Harness
2. 层级
3. 审查的文件
4. 检查的文档
5. 项目上下文摘要
6. 盲点
7. 评分卡
8. 发现
9. 建议的更改
10. 拟议补丁预览
11. 置信度

审查了 2 个或更多 harness 时，还要添加跨 harness 综合部分。

参考文件索引

文件	内容	阅读时机
references/workflow.md	逐关卡审计／应用工作流、优先级规则、降级模式和审批关卡详情	Audit、Apply Approved
references/latest-doc-sources.md	各执行环境的官方 llms.txt 和文档 URL，以及回退顺序	刷新最新文档
references/harness-surfaces.md	项目／全局界面、优先级、安装 Agent 名称、生成／合并的说明	解读界面
references/harness-checklists.md	各执行环境的审计检查清单和边缘情况	按执行环境审查
references/evidence-boundaries.md	证据标签、盲点处理和矛盾策略	报告发现
references/install-guidance.md	准确的 npx skills add ... 命令、何时展示这些命令以及反模式	安装指导
references/output-format.md	各执行环境和跨执行环境的报告模板	最终输出
references/discovery-pipeline.md	W0–W4 探索阶段、深度推断、证据与契约、重定向	Discover
references/discovery/	协调器契约、侦察模板、输出格式、研究整合	Discover 侦察和报告
references/ecosystem-research.md	旧版来源系列说明；分派时优先使用 discovery-pipeline.md	Discover W2 来源规划
references/source-profiles.md	来源系列、程序化访问、置信度角色和来源降级行为	Discover W2 来源规划
references/usage-review.md	只读用量来源、隐私类别、评分卡、信号架构和建议路径	用量审查
data/research-sources.json	用于来源规划和探测脚本的机器可读来源注册表	Discover W2 来源规划

仅阅读当前步骤所需的参考文件。不要预加载所有参考文件。

渐进式披露

按照当前模式的指示加载参考文件。不要一次性加载所有参考文件；应使用分派表、来源计划和最终输出需求，选择最精简的相关文件集。

规范词汇

这些术语是 harness-master 报告的规范用语，应严格使用。

请始终严格使用以下术语：

术语	含义	而非
harness	一种受支持的 Agent／运行时目标	editor、toolchain
level	审查范围：project、global 或 both	environment
project surface	仓库本地的文件或由 harness 使用的生成产物	global config
global surface	仓库外的用户级 harness 配置	project file
dry-run	仅显示发现项和补丁预览；不做任何修改	apply
approval gate	修改前必须获得用户明确同意	implied approval
blind-spot	当前会话中无法观察到的界面或行为	guess
repo-observed	根据当前代码库中实际的 harness 接线方式推断出的行为	official-doc evidence
patch preview	修改前展示的拟议差异或代码片段	applied change
canonical source	应修改的文件或配置，而非生成的输出	generated surface
source plan	只读的来源清单，包括 URL／命令、环境变量、证据字段和故障模式	apply plan
candidate dossier	针对单个生态系统候选项的规范化证据包	endorsement
support tier	由证据和验证状态支撑的采用就绪度类别	popularity rank
quarantine	存在凭证、代理、破坏性、攻击性或广泛权限风险的候选项类别	rejection without review
usage signal	关于令牌、成本、配额、工具、MCP、技能、插件或工作流行为的脱敏汇总证据	raw transcript
privacy class	敏感度类别，用于决定是否可以收集或汇总某个来源，或是否必须仅手动处理	permission bypass

关键规则

1. 每次新的 harness-master 运行都会从试运行审核模式开始。
2. 未获得用户明确批准前，绝不编辑。
3. 只有在当前会话中完成匹配的试运行审核后，Apply Approved 才有效。
4. 只询问缺失的输入。绝不重复询问已确认的 harness 或级别。
5. 提出 harness 变更建议前，始终检查项目上下文。
6. 声称配置是最新或已过时时，始终先查阅最新的官方指南。
7. 明确标记盲点。不要猜测隐藏设置或仅限 UI 的设置。
8. 有明确证据时，优先编辑规范源，而非生成或合并后的输出。
9. 每项发现都必须带有证据标签：verified-file、verified-doc、repo-observed 或 blind-spot。
10. 正确的编辑方案明确时，提供具体的补丁预览。
11. 只有确实应当安装时，才使用 npx skills add ...。
12. 必须清楚拒绝不受支持的 harness，并列出受支持的集合。
13. 生态系统研究仅供参考且只读。绝不能仅依据研究报告应用变更。
14. 带凭证的 API 属于可选增强项。缺少凭证会降低置信度，但不会阻止基线源规划。
15. GitHub GraphQL 用于增强已知候选仓库；广泛发现时应使用 REST／搜索或代码／文件查找。
16. Usage Review 仅供参考且只读。绝不能仅依据使用情况发现应用配置变更、安装工具、导出原始会话或打印原始提示词／跟踪记录。
17. Usage Review 可以使用聚合安全且经过清理的元数据源，但不在范围内的内容包括机密文件、凭证值、原始转录、原始跟踪记录和原始消息表正文。
18. 只有在路径规范化、清单有效，并且可读取的便携式 SKILL.md 前置元数据与目录／名称匹配且描述非空时，已配置的 Grok 插件才是仓库技能所有者。所有权无效时，专用激活必须默认失败，且不得改变外部技能回退行为。
19. 已保存工作流投影、由 canary 控制的旧版迁移和回滚，必须全部使用完全相同的回执摘要。绝不覆盖不一致的工作流，也绝不在发现根目录下保留工作流备份。派生变更锁之前，先验证完整的回执路径／回滚结构；移除投影工作流时，只能使用其精确的活动应用所有者标记。丢弃回执所有的工作流 inode 前，先发布并持久同步该事务专属的 rolled-back 墓碑；绝不删除该墓碑。