CtrlK
BlogDocsLog inGet started
Tessl Logo

regulatory-fallback-research

Handle tool failures when researching regulatory/government content by using fallback methods and domain knowledge

49

Quality

53%

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 ./benchmarks/gdpval/skills/regulatory-fallback-research/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

50%

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

The body presents a clear, well-structured fallback workflow with useful domain specifics, but it is a monolithic single file whose 'code examples' are non-executable pseudocode and whose validation checkpoints are implicit. It is solid but uniformly mid-tier across all dimensions.

Suggestions

Replace invented functions (create_pharmacy_checklist) and shell_agent task strings with concrete, runnable invocations or clearly-labeled prompt templates.

Make validation explicit by adding validate-then-proceed gates between steps (e.g., 'Confirm the failure is an unknown error before moving to Step 2') and a validate->fix->retry loop where applicable.

Remove the duplicate trailing frontmatter block and trim the Overview/repeated shell_agent examples to tighten token use; consider moving the domain-knowledge framework lists into a referenced file.

DimensionReasoningScore

Conciseness

The body is mostly efficient with useful domain specifics (HIPAA, OBRA-90, OSHA), but the Overview and repeated shell_agent examples pad it, and a duplicate frontmatter block at the end is pure junk. It is not a 1 (no wall of basic-concept explanation) and not a 3 (some unnecessary content and the trailing artifact).

2 / 3

Actionability

It gives concrete guidance (specific shell_agent task prompts, named compliance frameworks), but the 'code' uses invented non-executable functions like create_pharmacy_checklist(...) and shell_agent task strings rather than runnable code. It is not a 1 (not purely vague) and not a 3 (not copy-paste executable).

2 / 3

Workflow Clarity

A clear 4-step fallback sequence with expected outcomes per step, a failure-scenario table, and a Quality Criteria checklist exist, but validation checkpoints are implicit 'expected outcomes' rather than explicit validate-then-proceed gates, and there is no validate->fix->retry feedback loop. It is not a 1 (steps are sequenced) and not a 3 (no explicit validation gates/feedback loops).

2 / 3

Progressive Disclosure

No bundle files exist and all content is inline in a single ~140-line file that is well-organized into sections, but nothing is split off and there is no navigation to deeper material. It is not a 1 (well-organized, no nested references) and not a 3 (over 50 lines, monolithic, not split across files).

2 / 3

Total

8

/

12

Passed

Description

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 scopes a distinct niche (regulatory/government research with tool-failure fallback) but relies on abstract action language and lacks an explicit 'Use when...' trigger clause. It is competent but could be sharpened with concrete actions and broader natural trigger terms.

Suggestions

Add an explicit 'Use when...' clause, e.g. 'Use when researching regulatory, government, or compliance content (FDA, CMS, state boards) and primary source tools return errors or fail repeatedly.'

Replace abstract verbs with concrete actions, e.g. 'Retry failed sources, delegate secondary research to a shell agent, and compile deliverables from established compliance frameworks.'

Broaden natural trigger terms to include 'compliance', 'government sites', and named agencies users would actually mention.

DimensionReasoningScore

Specificity

The description names the domain ('regulatory/government content') and a few actions ('Handle tool failures', 'using fallback methods and domain knowledge'), but these are abstract rather than a list of multiple concrete actions. It is not a 1 because it is not vague like 'Helps with documents', and not a 3 because it does not enumerate specific concrete actions.

2 / 3

Completeness

It answers 'what' (handle tool failures via fallback methods and domain knowledge) and embeds an implied 'when' ('when researching regulatory/government content'), but lacks an explicit 'Use when...' trigger clause. Per the judging guidelines, a missing explicit 'Use when...' clause caps completeness at 2.

2 / 3

Trigger Term Quality

It includes some natural terms a user might say ('tool failures', 'regulatory/government content'), but coverage is limited and misses common variations like 'compliance', 'FDA', or 'government sites'. It is not a 1 (not pure jargon) and not a 3 (no broad coverage of natural trigger terms).

2 / 3

Distinctiveness Conflict Risk

The combination of regulatory/government research plus tool-failure fallback is a clear, narrow niche unlikely to trigger for unrelated skills. It is not a 2 because it is more specific than 'Works with document files', and the distinct trigger (tool failures during regulatory research) makes conflict unlikely.

3 / 3

Total

9

/

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.

Validation16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository
HKUDS/OpenSpace
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.