CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

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.

Quality

75%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Passed

No findings from the security scan

Fix and improve this skill with Tessl

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

The canonical home for this skill is regex-vs-llm-structured-text in affaan-m/ECC

SKILL.md
Quality
Evals
Security

Quality

Content

71%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.

A well-structured, actionable skill with executable code, a clear decision framework, and real-world metrics, held back by an incomplete LLM validator example and a monolithic single-file layout that inlines implementation code rather than splitting it into scripts. The workflow has an explicit confidence checkpoint but lacks a feedback loop for LLM-corrected output.

Suggestions

Move the four implementation code blocks into a scripts/ file (e.g. scripts/hybrid_parser.py) and reference it, keeping SKILL.md as a decision-framework overview with a minimal inline example.

Complete validate_with_llm so it is executable — parse the LLM response, construct the corrected ParsedItem, and handle the 'CORRECT' case instead of returning an undefined corrected_item.

Add a re-validation step after LLM correction (re-score confidence or verify required fields) to close the feedback loop for this batch operation.

Merge the overlapping "When to Activate" and "When to Use" sections to remove redundancy.

DimensionReasoningScore

Conciseness

The body is dense and lean — no explanations of concepts Claude already knows, minimal comments, and information-bearing sections — but the overlapping "When to Activate" and "When to Use" sections and the repeated 95-98% statistic could be trimmed, matching anchor 4 rather than the fully lean anchor 5.

4 / 5

Actionability

Three of the four code blocks (regex parser, confidence scoring, hybrid pipeline) are complete and executable, but validate_with_llm ends with "# Parse LLM response and return corrected item..." returning an undefined corrected_item, a concrete gap that anchor 4 ("minor gaps") describes.

4 / 5

Workflow Clarity

Steps are clearly sequenced (Regex Parser → Confidence Scoring → LLM Validator → Hybrid Pipeline) with an explicit confidence-threshold checkpoint, so validation is present (no batch-operation cap at 3); however there is no re-validation of LLM-corrected items or error-recovery loop, which anchor 5 requires.

4 / 5

Progressive Disclosure

Sections are well-organized within a single file, but ~130 lines of implementation code are inlined in a 215-line SKILL.md with no references/ or scripts/ split — content that should be separate is inline, matching anchor 3.

3 / 5

Total

15

/

20

Passed

Description

70%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.

A specific, well-scoped description with a clear niche and low conflict risk, weakened by the absence of an explicit 'Use when...' trigger clause and missing common synonyms like 'extract' or concrete format names. Adding trigger guidance would lift the capped completeness dimension.

Suggestions

Append an explicit trigger clause, e.g. "Use when parsing quizzes, forms, invoices, or other repeating-pattern text, or when deciding between regex and LLM for extraction."

Include natural synonyms users would say — "extract", "text extraction", "hybrid pipeline" — and concrete formats (quizzes, forms, invoices) to broaden trigger-term coverage.

DimensionReasoningScore

Specificity

The description names the domain ("parsing structured text", "regex and LLM") and gives concrete strategic actions ("start with regex, add LLM only for low-confidence edge cases"), which is more precise than anchor 3's generic action list but not the comprehensive multi-action coverage of anchor 5.

4 / 5

Completeness

The 'what' is clear ("Decision framework for choosing between regex and LLM... start with regex, add LLM only for low-confidence edge cases"), but there is no 'Use when...' clause or equivalent explicit trigger guidance — 'when parsing structured text' is only weakly implied — so completeness is capped at 3 per the rubric guideline.

3 / 5

Trigger Term Quality

Natural terms like "regex", "LLM", "parsing", and "structured text" match what users would say in this domain, but common variations such as "extract", "text extraction", and concrete formats (quizzes, forms, invoices) are absent, keeping it short of anchor 5.

4 / 5

Distinctiveness Conflict Risk

The regex-vs-LLM hybrid parsing niche is highly specific with distinct trigger terms, making conflict with other skills minimal — a clear match for anchor 5.

5 / 5

Total

16

/

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.

Validation — 15 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

frontmatter_unknown_keys

Unknown frontmatter key(s) found; consider removing or moving to metadata

Warning

Total

15

/

16

Passed

Repository

valeriibeck-star/claude-skills

Path

skills/regex-vs-llm-structured-text/SKILL.md

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.