CtrlK
BlogDocsLog inGet started
Tessl Logo

802-regulations-dora

Use when reviewing, designing, or modifying Java enterprise systems that may support financial entities, critical ICT services, third-party ICT provider integrations, or operational resilience obligations under DORA. This should trigger for requests such as Review a Java platform for DORA ICT risk controls; Design operational resilience evidence for a financial service; Add incident, continuity, backup, recovery, or third-party ICT controls; Assess resilience testing and monitoring before production release. Part of Plinth Toolkit

65

Quality

82%

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

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, appropriately split instruction skill: the body is a genuine overview, all four bundle files exist and are clearly signaled one level deep, and the workflow is sequenced with explicit proceed/not-proceed gates and secret-redaction rules. The main cost is redundancy — a duplicated legal-advice disclaimer, a 'When to use' section that restates the frontmatter description, and reference links repeated at the top and bottom of the file.

Suggestions

Remove the duplicated disclaimer ("This Skill is not legal advice... does not represent legal advice, a legal opinion, or a final regulatory determination" appears in two intro paragraphs) and keep one statement, pointing to the NOT LEGAL ADVICE constraint for the rest.

Delete or shrink the 'When to use this skill' section, which restates the frontmatter description's trigger list verbatim, and drop the closing 'Reference' section that repeats the four bundle links already given in the intro and workflow steps.

Add a feedback loop to the workflow for when questionnaire answers conflict with reviewed evidence (e.g., re-answer the affected item, re-check the scope classification, then regenerate the affected report sections) to lift workflow clarity to the top anchor.

DimensionReasoningScore

Conciseness

The body is mostly on-message with dense, useful constraint lists, but it contains several padded/duplicated sections: the disclaimer "This Skill is not legal advice" / "does not represent legal advice, a legal opinion..." appears twice (intro paragraphs), the "When to use this skill" section repeats the frontmatter description's trigger list nearly verbatim, and the reference links are listed twice (top of the body and again in the closing "Reference" section). This fits the 3 anchor (mostly efficient but could be tightened) rather than the 2 anchor, since no space is spent explaining concepts Claude already knows.

3 / 5

Actionability

For an instruction-only skill, the guidance is concrete: exact file paths to read in order ("Read references/802-regulations-dora-chapters-summary.md, ... in that order"), a defined questionnaire artifact with a 20-question gate, explicit evidence/Unknown marking rules, a redaction token ([REDACTED_SECRET]), and a report template for the output. It stops short of the 5 anchor because 'Recommend engineering controls' and 'Review implementation' remain checklists of concerns rather than copy-paste-ready procedures or illustrative snippets.

4 / 5

Workflow Clarity

The 6-step workflow is clearly sequenced with explicit gates: "Do not start implementation review until the chapters summary, examples reference, questionnaire rules, and report template are understood" and "Do not proceed to implementation review or the report until all 20 questions have an evidence-backed answer or an Unknown marker". It misses the 5 anchor because there is no validate→fix→retry feedback loop (e.g., what to do when evidence contradicts questionnaire answers or when the report fails its own completeness rules), only forward gates.

4 / 5

Progressive Disclosure

Scored against the actual bundle: references/802-regulations-dora-chapters-summary.md, references/802-regulations-dora-engineering-examples.md, assets/questions/802-dora-engineering-review-questionnaire.md, and assets/reports/802-dora-engineering-review-report-template.md all exist and are each referenced by exact path, one level deep, with labeled roles (chapters summary, examples, questionnaire, report template) stated both in the intro and in the workflow steps. The SKILL.md body stays an overview while all detail lives in the bundle files — easy navigation with no nesting.

5 / 5

Total

16

/

20

Passed

Description

87%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 well-constructed description that explicitly answers both what the skill does and when to use it, with concrete DORA-specific trigger phrases and strong, natural keyword coverage. Its only weaknesses are minor: capability coverage is expressed via trigger examples rather than a complete action list, and a few common synonyms (disaster recovery, business continuity) are absent.

DimensionReasoningScore

Specificity

The description names the domain ("Java enterprise systems", "operational resilience obligations under DORA") and several concrete actions ("Review a Java platform for DORA ICT risk controls", "Design operational resilience evidence", "Add incident, continuity, backup, recovery, or third-party ICT controls", "Assess resilience testing and monitoring"). It falls just short of the 5 anchor because the 'what' is expressed through trigger examples rather than a fully enumerated capability list.

4 / 5

Completeness

Both questions are answered explicitly: 'what' via "reviewing, designing, or modifying Java enterprise systems that may support financial entities, critical ICT services, third-party ICT provider integrations, or operational resilience obligations under DORA", and 'when' via the explicit "Use when..." clause plus concrete trigger phrases ("This should trigger for requests such as Review a Java platform for DORA ICT risk controls; ... Assess resilience testing and monitoring before production release"). This mirrors the 5-anchor example's structure of capability statement plus explicit trigger phrases.

5 / 5

Trigger Term Quality

Strong natural trigger vocabulary: "DORA", "operational resilience", "incident, continuity, backup, recovery", "resilience testing", "third-party ICT provider", "financial entities". A few common synonyms users might say are missing (e.g., "disaster recovery", "DR", "business continuity", "failover"), matching the 'good keyword coverage; a few natural terms missing' anchor rather than the comprehensive 5.

4 / 5

Distinctiveness Conflict Risk

A clear niche (DORA regulatory operational-resilience review for Java enterprise/financial-entity systems) with distinct triggers like "DORA ICT risk controls" and "operational resilience evidence for a financial service". The regulation-specific vocabulary makes triggering for the wrong skill unlikely; overlap with generic code-review or backup/recovery skills is minimal.

5 / 5

Total

18

/

20

Passed

Validation

87%

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

Validation — 14 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

relative_links

Relative link issues: 2 deeper-than-1-level

Warning

referenced_paths_exist

Referenced path issues: 6 deeper-than-1-level

Warning

Total

14

/

16

Passed

Repository
jabrena/plinth
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.