enrichment-module-builder
Build a new Nemesis file enrichment module end-to-end with explicit user approval gates for output mode, library choice, sample files, and integration testing.
73
60%
Does it follow best practices?
Impact
99%
1.41xAverage score across 3 eval scenarios
Risky
Do not use without reviewing
Optimize this skill with Tessl
npx tessl skill review --optimize ./.agents/skills/enrichment-module-builder/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 identifies a clear, niche domain (Nemesis file enrichment modules) which makes it distinctive, but it lacks an explicit 'Use when...' clause and could be more specific about the concrete actions performed. The process-oriented language (approval gates) describes workflow rather than capabilities, and natural trigger terms are limited to project-specific jargon.
Suggestions
Add an explicit 'Use when...' clause, e.g., 'Use when the user wants to add a new file type parser or enrichment module to the Nemesis platform.'
List more concrete actions such as 'scaffolds module boilerplate, implements file parsing logic, writes unit tests, and integrates with the Nemesis enrichment pipeline'.
Include natural trigger terms users might say, such as 'new file type', 'enrichment plugin', 'file parser', 'add support for [format]'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain ('Nemesis file enrichment module') and describes the general process ('end-to-end with explicit user approval gates'), but doesn't list specific concrete actions like scaffolding code, writing parsers, configuring pipelines, etc. The approval gates are listed but are more process steps than concrete capabilities. | 2 / 3 |
Completeness | The 'what' is partially addressed (build a Nemesis file enrichment module with approval gates), but there is no explicit 'Use when...' clause or equivalent trigger guidance. The when is only implied by the description itself, which caps this at 2 per the rubric guidelines. | 2 / 3 |
Trigger Term Quality | Includes some relevant terms like 'Nemesis', 'file enrichment module', 'integration testing', but 'Nemesis' is a niche term that users would need to know. Missing common variations or natural phrases a user might say like 'add a new file type', 'enrichment plugin', or 'file parser'. | 2 / 3 |
Distinctiveness Conflict Risk | The description is highly specific to 'Nemesis file enrichment module' which is a very distinct niche. It's unlikely to conflict with other skills due to the specificity of the project name and the particular workflow described (approval gates for output mode, library choice, sample files, integration testing). | 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 excels at actionability and workflow clarity, providing executable code, specific commands, and a well-structured multi-step process with explicit validation gates and error recovery. However, it is severely verbose — the extensive presentation templates, repeated gate instructions, and inline content that could be referenced externally inflate the token cost significantly. The content would benefit greatly from aggressive trimming of template text and splitting detailed sections into referenced files.
Suggestions
Reduce presentation templates in Steps 2-4 and 8 to brief format notes (e.g., 'Present recommendation with: mode name, rationale, alternatives, and ask for approval') rather than full multi-line markdown templates that Claude can generate naturally.
Remove the triple repetition of gate instructions — the critical note at the top is sufficient; remove the 'STOP' blocks and inline gate reminders from each step.
Extract the full analyzer.py template (Step 6) and test template (Step 7) into separate referenced files (e.g., ANALYZER_TEMPLATE.py, TEST_TEMPLATE.py) to reduce SKILL.md size.
Cut explanatory text that Claude already knows, such as what findings categories mean, what YARA rules are, and general descriptions of output modes — focus on project-specific conventions only.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is extremely verbose at ~450 lines. It includes extensive template text that Claude would need to present to users, redundant formatting instructions, and explanations of concepts Claude already understands (e.g., what findings are, what YARA rules do). The presentation templates alone consume enormous token budget and could be reduced to brief format notes. Much content is repeated across steps (e.g., the 'STOP' gates are explained in the overview, in each step, and in the critical note at the top). | 1 / 3 |
Actionability | The skill provides fully executable code templates, specific bash commands with correct flags, concrete database queries with exact container names and credentials, and copy-paste ready test structures. The module template in Step 6 is a complete, runnable Python class, and the integration testing commands are specific and executable. | 3 / 3 |
Workflow Clarity | The 8-step workflow is clearly sequenced with explicit user approval gates at steps 2, 3, 4, and 8. Each gate has clear stop conditions. Step 8 includes a detailed verification checklist with pass/fail criteria, error recovery guidance in the troubleshooting section, and explicit ordering ('execute these steps IN ORDER'). The completion checklist ensures nothing is skipped. | 3 / 3 |
Progressive Disclosure | The skill references external files (DEVELOPMENT_GUIDE.md, test harness directory, 8 reference modules) which is good, but the SKILL.md itself is monolithic — all 8 steps with full templates, code blocks, and presentation formats are inline. The presentation templates, troubleshooting section, and detailed test code could be split into separate referenced files. No bundle files are provided to offload content to. | 2 / 3 |
Total | 9 / 12 Passed |
Validation
90%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 10 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
skill_md_line_count | SKILL.md is long (654 lines); consider splitting into references/ and linking | Warning |
Total | 10 / 11 Passed | |
- Repository
- SpecterOps/Nemesis
- Commit
432d081
- 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.