测量与改进

本指南的一切浓缩为一条命令：

npx harness-score

扫描器遍历你的仓库（仅读取文件系统 — 无 LLM、无网络、无遥测），对任意 AI 工具运行 36 项确定性检查，报告成熟度等级及距下一级的精确差距：

  harness-score v1.0.0  /work/my-app

  Maturity: L2 · Guided   Score: 66/108 (61%)
  Detected: Cursor, Claude Code

  Context & Guides     ████████████████░░░░  80%
  Skills & Commands    █████████████░░░░░░░  67%
  Hooks & Guardrails   ░░░░░░░░░░░░░░░░░░░░   0%
  ...

  To reach L3: sensors ≥ 60%; ci ≥ 50%

多工具： 扫描器通过 OR 语义识别 Cursor、Claude Code、Windsurf、Cline、Continue 等工具的 harness 产物 — 配置任一工具即计入 Harness Score。详见 多 harness 支持。

安装

npx harness-score                                       # no install
npm install -g harness-score                            # global binary
npm install --save-dev harness-score                    # pinned devDependency

亦镜像于 GitHub Packages （@paladini/harness-score）与 JSR， 供 Deno/Bun 项目使用。

作为库使用

CLI 是完整类型化编程 API 的薄包装 — 适用于自定义仪表盘、机器人，或任何需要原始 Report 而非解析终端输出的工具：

import { score } from 'harness-score';

const report = score('/path/to/repo');
console.log(report.level.name, report.score.percent, report.dimensions);
// With global scopes: score(path, { scopeFlags: ['user'] })
console.log(report.effective.level.index);

Report、Check、CheckResult、DimensionScore、LevelInfo、ScoreSnapshot 及所有其他类型均以 TypeScript 声明导出 — 通过显式 "types" 字段解析，编辑器与 tsc 无需额外配置即可识别。更低层构建块同样导出，供 score() 未直接覆盖的场景使用：

import { score, computeDiff, renderMarkdown } from 'harness-score';

const report = score('/path/to/repo');
const markdown = renderMarkdown(report);          // same renderer the CLI's --md uses

扫描配置

默认情况下，扫描器仅测量仓库成熟度 — 随代码一起流转、在 CI 中可复现的 harness。可选包含用户级或共享 harness 树以得到 effective 分数（开发者笔记本上 agent 可能看到的内容）。

{
  "scopes": { "user": false, "system": false },
  "extraRoots": [{ "id": "team-shared", "path": "../shared-harness" }],
  "gate": "maturity"
}

保存为扫描根目录的 .harness-score.json，或传递 --config <file>。完整键参考：指标与代码 — 配置。

harness-score --scope user              # repo + ~/.cursor, ~/.claude, …
harness-score --scope user,system
harness-score --gate effective --min-level 2   # gate on effective score

终端报告显示 Maturity（repo）与 Effective（当两者不同时）。CI 应保持 gate: maturity，除非你刻意在带有用户 harness 的自托管 runner 上运行。

CLI 参考

harness-score [path]              # human report (default: current directory)
harness-score --json              # full report as JSON
harness-score --md report.md      # markdown report (use "-" for stdout)
harness-score --badge badge.svg   # SVG pill: harness + detected level (L0–L4)
harness-score --min-level 3       # exit 1 if below L3 — the CI gate (uses gate mode)
harness-score --diff base.json    # compare maturity against a previous --json report
harness-score --config .harness-score.json
harness-score --scope user        # include user-level harness in effective score
harness-score --gate maturity     # or effective — which score --min-level uses

随时间跟踪分数

--diff <file> 将当前扫描与较早一次 --json 运行保存的基线报告对比 — 等级与分数的增量、各维度变动，以及具体哪些检查项发生了变化：

