create-core-check
Create a new Go core check that collects metrics and sends them to Datadog
49
55%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./.claude/skills/create-core-check/SKILL.mdQuality
Discovery
32%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 identifies a specific domain (Datadog Go core checks) but is too terse—it lacks a 'Use when...' clause, doesn't enumerate concrete sub-actions, and misses common trigger term variations. It reads more like a task summary than a skill description designed for disambiguation among many skills.
Suggestions
Add an explicit 'Use when...' clause with trigger terms like 'Datadog Agent check', 'custom integration', 'agent metric collection', 'golang check'.
List more specific concrete actions such as 'scaffold check directory structure, implement the Check() method, write unit tests, configure check YAML'.
Include common keyword variations users might use: 'Datadog Agent', 'custom check', 'integration', 'golang', '.go check file'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (Go core check, Datadog) and a couple of actions (collects metrics, sends them), but doesn't list multiple specific concrete actions like scaffolding files, writing tests, configuring YAML, etc. | 2 / 3 |
Completeness | It describes what the skill does but has no explicit 'Use when...' clause or equivalent trigger guidance, and per the rubric a missing 'Use when' clause caps completeness at 2—but the 'what' is also fairly thin, so this lands at 1. | 1 / 3 |
Trigger Term Quality | Includes relevant keywords like 'Go', 'core check', 'metrics', and 'Datadog' that users might say, but misses common variations such as 'agent check', 'custom check', 'Datadog Agent', 'golang', or 'integration'. | 2 / 3 |
Distinctiveness Conflict Risk | The mention of 'Go core check' and 'Datadog' provides some specificity, but it could overlap with other Datadog-related skills or general Go development skills without clearer scoping. | 2 / 3 |
Total | 7 / 12 Passed |
Implementation
77%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a strong, well-structured skill that provides clear, actionable guidance for creating Datadog core checks. Its greatest strength is the systematic workflow with explicit reference file mapping and verification steps. The main weakness is moderate verbosity—the Sender Methods Reference table and Important Notes section could be extracted to bundle files or trimmed, as much of this information is discoverable from the reference files the skill already directs Claude to read.
Suggestions
Extract the Sender Methods Reference table and Important Notes into a separate bundle file (e.g., REFERENCE.md) and link to it from the main skill to reduce token footprint.
Remove or condense the introductory sentence ('Core checks collect metrics, service checks, or events...') since Claude can infer this from context.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is mostly efficient and well-structured, but includes some information Claude already knows (e.g., explaining what core checks are, the Sender Methods Reference table which could be discovered from code, and the 'Important Notes' section partially restates what's already in the step-by-step instructions). The reference table and notes section add ~40 lines that could be trimmed or moved to a bundle file. | 2 / 3 |
Actionability | The skill provides highly concrete guidance: specific file paths to read as references, exact directory structures, specific commands for testing/building/linting, a clear table mapping check types to reference files, and concrete test flow steps with mock sender patterns. The approach of reading existing codebase patterns rather than providing inline code is appropriate given the variability of check types. | 3 / 3 |
Workflow Clarity | The 7-step workflow is clearly sequenced with logical dependencies (gather info → read references → create check → register → config → test → verify). Step 7 includes explicit verification with three distinct validation commands (test, build, lint). The multi-step process has clear checkpoints and the ordering constraints (e.g., BuildID before CommonConfigure) are explicitly called out. | 3 / 3 |
Progressive Disclosure | The skill is well-organized with clear sections and a reference table pointing to codebase files, but it's a monolithic document (~150 lines) that inlines the Sender Methods Reference and Important Notes sections which could be split into separate bundle files. The reference table for check types is excellent progressive disclosure into the codebase, but the skill itself has no bundle files to offload secondary content. | 2 / 3 |
Total | 10 / 12 Passed |
Validation
81%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 9 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
allowed_tools_field | 'allowed-tools' contains unusual tool name(s) | Warning |
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 9 / 11 Passed | |
- Repository
- DataDog/datadog-agent
- Commit
a41685a
- Reviewed
Table of Contents
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.