菜单
Triage unexpected TiDB test diffs that seem unrelated to the current PR. Use when plan/result/testdata changes appear after merge/rebase or only in specific local runs, especially to quickly rule in/out failpoint enablement issues.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Decide where to place TiDB tests and how to write them (basic structure, naming, testdata usage). Use when asked about test locations, writing conventions, shard_count limits, casetest categorization, or when reviewing test changes in code review.
Use when implementing a user- or reviewer-prescribed code change (including review comments with suggested fixes or options), especially when the requested edit may be risky, incomplete, ambiguous, or misaligned with TiDB correctness and compatibility constraints.
Use when deciding whether make bazel_prepare is required before build or test commands based on local file changes in TiDB.
Use when creating or editing TiDB GitHub issues so issue templates, labels, issue titles, and issue descriptions stay consistent with repository workflow. Trigger on tasks involving issue creation, bug reports, enhancement tracking issues, label selection, or searching for existing issues and PRs before filing a new one.
Use when creating or editing TiDB pull requests so PR title scope, PR template fields, hidden HTML comments, and bot-parsed checklist sections stay intact. Trigger on tasks involving PR creation, PR body updates, issue linking from a PR, test checklist updates, or investigating labels like do-not-merge/needs-tests-checked.
Use when running TiDB package tests and deciding whether failpoint enable/disable is required before and after the test command.
| name | tidb-test-diff-triage |
| description | Triage unexpected TiDB test diffs that seem unrelated to the current PR. Use when plan/result/testdata changes appear after merge/rebase or only in specific local runs, especially to quickly rule in/out failpoint enablement issues. |
Use this workflow when:
In TiDB, many test behaviors rely on failpoint instrumentation. -tags=intest,deadlock does not enable failpoints.
docs/agents/testing-flow.md -> Failpoint decision for unit tests against the affected package.Failpoint-enabled run and add -count=1 to the go test command for reproducibility.If failpoint is not the cause:
-run <TestName> -count=1).Useful commands:
git bisect start
git bisect bad <bad_commit>
git bisect good <good_commit>
Only sync expected plan/result when one of these is true:
Do not record/update testdata before root cause is identified.
Symptom: what diff changed.Scope: single test vs full suite.Failpoint check: commands and result.First bad commit: hash and title (if bisected).Conclusion: setup issue / upstream behavior change / local regression.Action: rerun with failpoint, sync expected, or continue fixing code.