원클릭으로 Manus에서 모든 스킬 실행

test-lock-rules

스타7

포크0

업데이트2026년 5월 27일 00:22

§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 페이지를 검토하고 설치를 진행할 수 있습니다.

Manus에서 실행

출처

cantascendia

cantascendia/yakuten

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Manus에서 실행

Test-Lock 规则 (§20.3 / 铁律 #14)

你正在编辑测试文件。AI 时代 TDD 最大风险是 作弊式 TDD：实现失败 → 改测试让其通过。本规则强制：AI 只能改实现，不能改断言（除非满足下列合法场景）。

4 个合法场景（必须在响应或 commit msg 显式标注）

场景	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，断言不变`

5 条防作弊规则（手册 §20.3）

#	规则	你应如何遵守
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 给用户，不假设期望行为

你应当如何响应

当 hook test-lock-guard 注入提醒时

不要无视提醒继续 Edit
在响应里显式说明：

"本次编辑 tests/foo.test.ts 属于场景 [①/②/③/④]：<具体理由>。 commit message 会标 [spec-change|bug-fix|test|refactor]:。"
改完后说明：
- 是否影响其他测试（断言语义有变？）
- 是否需要补 mutation testing
- commit message 实际写了什么

当用户要求"改测试让它通过"

直接拒绝 + 引导：

"这违反铁律 #14 Test-Lock。改测试让实现通过 = 作弊式 TDD。正确做法：

把失败的测试输出告诉我

我们一起诊断实现为什么不符合断言期望

修实现而不是断言如果断言本身错了（场景 ②），需要先有证据：参考文档/SPEC/原作者意图。"

当用户说 "skip tests" / "这个测试不重要"

→ 触发 §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 突然加这选项

引用

handbook §20.3 全文
CLAUDE.md 铁律 #14
.claude/hooks/test-lock-guard.sh（注入提醒层）
.claude/rules/test-lock.md（详细 5 条规则）

이 저장소의 다른 Skills

같은 저장소

seo-ops

cantascendia/yakuten

yakuten (hrtyaku.com) 网站运营/SEO 作战入口。当用户要求：分析 GA/GSC 数据、看流量/排名/搜索词、出 SEO 报告、推荐 SEO 文章选题、优化 CTR/meta/AEO、内容更新计划、"网站运营" 等任务时触发。分析由 Claude 本人完成（不调 Gemini；scripts/seo/ai-analyze.mjs 仅为 CI 无人值守备用）。

2026-07-107

constitution-loader

cantascendia/yakuten

§37 Constitution 协议自动加载器（对齐 GitHub Spec Kit）。当用户请求涉及 spec/plan/ feature/architecture/decision/release 或开始新任务时自动触发。读取项目 docs/ai-cto/CONSTITUTION.md 并把项目特定的不可妥协约束注入响应。

2026-05-277

eval-gate-policy

cantascendia/yakuten

§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 提醒。

2026-05-277

forbidden-policy

cantascendia/yakuten

§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 应如何响应被阻止时的处理流程。

2026-05-277

handbook-search

cantascendia/yakuten

ai-playbook handbook (3986 行) 智能查询入口。当用户/任务提到 §NN.M 章节号、 "手册"、"playbook"、"铁律 #N"、"反模式"、"竞品" 等关键词时自动触发。读 INDEX.md 决定该读哪段 handbook，避免每次塞 3986 行全文进上下文。

2026-05-277

learned-rules-loader

cantascendia/yakuten

v3.9 Bugbot-style learned rules 自动加载器（Cursor 启发，44k learned rules 验证）。当 Claude 触及 .claude/rules/learned/ 目录或被 /cto-evolve apply 写入新 learned rule 时自动加载。把项目历次自审 / cross-review / commit 沉淀的具体教训注入上下文，避免重复犯同类错。

2026-05-277

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"]

Test-Lock 规则 (§20.3 / 铁律 #14)

4 个合法场景（必须在响应或 commit msg 显式标注）

场景	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，断言不变`

5 条防作弊规则（手册 §20.3）

#	规则	你应如何遵守
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 给用户，不假设期望行为

你应当如何响应

当 hook test-lock-guard 注入提醒时

不要无视提醒继续 Edit
在响应里显式说明：

"本次编辑 tests/foo.test.ts 属于场景 [①/②/③/④]：<具体理由>。 commit message 会标 [spec-change|bug-fix|test|refactor]:。"
改完后说明：
- 是否影响其他测试（断言语义有变？）
- 是否需要补 mutation testing
- commit message 实际写了什么

当用户要求"改测试让它通过"

直接拒绝 + 引导：

"这违反铁律 #14 Test-Lock。改测试让实现通过 = 作弊式 TDD。正确做法：

把失败的测试输出告诉我

我们一起诊断实现为什么不符合断言期望

修实现而不是断言如果断言本身错了（场景 ②），需要先有证据：参考文档/SPEC/原作者意图。"

当用户说 "skip tests" / "这个测试不重要"

→ 触发 §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 突然加这选项

引用

handbook §20.3 全文
CLAUDE.md 铁律 #14
.claude/hooks/test-lock-guard.sh（注入提醒层）
.claude/rules/test-lock.md（详细 5 条规则）