create-component
Create a new Fx component using the modern def/fx/impl pattern (NOT legacy)
65
58%
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-component/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 niche (Fx component creation with a specific modern pattern) and distinguishes itself from legacy approaches, which is a strength. However, it lacks an explicit 'Use when...' clause, provides only a single action, and misses natural trigger terms users might employ when requesting this skill.
Suggestions
Add an explicit 'Use when...' clause, e.g., 'Use when the user asks to create a new Fx component, add a dependency injection module, or scaffold a def/fx/impl structure.'
Include more natural trigger terms users might say, such as 'uber fx', 'Go fx module', 'dependency injection', 'fx provider', or 'new fx service'.
Expand the 'what' portion to list additional concrete actions beyond just 'Create', such as 'scaffolds the def interface, fx provider function, and impl struct' to give Claude more context for selection.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names a specific domain (Fx component creation) and mentions a concrete pattern ('def/fx/impl pattern'), but only describes one action ('Create') without listing additional capabilities or details about what the component involves. | 2 / 3 |
Completeness | Describes what it does (create an Fx component using the modern pattern) but has no explicit 'Use when...' clause or equivalent trigger guidance, which per the rubric should cap completeness at 2, and the 'what' is also fairly thin, bringing it to 1. | 1 / 3 |
Trigger Term Quality | Includes some relevant terms like 'Fx component', 'def/fx/impl pattern', and 'legacy', but misses common user variations such as 'fx module', 'dependency injection', 'uber fx', 'Go fx', or framework-specific terminology users might naturally use. | 2 / 3 |
Distinctiveness Conflict Risk | The description is quite specific to a particular framework pattern ('def/fx/impl') and explicitly distinguishes itself from legacy approaches, making it unlikely to conflict with other skills. | 3 / 3 |
Total | 8 / 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, actionable skill with a clear multi-step workflow and explicit validation. It provides specific file patterns, function signatures, and CLI commands that make it highly executable. Minor weaknesses include some verbosity in the user-interaction step and lack of bundle files for progressive disclosure, though the inline content is well-organized.
Suggestions
Consider extracting the detailed file content patterns (what goes in each .go file) into a reference file like PATTERNS.md to improve progressive disclosure and reduce SKILL.md length.
Tighten step 2 by removing it or condensing it to a single line — Claude can infer when to ask clarifying questions without being told each specific question.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is mostly efficient and domain-specific, but step 2 (asking the user) and some explanatory parentheticals add moderate bloat. The repeated emphasis on legacy vs new-style could be tightened since the pattern is already shown. | 2 / 3 |
Actionability | Provides concrete directory structures, specific file names, exact function signatures (e.g., `fxutil.ProvideComponentConstructor`, `func NewComponent(deps Requires) (Provides, error)`), specific CLI commands for validation, and clear usage examples. The guidance is highly specific and actionable. | 3 / 3 |
Workflow Clarity | Clear 9-step sequential workflow from argument parsing through validation, with an explicit validation step (step 9) including specific lint commands and a 'fix and re-run until clean' feedback loop. The sequence covers reading references before writing, creating structure, registering modules, and validating. | 3 / 3 |
Progressive Disclosure | The skill is well-structured with clear sections (Instructions, Critical Rules, Usage), but all content is inline in a single file with no references to supporting documents. The reference examples strategy (step 3: 'read a recent component') is a good pattern but relies on discovery rather than linking to specific reference files. | 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
8ef4f98
- 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.