create-component
Create a new Fx component using the modern def/fx/impl pattern (NOT legacy)
52
60%
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-component/SKILL.mdQuality
Discovery
57%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 clearly identifies a specific framework pattern and distinguishes modern from legacy approaches, which is a strength for distinctiveness. However, it lacks an explicit 'Use when...' clause and could benefit from additional trigger terms and more detailed capability listing beyond just 'Create'.
Suggestions
Add an explicit 'Use when...' clause, e.g., 'Use when the user asks to create a new Fx component, add an Fx module, or scaffold a service with dependency injection.'
Include common user-facing trigger terms and variations such as 'uber fx', 'go fx', 'dependency injection', 'fx module', 'fx provider', or 'fx service'.
List additional concrete actions if applicable, e.g., 'Create a new Fx component, scaffold providers and invokers, wire dependencies using the modern def/fx/impl pattern.'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names a specific domain (Fx component creation) and a specific pattern (def/fx/impl), but only describes one action ('Create') rather than listing multiple concrete capabilities. | 2 / 3 |
Completeness | Answers 'what' (create an Fx component using the modern pattern) but lacks an explicit 'Use when...' clause. The when is only implied by the action description, which caps this at 2 per the rubric guidelines. | 2 / 3 |
Trigger Term Quality | Includes relevant terms like 'Fx component', 'def/fx/impl pattern', and 'legacy', which are useful triggers. However, it lacks common user variations—users might say 'new fx module', 'fx dependency injection', 'uber fx', or 'go fx' which are absent. | 2 / 3 |
Distinctiveness Conflict Risk | The description is quite specific to a particular framework pattern (Fx with def/fx/impl) and explicitly distinguishes itself from legacy approaches, making it unlikely to conflict with other skills. | 3 / 3 |
Total | 9 / 12 Passed |
Implementation
62%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill provides a well-sequenced workflow for creating Fx components with clear validation steps and good structural guidance. Its main weaknesses are the lack of concrete, copy-paste-ready code templates for the generated files (relying instead on runtime discovery of reference examples) and some minor verbosity in repeated guidance. Adding inline code templates would significantly improve actionability.
Suggestions
Add concrete, executable code templates for each generated file (def/component.go, fx/fx.go, impl/<component>.go) with placeholder variables, rather than relying on Claude to discover reference examples at runtime.
Extract the code templates into a separate TEMPLATES.md bundle file and reference it from the main skill to improve progressive disclosure and reduce inline bulk.
Consolidate the 'Critical Rules' section with the inline rules in step 5 to avoid repetition and improve conciseness.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is mostly efficient and avoids explaining basic Go or Fx concepts, but some sections are slightly verbose—e.g., step 2 (asking the user) could be more compact, and the critical rules section partially repeats what's already stated in the instructions. | 2 / 3 |
Actionability | The skill provides a clear directory structure, specific file naming conventions, and concrete CLI commands for validation, but lacks actual executable code templates for the key files (def/component.go, fx/fx.go, impl/<component>.go). It tells Claude to 'read reference examples' rather than providing copy-paste-ready templates, making it dependent on runtime discovery. | 2 / 3 |
Workflow Clarity | The 9-step workflow is clearly sequenced from argument parsing through creation, registration, wiring, and validation. Step 9 includes an explicit validation command with a 'fix and re-run until clean' feedback loop, which is appropriate for a code generation task. | 3 / 3 |
Progressive Disclosure | The content is reasonably well-structured with clear sections, but everything is inline in a single file. The reference to reading existing components (step 3) is a form of progressive disclosure, but there are no bundle files or linked references to templates, examples, or detailed API docs that could offload the inline content. | 2 / 3 |
Total | 9 / 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
26d14c5
- 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.