CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

pre-modification-check

Use before modifying, refactoring, moving, or deleting files in a Repowise-indexed repository, especially shared utilities, core modules, public APIs, or files the user did not explicitly identify.

Quality

83%

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

The canonical home for this skill is pre-modification-check in repowise-dev/repowise

SKILL.md
Quality
Evals
Security

Quality

Content

92%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 an exemplary instruction-only skill: copy-paste-ready tool calls, concrete warning thresholds, a per-scenario workflow with a threshold checklist, and a tool-error fallback — all in under 50 lines with nothing padded. The only improvement is trimming a couple of motivational rationale sentences.

DimensionReasoningScore

Conciseness

The body is lean and field explanations are tool-specific knowledge Claude would not already have (defect_profile, bug_magnet, co_change_partners), so they earn their tokens. A few rationale sentences could be trimmed — 'This prevents accidentally violating architectural decisions' and 'the strongest single signal that the next edit breaks something; lead with it' explain motivation rather than instruct — matching anchor 4's 'minor instances of over-explanation'. Not 5 because of those trimmable sentences; not 3 because there is no padded or generic explanation of concepts Claude already knows.

4 / 5

Actionability

Every tool invocation is given as copy-paste-ready literal syntax — get_risk(targets=["path/to/file.py"]), the batched multi-file and directory example, get_context(targets=["file.py"]), and get_health(targets=["file.py"]) — covering the common cases (single edit, multi-file edit, refactor/move). Return fields, exact warning thresholds (90th percentile, >10 dependents, bus factor 1), and a tool-error fallback are all specified, matching anchor 5.

5 / 5

Workflow Clarity

The workflow is clearly sequenced by scenario (before editing → batch case → warning criteria → refactor/move path → error handling), the 'When to warn the user' section is an explicit threshold checklist, and the Error handling section provides a feedback loop for tool failures ('proceed with the modification but note that risk assessment was unavailable'). This matches anchor 5's 'explicit validation steps; feedback loops for error recovery; checklists'. Not 4: no checkpoint is missing within the skill's pre-modification scope — what happens after the warning is the user's decision, outside this skill's remit.

5 / 5

Progressive Disclosure

The skill is under 50 lines with no bundle files present (references/, scripts/, assets/ do not exist), and no external references are needed; per the rubric's simple-skill guideline, well-organized sections alone earn the top score. Headers cleanly separate each scenario, and no content that belongs in a separate file is inlined.

5 / 5

Total

19

/

20

Passed

Description

65%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 has a strong, explicit trigger clause with natural developer vocabulary and a clearly distinct niche, but it omits any statement of what the skill does when invoked — the capability is left entirely implicit. Adding one clause describing the actual action (e.g., assessing per-file change risk via Repowise) and a few change-verb synonyms would round it out.

Suggestions

State the capability explicitly, e.g. 'Assesses change risk (hotspots, dependents, bug history, ownership) via Repowise get_risk before modifying, refactoring, moving, or deleting files...' — this fixes the missing 'what' that caps completeness.

Add common trigger synonyms such as 'updating', 'editing', or 'renaming files' alongside the existing 'modifying, refactoring, moving, or deleting' for broader natural-term coverage.

Consider naming the concrete outputs Claude gets (risk scores, dependents count, test gaps) so users can recognize the skill by what it returns, not just when it applies.

DimensionReasoningScore

Specificity

The description names a specific domain ('Repowise-indexed repository') and concrete trigger actions ('modifying, refactoring, moving, or deleting files'), but it never states what the skill itself does — the capability (e.g., assessing change risk, calling get_risk) is only implied by the skill name. Per the guideline to score only what is explicitly stated, this matches anchor 3: domain named with some concrete actions but not comprehensive capability coverage. Not 4 because the skill's own actions are entirely unstated; not 2 because the domain and trigger actions are specific, not generic.

3 / 5

Completeness

The 'when' is explicit and detailed ('Use before modifying, refactoring, moving, or deleting files...'), but the 'what' — what the skill actually does when invoked — is never stated in the description itself. This sits between anchor 2 (only 'when' present without 'what') and anchor 3 (clear 'what', weak 'when'): the missing 'what' mirrors anchor 2's condition, but the unusually rich, explicit 'when' clause with concrete trigger phrases lifts it above anchor 2's bare 'Use when working with documents' example. Not 4 because one of the two required elements is absent, not 2 because the trigger guidance is far stronger than the anchor-2 example.

3 / 5

Trigger Term Quality

Natural developer vocabulary is present: 'modifying, refactoring, moving, or deleting files', 'shared utilities', 'core modules', 'public APIs', plus an explicit 'Use before...' clause. A few common synonyms are missing ('updating', 'editing', 'renaming', 'changing code'), so it does not reach anchor 5's comprehensive coverage; it clearly exceeds anchor 3's 'some relevant keywords' since four change-type verbs and three file-class nouns are covered.

4 / 5

Distinctiveness Conflict Risk

The 'Repowise-indexed repository' qualifier creates a clear niche with distinct triggers and minimal conflict risk against generic file- or code-editing skills, matching anchor 5. Not 4: the tool-specific scoping means even closely related skills would not be wrongly triggered outside an indexed repository.

5 / 5

Total

15

/

20

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 — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository

repowise-dev/repowise

Path

plugins/codex/skills/pre-modification-check/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.