harness-score --json > baseline.json   # save today's report
# ...later, after changes...
harness-score --diff baseline.json     # see what moved

  Compared to baseline:
    Level: L2 · Guided → L3 · Sensing (+1)
    Score: 61/108 (56%) → 84/108 (78%) (+22pp)
    Sensors & Feedback   20% → 90% (+70pp)
    Newly passing: SNS-01, SNS-02, SNS-04, CI-01, CI-02

--diff 可与 --json（向 payload 添加 current/baseline/diff）及 --md（添加「Compared to baseline」章节）配合使用 — GitHub Action 借此在 PR 上评论「harness 分数从 L2 升到 L3」。

Cursor 插件

从 本仓库的插件目录 安装 Harness Score （Cursor Marketplace 上架申请已提交、待审核 — 上线后此链接将移至该处），你将获得：

• /harness-audit — 在打开的工作区运行扫描器，让智能体展示报告及主要修复建议。
• harness-engineering skill — 当你说「修一下」或「改进我的 harness」时，智能体知道如何按本指南的方案编写缺失产物。

分析本身始终是确定性 CLI；模型只负责展示结果，并按你的要求应用修复。

CI 门禁

Harness 会静默退化 — 有人在清理时删掉 hooks.json，规则文件任其腐烂。在 CI 中锁定等级：

- name: Harness gate
  run: npx -y harness-score --min-level 3

或使用打包 action，同时生成徽章：

- uses: paladini/harness-score@v1
  with:
    min-level: '3'
    badge: 'harness-badge.svg'

展示成熟度

Harness Score 提供两种品牌 SVG 格式，与扫描器进度条同一视觉语言 — 不依赖 shields.io、无需付费服务、渲染时无需联网：

格式	文件	显示内容	最佳用途
徽章	harness-badge.svg 或 badge-l0.svg … badge-l4.svg	harness · L4	README 行（112×20 胶囊形徽章）
分享卡片	card-l0.svg … card-l4.svg	带等级名称的完整横幅	社交帖、仓库头图（860×240）

徽章始终仅显示等级（L0–L4）。等级名称 （Unharnessed、Guided…）出现在分享卡片与扫描器输出中。

无论 CI 重新生成还是固定静态文件，胶囊形徽章外观相同 — 只是接入方式不同。

徽章 — 自动更新（推荐）

harness-score --badge 为扫描器检测到的等级写入 SVG。 在 CI 中配置一次；README 中的图片会随 harness 改进自动更新。

# .github/workflows/harness.yml
name: Harness Score
on: { push: { branches: [main] } }
permissions: { contents: write }
jobs:
  harness:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: paladini/harness-score@v1
        with: { badge: 'harness-badge.svg' }
      - uses: JamesIves/github-pages-deploy-action@v4
        with: { branch: badges, folder: ., clean: false }

在 README 中引用已发布文件 — 完整复制粘贴方案见 嵌入片段：

<img alt="Harness Score" src="https://raw.githubusercontent.com/<you>/<repo>/badges/harness-badge.svg" height="20">

在 <img> 上设置 height="20"，使胶囊形徽章与同行的 npm/CI shields 对齐 （112×20 SVG；仅显示等级 — 分数百分比留在 CLI 报告中）。

本仓库自举示例（本指南在 GitHub Pages 上的实时徽章）：

Badge (this repo)

与检测等级匹配的分享卡片发布为 harness-card.svg（本仓库当前为 L4）：

徽章 — 固定等级

同一胶囊形徽章、静态文件 — 若不想由 CI 重新生成图片，选用 badge-l0.svg … badge-l4.svg。 Markdown、HTML、iframe、JSX 等用法见 嵌入片段。

分享卡片

用作头图或社交帖时，使用横幅式分享卡片 — 包含等级名称 （Unharnessed、Guided…）：

Level	Badge	Share card
L0 · Unharnessed	badge-l0.svg	card-l0.svg
L1 · Documented	badge-l1.svg	card-l1.svg
L2 · Guided	badge-l2.svg	card-l2.svg
L3 · Sensing	badge-l3.svg	card-l3.svg
L4 · Self-correcting	badge-l4.svg	card-l4.svg

