tidb-failpoint-test-runner

Use when running TiDB package tests and deciding whether failpoint enable/disable is required before and after the test command.

0.96x

Quality

67%

Does it follow best practices?

Impact

96%

0.96x

Average score across 3 eval scenarios

Securityby

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./.agents/skills/tidb-failpoint-test-runner/SKILL.md

Quality

Content

68%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

The content is exemplary in brevity and well-structured, deferring detail cleanly to an external doc. It loses points because the executable commands are not present inline and the workflow lacks a validation/verification checkpoint for the test run.

Suggestions

Inline the actual failpoint enable/disable and run commands (or at least the canonical command templates) so the skill is executable without opening the external doc.

Add a validation step after the run (e.g., 'Confirm tests pass; on failure, re-check failpoint state and re-run') to satisfy the batch-operation feedback-loop expectation.

Confirm `docs/agents/testing-flow.md` exists at the referenced path and consider linking it as a bundle reference so the one-level-deep navigation is verifiable.

Dimension	Reasoning	Score
Conciseness	The body is lean and assumes Claude's competence: no concept explanations, no padding, and every line (the `-tags=intest,deadlock` note, the decision branches, the `-run <TestName>` tip) earns its place, matching the lean-and-efficient 5 anchor.	5 / 5
Actionability	It gives concrete decision branches and flags (`-run <TestName>`, `-tags=intest,deadlock` does not enable failpoints), but the actual executable failpoint enable/disable and run commands are deferred entirely to `docs/agents/testing-flow.md` rather than being inline, leaving key execution details incomplete as in the 3 anchor.	3 / 5
Workflow Clarity	There is a clear 4-step sequence, but a test run is a batch operation with no validation checkpoint (no 'verify tests passed' or failure/retry step) and step 4 only records evidence rather than confirming outcomes, so the missing-feedback cap at 3 applies.	3 / 5
Progressive Disclosure	Overview and Workflow sections are well organized and the detailed commands are deferred one level deep to a clearly signaled external doc with specific section anchors, but even the core commands live in that external file rather than just advanced content, a minor organization gap that keeps it below 5.	4 / 5
	Total	15 / 20 Passed

Description

66%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

The description is concise, third person, and clearly scoped to the TiDB failpoint-testing niche with an explicit 'Use when' trigger. Its main weaknesses are limited action coverage and reliance on domain jargon without synonyms.

Suggestions

Add one or two more concrete actions (e.g., 'selecting the failpoint-enabled or standard run command set') to lift specificity above 3.

Include natural synonyms or phrasings a user might say (e.g., 'unit tests', 'pkg/... tests', 'failpoint injection') to broaden trigger-term coverage.

Dimension	Reasoning	Score
Specificity	Names the domain ('running TiDB package tests') and two concrete actions ('deciding whether failpoint enable/disable is required before and after the test command'), but coverage is narrow rather than comprehensive, matching the 1-2 concrete actions anchor rather than the several-actions anchor at 4.	3 / 5
Completeness	It explicitly answers both 'what' (run TiDB package tests, decide failpoint enable/disable before/after) and 'when' ('Use when running TiDB package tests...'), but the 'what' is somewhat narrow and could be more explicit about scope, keeping it just below the fully-concrete 5.	4 / 5
Trigger Term Quality	Relevant keywords like 'TiDB package tests', 'failpoint enable/disable', and 'test command' are present and a TiDB developer would say them, but synonyms or common variations are missing and the phrasing leans on technical jargon, so it is not the comprehensive coverage of a 4 or 5.	3 / 5
Distinctiveness Conflict Risk	The trigger is a clear niche ('TiDB package tests' with 'failpoint enable/disable') that is highly unlikely to fire for any unrelated skill, so conflict risk is minimal and the distinct-trigger anchor at 5 is the best fit.	5 / 5
	Total	15 / 20 Passed

Validation

100%

Warnings & errors only

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository: pingcap/tidb
Path: .agents/skills/tidb-failpoint-test-runner/SKILL.md
Commit: d8d57d7

Reviewed: 1 day ago

Table of Contents

Discovery Implementation Validation

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.