with one click
tidb-verify-profile
Use when choosing local validation scope in TiDB work, especially to separate fast coding-loop checks from completion checks and avoid unnecessary slow commands.
Menu
Use when choosing local validation scope in TiDB work, especially to separate fast coding-loop checks from completion checks and avoid unnecessary slow commands.
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-verify-profile |
| description | Use when choosing local validation scope in TiDB work, especially to separate fast coding-loop checks from completion checks and avoid unnecessary slow commands. |
Use this skill to decide how much local validation to run before and after code changes.
Policy requirements still come from AGENTS.md; this skill is the execution guide.
WIP (coding loop)Use while still iterating and not claiming the task is complete.
go test -run <TestName> -tags=intest,deadlock).make lint, package-wide runs, realtikvtest).Ready (completion gate)Use when claiming task completion or PR readiness.
Mandatory trigger phrases are defined in AGENTS.md -> Quick Decision Matrix.
AGENTS.md -> Task -> Validation Matrix.make lint.AGENTS.md -> Agent Output Contract for final reporting.Heavy (explicitly required)Use only when scope or user request requires expensive checks.
make bazel_lint_changed unless the user explicitly requests it.