All badge levels (112×20)

Share card example (860×240)

从上方表格下载任意等级 — 分享卡片包含等级名称。

嵌入片段

复制粘贴即可分享的方案。替换占位符：

占位符	自动更新徽章	固定徽章（等级 {N}）	分享卡片
{BADGE_URL}	https://raw.githubusercontent.com/{owner}/{repo}/badges/harness-badge.svg	https://paladini.github.io/harness-score/maturity/badge-l{N}.svg	—
{CARD_URL}	—	—	https://paladini.github.io/harness-score/maturity/card-l{N}.svg
{LINK}	你的仓库或 https://paladini.github.io/harness-score/	同上	同上

{N} 为 0–4。本仓库的实时徽章（你的 fork 无需 CI）： https://raw.githubusercontent.com/paladini/harness-score/main/docs/public/harness-badge.svg

徽章尺寸： 112×20 — 始终设置 height="20"（或 height={20}），使胶囊形徽章与同行的 shields.io 徽章对齐。

徽章 — Markdown

仅图片（GitHub、GitLab、dev.to — 若纯 ![]() 会被拉伸，请用 HTML）：

<img alt="Harness Score L4" src="{BADGE_URL}" height="20">

带链接（可点击）：

[![Harness Score L4]({BADGE_URL})]({LINK})

引用式：

[![Harness Score][hs-badge]][hs-link]

[hs-badge]: {BADGE_URL}
[hs-link]: {LINK}

徽章 — HTML

<img alt="Harness Score L4" src="{BADGE_URL}" height="20" width="112">

带链接：

<a href="{LINK}">
  <img alt="Harness Score L4" src="{BADGE_URL}" height="20" width="112">
</a>

徽章 — iframe

适用于仅允许 iframe、不允许 <img> 的 CMS 或 wiki：

<iframe
  src="{BADGE_URL}"
  title="Harness Score L4"
  width="112"
  height="20"
  style="border:0;overflow:hidden"
></iframe>

徽章 — SVG object / embed

<object data="{BADGE_URL}" type="image/svg+xml" width="112" height="20">
  <a href="{BADGE_URL}">Harness Score L4</a>
</object>

<embed src="{BADGE_URL}" type="image/svg+xml" width="112" height="20" />

徽章 — JSX / React

<a href="{LINK}">
  <img
    alt="Harness Score L4"
    src="{BADGE_URL}"
    height={20}
    width={112}
    style={{ verticalAlign: 'middle' }}
  />
</a>

徽章 — AsciiDoc

image:{BADGE_URL}[Harness Score L4,link={LINK},height=20]

徽章 — BBCode（论坛）

[url={LINK}][img]{BADGE_URL}[/img][/url]

徽章 — 直接 URL

粘贴到聊天、Notion 图片块、Slack、Discord，或任何接受原始图片 URL 的工具：

{BADGE_URL}

分享卡片 — Markdown / HTML

用于 README 头图、博客或社交预览的横幅（{N} = 0–4）：

[![Harness Score L4 · Self-correcting]({CARD_URL})]({LINK})

<a href="{LINK}">
  <img
    alt="Harness Score L4 · Self-correcting"
    src="{CARD_URL}"
    width="560"
    style="max-width:100%;height:auto;border-radius:8px"
  />
</a>

分享卡片 — iframe

<iframe
  src="{CARD_URL}"
  title="Harness Score L4 · Self-correcting"
  width="560"
  height="157"
  style="border:0;max-width:100%"
></iframe>

分享卡片 — 直接 URL

{CARD_URL}

完整示例（固定 L3 徽章）

<a href="https://paladini.github.io/harness-score/">
  <img alt="Harness Score L3" src="https://paladini.github.io/harness-score/maturity/badge-l3.svg" height="20">
</a>

