create-config-field
Add a new configuration field to the Datadog Agent (datadog.yaml)
71
66%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./.claude/skills/create-config-field/SKILL.mdQuality
Discovery
40%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 clear, narrow task (adding a config field to datadog.yaml) which gives it strong distinctiveness, but it lacks a 'Use when...' clause and provides only a single action without elaboration. It would benefit significantly from explicit trigger guidance and additional detail about what the process involves.
Suggestions
Add a 'Use when...' clause with trigger terms like 'when the user needs to add a new setting to the Datadog Agent config', 'datadog.yaml field', 'agent configuration option'.
Expand the capability description with more concrete actions, e.g., 'Adds a new configuration field to datadog.yaml, including defining the field schema, setting defaults, adding documentation comments, and wiring it into the agent's config parsing logic'.
Include common keyword variations users might use such as 'config option', 'agent setting', 'YAML parameter', 'Datadog config' to improve trigger term coverage.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names a specific domain (Datadog Agent configuration) and one action (add a configuration field), but does not list multiple concrete actions or elaborate on what adding a field entails. | 2 / 3 |
Completeness | Describes what the skill does (add a configuration field) but completely lacks any 'Use when...' clause or explicit trigger guidance for when Claude should select this skill. Per rubric guidelines, a missing 'Use when' clause caps completeness at 2, and since the 'what' is also thin, this scores a 1. | 1 / 3 |
Trigger Term Quality | Includes relevant keywords like 'Datadog Agent', 'datadog.yaml', and 'configuration field', but misses common variations users might say such as 'config option', 'agent setting', 'YAML config', or 'new parameter'. | 2 / 3 |
Distinctiveness Conflict Risk | The description targets a very specific niche — adding configuration fields to the Datadog Agent's datadog.yaml — which is unlikely to conflict with other skills due to the narrow, product-specific scope. | 3 / 3 |
Total | 8 / 12 Passed |
Implementation
92%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a high-quality skill that provides precise, project-specific guidance for adding configuration fields to the Datadog Agent. Its greatest strengths are the comprehensive subsystem mapping tables, concrete code examples, and clear verification steps. The only minor weakness is that the reference tables could potentially be split into a separate file for better progressive disclosure, though the current organization is still quite readable.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The content is lean and efficient. Every table, code snippet, and note earns its place. It doesn't explain what Go is, what YAML is, or how config files work—it assumes Claude's competence and focuses entirely on project-specific knowledge Claude wouldn't have. | 3 / 3 |
Actionability | Provides concrete, executable Go code for registering config keys, specific build/lint commands, exact file paths, and method signatures with real examples. The step-by-step process includes specific commands like `dda inv agent.build --build-exclude=systemd` and patterns like `BindEnvAndSetDefault("my_feature.timeout", 30, "DD_MY_TIMEOUT")`. | 3 / 3 |
Workflow Clarity | The 4-step workflow is clearly sequenced: gather info → register key → optionally document → verify. Step 4 includes explicit build, lint, and config generation validation steps. The information-gathering step has a clear checklist of 8 items, and the skill includes decision points (e.g., serverless-compatible fields, dedicated setup file vs inline). | 3 / 3 |
Progressive Disclosure | The content is well-structured with tables and clear sections, but it's all inline in a single file. The tables for subsystems are useful reference material that could be split into a separate reference file. However, given no bundle files exist, the skill does a reasonable job organizing content with headers and tables, though it's on the longer side for a single file. | 2 / 3 |
Total | 11 / 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
0f36ad4
- 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.