菜单
§20.3 Test-Lock 规则（铁律 #14）。当 Claude 编辑测试文件 (tests/、__tests__/、 *.test.{ts,tsx,js,jsx,py}、*.spec.*、*_test.{py,go}) 时自动加载。强制： AI 只能改实现不能改断言；改测试需符合合法场景之一并显式标注 commit message。 配套 .claude/hooks/test-lock-guard.sh 注入 PreToolUse 提醒。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
yakuten (hrtyaku.com) 网站运营/SEO 作战入口。当用户要求：分析 GA/GSC 数据、看流量/排名/搜索词、 出 SEO 报告、推荐 SEO 文章选题、优化 CTR/meta/AEO、内容更新计划、"网站运营" 等任务时触发。 分析由 Claude 本人完成（不调 Gemini；scripts/seo/ai-analyze.mjs 仅为 CI 无人值守备用）。
§37 Constitution 协议自动加载器（对齐 GitHub Spec Kit）。当用户请求涉及 spec/plan/ feature/architecture/decision/release 或开始新任务时自动触发。读取项目 docs/ai-cto/CONSTITUTION.md 并把项目特定的不可妥协约束注入响应。
§35 Eval-Driven Development 强制规则（铁律 #12）。当 Claude 编辑 .claude/commands/、 .claude/agents/、.claude/skills/、.agents/skills/、CLAUDE.md、playbook/handbook.md、 .claude/output-styles/ 等 prompt/agent 配置类文件时自动加载。 强制：无 eval 不进 main。配套 eval-gate.sh 注入 PostToolUse 提醒。
§32.1 Forbidden 路径强制规则。当 Claude 编辑 auth/payment/billing/secrets/keys/migration/ crypto/infra/terraform/ansible/.github/workflows 路径下文件时自动加载。要求 spec-driven、 双签、PR 标签 requires-double-review。配套 .claude/hooks/forbidden-guard.sh 硬阻止 (exit 2)；本 skill 提供 Claude 应如何响应被阻止时的处理流程。
ai-playbook handbook (3986 行) 智能查询入口。当用户/任务提到 §NN.M 章节号、 "手册"、"playbook"、"铁律 #N"、"反模式"、"竞品" 等关键词时自动触发。 读 INDEX.md 决定该读哪段 handbook，避免每次塞 3986 行全文进上下文。
v3.9 Bugbot-style learned rules 自动加载器（Cursor 启发，44k learned rules 验证）。 当 Claude 触及 .claude/rules/learned/ 目录或被 /cto-evolve apply 写入新 learned rule 时自动加载。把项目历次自审 / cross-review / commit 沉淀的具体教训注入上下文， 避免重复犯同类错。
| name | test-lock-rules |
| description | §20.3 Test-Lock 规则（铁律 #14）。当 Claude 编辑测试文件 (tests/、__tests__/、 *.test.{ts,tsx,js,jsx,py}、*.spec.*、*_test.{py,go}) 时自动加载。强制： AI 只能改实现不能改断言；改测试需符合合法场景之一并显式标注 commit message。 配套 .claude/hooks/test-lock-guard.sh 注入 PreToolUse 提醒。 |
| user-invocable | false |
| paths | ["**/tests/**","**/test/**","**/__tests__/**","**/*.test.ts","**/*.test.tsx","**/*.test.js","**/*.test.jsx","**/*.spec.ts","**/*.spec.js","**/*_test.py","**/test_*.py","**/*_test.go"] |
你正在编辑测试文件。AI 时代 TDD 最大风险是 作弊式 TDD：实现失败 → 改测试让其通过。 本规则强制：AI 只能改实现，不能改断言（除非满足下列合法场景）。
| 场景 | commit msg 标记 | 示例 |
|---|---|---|
| ① Spec 变更 | spec-change: | spec-change: 用户登录失败计数从 3 → 5（per SPEC.md §2.1） |
| ② Bug 修复 | bug-fix: 或 fix: | bug-fix: 测试本身有 bug，断言错了 sign convention |
| ③ 新增测试 | test: （仅添加） | test: 加 edge case empty input |
| ④ Refactor | refactor(test): | refactor(test): 提取共用 setup 到 fixture，断言不变 |
| # | 规则 | 你应如何遵守 |
|---|---|---|
| 1 | Test-Lock | 编辑测试文件时显式声明属于哪类合法场景 |
| 2 | Spec → Test → Code 顺序 | 不能先改 test 后改 SPEC（铁律 #2） |
| 3 | Mutation Gate ≥ 80% | 改完跑 Stryker / PIT / mutmut 验证 |
| 4 | Property-based 强制 | fast-check / Hypothesis ≥ 1 条 |
| 5 | 失败回灌 | 把 stderr 给用户，不假设期望行为 |
"本次编辑
tests/foo.test.ts属于场景 [①/②/③/④]：<具体理由>。 commit message 会标[spec-change|bug-fix|test|refactor]:。"
直接拒绝 + 引导：
"这违反铁律 #14 Test-Lock。改测试让实现通过 = 作弊式 TDD。 正确做法：
- 把失败的测试输出告诉我
- 我们一起诊断实现为什么不符合断言期望
- 修实现而不是断言 如果断言本身错了（场景 ②），需要先有证据：参考文档/SPEC/原作者意图。"
→ 触发 §33 vibe 警告（vibe-prompt-guard 会拦关键词）。 → 反问："为什么这个测试不重要？是否有 spec 依据可以删它？"
| 反模式 | 识别信号 |
|---|---|
| 改断言数字让通过 | expect(x).toBe(3) → expect(x).toBe(5) 而实现也改了 |
| 注释掉 failing test | // it.skip(...) 或 xit(...) 没解释 |
| 删测试文件 | Write tool 写空内容到现有 test file |
--passWithNoTests | jest config 突然加这选项 |
.claude/hooks/test-lock-guard.sh（注入提醒层）.claude/rules/test-lock.md（详细 5 条规则）