<iframe
  src="https://paladini.github.io/harness-score/maturity/badge-l3.svg"
  title="Harness Score L3"
  width="112"
  height="20"
  style="border:0"
></iframe>

shields.io 爱好者？ 你的 Action 也可以写入一个小 JSON 文件，并指向 shields endpoint （{ "schemaVersion": 1, "label": "harness", "message": "L3", "color": "brightgreen" }）。 上方的品牌 SVG 自包含，无需第三方。

检查目录

扫描器运行的每一项检查及其修复方案。检查 ID 稳定；CLI 将每项失败链接到此条目。

Context & Guides (20 pts)

CTX-01 · Agent context file present — 4 pts

存在项目 guide：根目录 AGENTS.md、CLAUDE.md 或 GEMINI.md，或 Claude Code 在 .claude/CLAUDE.md / .claude/AGENTS.md 的 session-start 说明（非 scoped rules）。 修复： 创建 AGENTS.md，回答：项目是什么、如何构建与测试、有哪些约定、哪些地方绝对不能动。方案见 第 3 章。

CTX-02 · Context file is substantive — 3 pts

≥20 行有意义的内容且 ≥2 个标题 — 占位内容不得分。 修复： 涵盖目录结构、构建与测试命令、约定、禁止区域。 优先写命令而非描述；指向 rules 而非粘贴全文。

CTX-03 · Scoped rules in use — 4 pts

任意受支持工具至少有一条 scoped rule 文件（如 .cursor/rules/*.mdc、 .windsurf/rules/*.md、.clinerules/*.md、.continue/rules/*.md、 .github/instructions/*.instructions.md、.agents/rules/*、.claude/rules/**/*.md）。代码子目录中的嵌套 context 文件（根目录以下、且非 .claude/CLAUDE.md 或 .claude/AGENTS.md 的 AGENTS.md、CLAUDE.md、GEMINI.md）同样计入 — 在 Claude Code、Codex 等工具中，它们相当于目录级 rules。 修复： 先写一条简短的 always-on rule 承载不可妥协的底线， 再按区域添加 path-scoped rules（或按子树添加嵌套 context 文件）。

CTX-04 · Rules have valid frontmatter — 3 pts

