Use when running tests under tests/realtikvtest that require a local TiUP playground lifecycle with strict startup, readiness checks, and cleanup.
80
70%
Does it follow best practices?
Impact
100%
1.09xAverage score across 3 eval scenarios
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./.agents/skills/tidb-realtikv-runner/SKILL.mdQuality
Discovery
89%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This is a well-targeted description with strong 'when' guidance and distinctive trigger terms that clearly define its niche. Its main weakness is that the 'what' portion could be more specific about the concrete actions performed (e.g., starting specific services, checking specific ports, running specific cleanup commands). Overall it serves its purpose well for skill selection in a multi-skill environment.
Suggestions
Add more specific concrete actions to the description, e.g., 'Starts TiKV/PD/TiDB services via TiUP, verifies port readiness, executes test suites, and tears down the playground cluster.'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description names the domain (running tests under a specific path with TiUP playground) and mentions some actions (startup, readiness checks, cleanup), but doesn't list concrete specific actions like 'start TiUP cluster', 'verify port availability', 'tear down instances'. The actions are somewhat abstract. | 2 / 3 |
Completeness | The description explicitly answers both 'what' (managing a local TiUP playground lifecycle with startup, readiness checks, and cleanup) and 'when' (when running tests under tests/realtikvtest that require this lifecycle), with a clear 'Use when' clause at the start. | 3 / 3 |
Trigger Term Quality | Includes highly specific natural trigger terms a developer would use: 'tests/realtikvtest', 'TiUP playground', 'startup', 'readiness checks', 'cleanup'. These are precise terms that match what a user working in this domain would naturally reference. | 3 / 3 |
Distinctiveness Conflict Risk | Highly distinctive with very specific triggers: 'tests/realtikvtest', 'TiUP playground', and the specific lifecycle pattern. This is unlikely to conflict with other skills due to the narrow, well-defined scope. | 3 / 3 |
Total | 11 / 12 Passed |
Implementation
50%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
The skill is admirably concise and well-structured as a checklist, but it critically lacks actionability: there are zero executable commands, code snippets, or concrete examples. It functions more as a table of contents pointing to an external document than as a self-contained skill. The workflow is logically sequenced but would benefit greatly from inline command examples for at least the core happy path.
Suggestions
Inline the core commands (tiup playground start, readiness check loop, go test invocation, cleanup/kill) so the skill is actionable without consulting the external file.
Add a concrete example showing the full happy-path sequence (start → poll PD → run one test → kill → verify) with copy-paste-ready shell commands.
Include the cleanup-safe template inline or as a code block, since it is referenced as a key workflow option but not shown.
Add an explicit error-recovery feedback loop (e.g., what to do if PD readiness check times out) to strengthen the workflow's validation checkpoints.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The content is lean and efficient. Every line serves a purpose—no explanation of what TiDB is, what a playground is, or other concepts Claude would already know. The checklist is tight and directive. | 3 / 3 |
Actionability | The skill provides no executable commands, no code snippets, and no concrete examples. It delegates all actual instructions to `docs/agents/testing-flow.md` without showing any of the commands inline. A reader cannot act on this skill alone. | 1 / 3 |
Workflow Clarity | Steps are listed in a logical sequence (start, configure, test, teardown, verify), and step 5 includes a verification checkpoint. However, the actual commands are absent—deferred entirely to an external file—so the workflow is more of an outline than an actionable sequence with concrete validation steps. | 2 / 3 |
Progressive Disclosure | The skill references `docs/agents/testing-flow.md` for details, which is one level deep and clearly signaled. However, no bundle files are provided, so we cannot verify the reference exists, and the skill itself contains almost no standalone content—it's essentially just a pointer, which over-delegates rather than providing a useful overview. | 2 / 3 |
Total | 8 / 12 Passed |
Validation
100%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 11 / 11 Passed
Validation for skill structure
No warnings or errors.
e70762e
Table of Contents
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.