CtrlK
BlogDocsLog inGet started
Tessl Logo

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.

56

Quality

65%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Low

Low-risk findings worth noting

Fix and improve this skill with Tessl

tessl review fix ./skills/regex-vs-llm-structured-text/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

68%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

The body is actionable and reasonably concise with four executable code sections and clear sectioning, but its batch workflow lacks explicit output validation/verification, capping workflow clarity. Minor redundancy between activation sections and diagrams could be trimmed.

Suggestions

Add an explicit validation/verification step for the final parsed output (e.g., a coverage check that all input blocks were parsed, with a retry/escalate feedback loop for failures) to lift workflow clarity above the batch-operation cap.

Complete the LLM validator implementation (parsing the response into a corrected ParsedItem) rather than leaving a placeholder return.

Merge the redundant 'When to Activate' and 'When to Use' sections, and consider collapsing the Decision Framework and Architecture Pattern diagrams into one to reduce token overlap.

DimensionReasoningScore

Conciseness

The body is largely efficient and assumes Claude's competence (it does not explain what regex or LLMs are), with dense executable code; the main redundancy is the overlapping 'When to Activate' and 'When to Use' lists plus two ASCII diagrams that convey similar pipeline info.

4 / 5

Actionability

It provides four concrete, mostly copy-paste-ready Python sections (regex parser, confidence scoring, LLM validator, hybrid pipeline); the one minor gap is the LLM validator stub ('Parse LLM response and return corrected item...') which is not fully implemented.

4 / 5

Workflow Clarity

The pipeline is clearly sequenced (regex -> confidence -> LLM for edge cases) with an implicit confidence threshold checkpoint, but as a batch parsing operation it lacks an explicit output-validation/verification step or error-recovery feedback loop, so per the batch-operation cap it cannot exceed 3.

3 / 5

Progressive Disclosure

Content is well-organized into clear, well-signaled sections with no nested references and appropriate inline code for a code skill; the only minor organization gap is the redundant 'When to Activate'/'When to Use' section pair.

4 / 5

Total

15

/

20

Passed

Description

61%Weight 40%Scale 1-5

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 is specific and uses natural trigger terms, but it lacks an explicit 'Use when...' activation clause, which caps its completeness. It carves a recognizable niche with low conflict risk.

Suggestions

Add an explicit 'Use when...' clause (e.g., 'Use when parsing structured text with repeating patterns and deciding between regex and LLM extraction').

Include a few more concrete action phrases (e.g., 'score confidence', 'validate edge cases') to broaden capability coverage.

Add common synonyms or file-type triggers (e.g., quizzes, forms, invoices) to strengthen keyword coverage.

DimensionReasoningScore

Specificity

The description names the domain ('parsing structured text') and two concrete actions ('start with regex, add LLM only for low-confidence edge cases'), but coverage is not comprehensive, matching the 1-2-concrete-actions anchor.

3 / 5

Completeness

The 'what' is clear ('Decision framework for choosing between regex and LLM when parsing structured text'), but there is no explicit 'Use when...' trigger clause, so per the boundary guidance completeness is capped at 3.

3 / 5

Trigger Term Quality

It uses natural user-facing terms ('regex', 'LLM', 'parsing structured text', 'edge cases') that a user would plausibly say, with only a few synonyms/variations missing.

4 / 5

Distinctiveness Conflict Risk

The regex-vs-LLM hybrid parsing niche is fairly distinct with specific triggers, with only minor overlap risk against generic text-parsing skills.

4 / 5

Total

14

/

20

Passed

Validation

93%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation15 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

metadata_version

'metadata.version' is missing

Warning

Total

15

/

16

Passed

Repository
affaan-m/ECC
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.