jbvc/regex-vs-llm-structured-text
Decision framework for choosing between regex and LLM when parsing structured text — start with regex, add LLM only for low-confidence edge cases.
74
74%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Quality
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 communicates a clear and distinctive concept — a decision framework for regex vs LLM parsing — but lacks explicit trigger guidance ('Use when...') and could benefit from more concrete action verbs and natural keyword variations. Its strength is its distinctiveness; its weakness is incomplete trigger coverage and moderate specificity.
Suggestions
Add an explicit 'Use when...' clause, e.g., 'Use when the user needs to parse structured text, extract fields from logs or documents, or decide between regex and LLM-based parsing approaches.'
Include more natural trigger terms and variations users might say, such as 'text extraction', 'pattern matching', 'log parsing', 'data extraction', 'scraping structured data'.
List more concrete actions the skill enables, e.g., 'Evaluates parsing confidence, routes low-confidence cases to LLM fallback, validates extracted fields.'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (parsing structured text) and describes the core approach (regex vs LLM decision framework), but doesn't list multiple concrete actions — it's more of a strategy description than a list of specific capabilities like 'parse log files, extract fields, handle malformed entries'. | 2 / 3 |
Completeness | The 'what' is addressed (decision framework for regex vs LLM parsing), but there is no explicit 'Use when...' clause or equivalent trigger guidance. The when is only implied by the description itself, which per the rubric caps completeness at 2. | 2 / 3 |
Trigger Term Quality | Includes relevant terms like 'regex', 'LLM', 'parsing', 'structured text', and 'edge cases', which are reasonably natural for developers. However, it misses common variations users might say like 'text extraction', 'pattern matching', 'data parsing', 'scraping', or specific formats. | 2 / 3 |
Distinctiveness Conflict Risk | The specific niche of choosing between regex and LLM for structured text parsing is quite distinctive. It's unlikely to conflict with other skills since the combination of 'decision framework', 'regex vs LLM', and 'low-confidence edge cases' creates a clear, unique identity. | 3 / 3 |
Total | 9 / 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 decision framework and executable code examples that demonstrate the full regex-to-LLM hybrid pipeline. Its main weakness is moderate verbosity — the 'When to Activate', 'When to Use', and 'Anti-Patterns' sections overlap with other content and could be consolidated. The architecture diagram and confidence-based validation checkpoint make the workflow exceptionally clear.
Suggestions
Merge 'When to Activate' and 'When to Use' into a single brief section, and fold 'Anti-Patterns' into 'Best Practices' as negative bullet points to reduce redundancy.
Consider extracting the full code implementations into a referenced file (e.g., IMPLEMENTATION.md) and keeping only the architecture diagram and key snippets in the main skill.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is mostly efficient with good code examples, but includes some unnecessary sections like 'When to Activate' and 'When to Use' which overlap significantly, and the anti-patterns section partially restates the best practices in negated form. The real-world metrics table adds value but the overall content could be tightened by ~20%. | 2 / 3 |
Actionability | Provides fully executable Python code for each pipeline stage — regex parser, confidence scorer, LLM validator, and hybrid pipeline orchestrator. The code uses concrete dataclasses, real regex patterns, and a working API call pattern. Copy-paste ready with minimal adaptation needed. | 3 / 3 |
Workflow Clarity | The pipeline is clearly sequenced with an explicit decision tree, ASCII architecture diagram, and numbered implementation steps (1→2→3→4). The confidence threshold acts as a validation checkpoint, and the pipeline gracefully handles the case where no LLM client is available. The feedback loop from low-confidence scoring to LLM validation is explicit. | 3 / 3 |
Progressive Disclosure | The content is well-structured with clear headers and a logical progression from decision framework to implementation to best practices. However, it's a fairly long monolithic file (~180 lines of content) with no references to external files for the detailed code examples or API reference, which could benefit from being split out for a skill of this complexity. | 2 / 3 |
Total | 10 / 12 Passed |
Validation
100%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 11 / 11 Passed
Validation for skill structure
No warnings or errors.
Reviewed
Table of Contents