每条 rule 都声明激活元数据（description、globs/trigger/paths/applyTo，或 alwaysApply）。 工具无需元数据即自动加载的 rules — .continue/rules/*、.claude/rules/*（仅可选 paths）与嵌套 context 文件 — 按设计即通过。 修复： 添加 frontmatter 块；没有它，智能体无法判断 rule 何时生效。

CTX-05 · Rules are scoped — 2 pts

并非每条 rule 都是全局 always-on。嵌套 context 文件视为 scoped — 仅作用于其所在子树。Claude Code 的 .claude/rules/*.md 若无 paths frontmatter 则为 always-on；仅保留一条无 paths 的 rule，或使用 paths: 限定范围。 修复： 将 rules 限定到路径（globs:、trigger: glob、paths:、applyTo:）， 仅在相关时加载 — 每条 always-on rule 都会占用每次请求的 context。

CTX-06 · No bloated rules — 2 pts

单条 rule 不超过 500 行。 修复： 按关注点拆分，或将流程性内容移入 skill。

CTX-07 · README present — 1 pt

修复： 添加 README.md；它是人类的首要导向文档，也是智能体的后备参考。

CTX-08 · No legacy .cursorrules — 1 pt

已弃用的单文件格式不存在（或另有现代 scoped rules）。 修复： 将 .cursorrules 内容迁移到对应工具的 scoped rules。

Skills & Commands (17 pts)

SKL-01 · At least one skill — 4 pts

.cursor/skills/<name>/、.claude/skills/<name>/、.agents/skills/<name>/ 下存在 SKILL.md；或当扫描根为 Claude Code / Cursor plugin 仓库时，在默认 plugin skills/<name>/ 下（扫描根存在 .claude-plugin/plugin.json 或 .cursor-plugin/plugin.json）。 修复： 将最常重复的流程（部署、发布、迁移） 封装为 skill — 第 3 章。

SKL-02 · Skills declare name and description — 3 pts

每条 skill 的 frontmatter 含 name: 与 description:。 修复： 智能体仅凭这两个字段决定是否加载 skill； 缺少它们，skill 等于不可见。

SKL-03 · Explicit workflows/commands defined — 3 pts

存在 command 或 workflow 文件（.cursor/commands/、.windsurf/workflows/、 .claude/commands/、.continue/prompts/、.zed/commands/、.agents/workflows/，或扫描根下的 plugin commands/）。 修复： 将你有意触发的 workflow（/review、/release） 编码为 command/workflow 文件。

SKL-04 · Skill descriptions are trigger-worthy — 2 pts

description ≥40 字符。 修复： 将 description 写成触发条件 — 「当用户要求部署或发布时使用；涵盖打 tag、流水线、回滚、冒烟测试。」

AGT-01 · Custom subagent defined — 3 pts

.cursor/agents/、.claude/agents/、.opencode/agents/ 或扫描根下的 plugin agents/ 下存在 subagent 文件。 修复： 为主智能体应委派的任务（规划、审查、发布）封装专用 subagent — 见 Subagents （第 2 章）。

AGT-02 · Subagents declare name and description — 2 pts

每条 subagent 定义的 frontmatter 含 name: 与 description:。 修复： 父智能体仅凭这两个字段决定是否委派； 缺少它们，subagent 永远不会被调用。

Hooks & Guardrails (14 pts)

Harness 工件既可从仓库根目录按规范路径识别，也可在工具目录本身作为扫描根目录时识别。 例如，扫描 .claude 时，物理路径 settings.json、hooks/、skills/ 和 agents/ 会被识别为对应的 .claude/... 路径；扫描 .devin 时，同样识别 hooks.v1.json、 config.json（hooks 键）、hooks/ 和 skills/。扫描 plugin 仓库根（扫描根存在 .claude-plugin/plugin.json 或 .cursor-plugin/plugin.json）时，默认识别 skills/、commands/、 agents/ 与 hooks/hooks.json 为对应工具的规范路径；树内其他位置的嵌套 plugin manifest 不会启用此别名。其他名称的通用根目录不会应用此规则。证据始终使用 实际读取的物理路径。

HKS-01 · Hooks configuration present and valid JSON — 4 pts

.cursor/hooks.json、.claude/settings.json（hooks 键）、扫描根下的 plugin hooks/hooks.json、.devin/hooks.v1.json（独立 event 映射）或 .devin/config.json（hooks 键）存在且可解析为 JSON。当存在多个配置时，优先选择有效且非空的配置；再依次按原生根目录深度、事件数量 和路径字典序进行确定性选择。gitignore 的 .devin/config.local.json 不会被扫描。 修复： 创建 hooks 配置，并按 第 5 章 的方案逐步扩展。

HKS-02 · Hook events and handlers are structurally valid — 2 pts

事件映射非空，每个事件都包含有效 handler，并且包含供应商要求的元数据，例如 Cursor 的 version。Claude Code handler 可使用 command、http、mcp_tool、prompt 或 agent；每种类型都必须提供必填字段。目录包含 Claude Code 文档中的全部 31 个事件： SessionStart、Setup、InstructionsLoaded、UserPromptSubmit、UserPromptExpansion、 MessageDisplay、PreToolUse、PermissionRequest、PostToolUse、PostToolUseFailure、 PostToolBatch、PermissionDenied、Notification、SubagentStart、SubagentStop、 TaskCreated、TaskCompleted、Stop、StopFailure、TeammateIdle、ConfigChange、 CwdChanged、DirectoryAdded、FileChanged、WorktreeCreate、WorktreeRemove、 PreCompact、PostCompact、SessionEnd、Elicitation 和 ElicitationResult。Devin 的 独立映射文档列出 PreToolUse、PostToolUse、PermissionRequest、UserPromptSubmit、 Stop、PostCompaction、SessionStart 和 SessionEnd（无需 version 字段）。 向前兼容： 未知但结构有效的事件保留分数，并产生 unknown-hook-event warning。 空事件或结构错误的事件仍会失败。

HKS-03 · Gate hook guards risky operations — 4 pts

已注册 gate hook（Cursor：beforeShellExecution、beforeMCPExecution、 preToolUse 或 beforeReadFile；Claude Code 或 Devin：PreToolUse 或 PermissionRequest）。 修复： 添加第 5 章的 destructive-command deny gate — 文字 rules 是请求；gate 是事实。

HKS-04 · Feedback hook observes output — 2 pts

已注册 feedback hook（Cursor：afterFileEdit、postToolUse 等； Claude Code：PostToolUse；Devin：PostToolUse 或 Stop）。 修复： 编辑时 format-and-lint，让智能体在会话内获得即时反馈。

HKS-05 · Hook scripts committed — 2 pts

命令可执行文件、shell 命令或 args 条目中出现的每个仓库本地路径都必须解析到已提交文件。 ${CLAUDE_PROJECT_DIR}/.claude/hooks/check.js 与 ${DEVIN_PROJECT_DIR}/.devin/hooks/check.py 等项目前缀规范路径也会解析到原生根目录下的物理 hook 路径。Devin 使用 os.path.join(os.environ['DEVIN_PROJECT_DIR'], …) 形式的命令会在不执行 Python 的情况下解析。 不执行命令的有效 handler 没有适用的本地脚本，因此可以通过。 修复： 提交所有引用的本地脚本；任何一个缺失路径都会使 HKS-05 失败。

Sensors & Feedback (20 pts)

SNS-01 · Test runner configured — 6 pts

存在真实的测试脚本/配置（vitest、jest、pytest、go test、cargo test、 文件加载 node:test 时的 node --test、phpunit.xml、pest.php 等），或在 Composer 中声明的测试包 （phpunit/phpunit、pestphp/pest 等）。 修复： 配置 runner 并提供一个明确的入口，在 AGENTS.md 中记录 — 测试是智能体验证自身工作的方式。

SNS-02 · Linter configured — 5 pts

eslint/biome、ruff、golangci-lint、rubocop、phpcs/rector 或等价工具。 修复： 能用 lint rule 表达的约定就不再需要文字说明。

SNS-03 · Type checking in place — 4 pts

tsconfig（理想情况下 strict: true）、mypy/pyright/ty、phpstan/psalm，或静态类型语言。 修复： 类型检查器是唯一免费审查每次智能体编辑的传感器 — 第 4 章。

SNS-04 · Formatter configured — 3 pts

prettier/biome、black/ruff-format、gofmt/rustfmt、pint 或 php-cs-fixer （无配置文件时，composer.json 中的 laravel/pint 也算）。 修复： diff 中的格式噪音会掩盖审查中的真实错误。

SNS-05 · Test files exist — 2 pts

树中至少有一个真实测试文件。 修复： 配置了 runner 却没有测试，等于没人挣来的绿灯。

CI Feedback (14 pts)

CI-01 · CI pipeline configured — 4 pts

GitHub Actions workflow（或 GitLab/CircleCI/Jenkins 等价物），也包括 cloudbuild/ 下的 Google Cloud Build 配置。 检测基于文件系统，会计入扫描根目录下任意深度的文件，因此嵌套工作区项目中的 CI 文件也算。它不会验证 CI 平台是否实际执行该文件。 修复： 添加 .github/workflows/ci.yml，每次 push 运行传感器。

CI-02 · CI runs the tests — 4 pts

修复： 任何由智能体编写的变更，在未跑测试套件的情况下都不应可合并。

CI-03 · CI runs lint/typecheck — 3 pts

修复： 廉价的计算型传感器应随每次 push 运行 — 质量左移。

CI-04 · Pre-commit checks installed — 3 pts

husky/lint-staged、pre-commit、.githooks/pre-commit 或 lefthook。扫描到的路径中也会识别 pre-commit 配置文件。 修复： 提交能获得的最早反馈；在变更进入历史前捕获编辑时 hooks 漏掉的问题。

Hygiene & Safety (23 pts)

HYG-01 · .gitignore present — 2 pts

修复： 智能体会提交它看到的内容；让构建产物与本地状态不可见。

HYG-02 · .gitignore covers env files — 3 pts

.gitignore 中有 .env 模式。 修复： 添加 .env 与 .env.*（允许 !.env.example）— 最便宜的护栏。

HYG-03 · No unprotected .env files — 4 pts

树中无未 gitignore 的真实 env 文件（模板可保留）。 修复： 移走 secrets；保留 .env.example 记录所需变量。

HYG-04 · MCP config free of credentials — 4 pts

MCP 配置（.cursor/mcp.json、.mcp.json、 .agents/mcp_config.json）中无 credential 特征。 修复： 使用 ${ENV_VAR} 插值 — MCP 配置中的内联 key 等于向每个 clone 公开的 secret。

HYG-05 · License present — 2 pts

仓库根目录存在 LICENSE、LICENSE.md、LICENSE.txt 或 COPYING。 不适用： 该文件不存在，且根目录 composer.json 或 package.json 的 license 为 proprietary 或 UNLICENSED（闭源声明）。该 check 同时退出 分数的分子和分母。"private": true 与 Cargo 的 publish = false 不会触发 这一点。缺少文件且 license 为 MIT 等 SPDX id 时仍然失败。 修复： 添加 LICENSE；开源使用与插件 marketplace 所需。

HYG-06 · No secrets in harness files — 2 pts

AGENTS.md、rules 与 hooks 配置中无 token 特征。 修复： 这些文件每次会话都会加载进模型上下文 — 其中的 key 按设计会被泄露。

HYG-07 · Lockfile committed — 3 pts

package-lock.json、uv.lock、Cargo.lock、go.sum 或等价 lockfile。 修复： 可复现安装意味着传感器在各处测试同一依赖树。

HYG-08 · MCP config uses env interpolation for credentials — 3 pts

当存在 MCP 配置（.cursor/mcp.json、.mcp.json、.agents/mcp_config.json）时， 它必须是合法 JSON，且任何 credential 形字段（token、key、secret、password 等） 使用 ${ENV_VAR} 插值而非字面量。这是 HYG-04 的正面补充。 不适用： 仓库没有 MCP 配置。不使用 MCP 并不是缺少插值配置，因此该 check 同时退出分数的分子和分母。之后添加配置会使该 check 重新适用。 修复： 将 secrets 引用为 "${VAR_NAME}"，并在 .env.example 中记录所需变量。

实践改进计划

从典型的 L0 产品仓库出发，每级一轮专注工作：

1. → L1（一个下午）。 写 AGENTS.md（CTX-01/02）。即使传感器较弱，也要包含构建/测试 命令 — 智能体会用到它们。
2. → L2（一天）。 三条 scoped rules + 一个最常重复流程的 skill （CTX-03…06、SKL-01/02）。修复卫生项：gitignore、env 文件、 许可证（HYG-01…05）。
3. → L3（若缺传感器则是真功夫）。 测试 runner + linter + 严格类型 + 运行三者的 ci.yml（SNS-*、CI-01…03）。若已有， 这一级几乎免费。
4. → L4（一个上午）。 第 5 章的两个 hooks — 一个 gate、一个 formatter — 与脚本一起提交（HKS-*）、pre-commit（CI-04）， 然后在 CI 中设置 --min-level 4，使其永不退化。