mock-best-practices

Use when reviewing CI coverage, automated checks, or test strategy related to Follow mocking best practices. Focus on whether the rule is continuously verified, not just documented.

Quality

57%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./skills/mock-best-practices/SKILL.md

Quality

Content

65%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 a well-structured, token-efficient overview that correctly delegates detailed code and guidance to references/rule.md via a clearly signaled one-level-deep reference. However, the Check/Fix/Explain sections are templated one-liners offering vague direction rather than actionable steps, and there is no sequenced workflow with validation checkpoints in the body itself.

Suggestions

Make the Check section actionable in the body: name what to look for concretely (e.g., 'grep for jest.mock on modules under test, missing afterEach(restoreAllMocks), spies on private methods') rather than 'Review this test file for mocking patterns'.

Turn the Check → Fix → Explain sections into a light sequence (review → flag over-mocking/cleanup gaps → apply fixes → re-run tests) so the body conveys order, or fold them into the Quick Reference to cut template redundancy.

Surface one or two key verification cues from references/rule.md (e.g., 'confirm the test fails when the mock is removed') so the review has a built-in checkpoint without leaving the overview.

Dimension	Reasoning	Score
Conciseness	The body is lean (~45 lines): a one-sentence rationale, a 4-bullet Quick Reference with concrete specifics ('jest.restoreAllMocks() in afterEach', 'Use MSW'), and a clean pointer to references/rule.md. The four near-identical one-line mode sections (Check/Fix/Explain/Code Review) add mild template redundancy, keeping it just below the every-token-earns-its-place anchor.	4 / 5
Actionability	The Quick Reference gives concrete, specific directives (mock external dependencies not business logic; cleanup via jest.restoreAllMocks(); use MSW; test behavior not internals), but the Check/Fix/Explain sections are high-level direction with no executable code or commands in the body ('Review this test file for mocking patterns...'). This matches 'some concrete guidance but incomplete' rather than the mostly-executable anchor — the executable examples live only in references/rule.md.	3 / 5
Workflow Clarity	The Check/Fix/Explain/Code Review sections act as a mode menu rather than a sequenced workflow — there is no ordered process and no validation checkpoints for the review outcome (the verification steps live only in the reference file). The single-action-5 exception doesn't apply since the body defines four parallel vague modes, so it lands on 'steps listed but checkpoints missing or implicit'.	3 / 5
Progressive Disclosure	The skill is under 50 lines with a well-organized body and a clearly signaled one-level-deep reference — 'For full implementation details, code examples, and framework-specific guidance, see references/rule.md' — and references/rule.md exists as a single flat file containing the detailed material (code examples, when-to-mock table, common mistakes, verification steps). This matches the simple-skill exception: well-organized sections with an appropriate, real external reference keeping bulk detail out of context.	5 / 5
	Total	15 / 20 Passed

Description

50%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 an explicit trigger clause and relevant testing keywords, but its core capability statement is obscured by the awkwardly embedded rule name ('related to Follow mocking best practices') and by framing the skill as CI-enforcement review rather than mocking guidance. Trigger terms lack common variations like 'unit tests', 'test doubles', or 'jest', and the broad CI/test-strategy framing creates overlap risk with sibling checklist rules.

Suggestions

Rewrite the capability clause to state what the skill does in third person (e.g., 'Reviews test mocking strategy: what to mock, cleanup with jest.restoreAllMocks(), MSW for API mocks') instead of embedding the raw rule name in a 'related to' clause.

Add natural trigger synonyms such as 'unit tests', 'test doubles', 'stubs', or 'jest mocks' so the description matches how users actually ask for mocking help.

Sharpen the 'when' clause to reference mocking/test-double work specifically (not just generic 'CI coverage, automated checks, or test strategy') to reduce overlap with other CI/testing checklist skills.

Dimension	Reasoning	Score
Specificity	The description names the domain and one concrete action — 'reviewing CI coverage, automated checks, or test strategy' — plus a directive to 'Focus on whether the rule is continuously verified, not just documented', but the awkward embedded phrase 'related to Follow mocking best practices' muddles what the skill actually does. It lists 1-2 concrete actions without comprehensive coverage, matching the anchor for a named domain with partial actions rather than the several-specific-actions anchor above.	3 / 5
Completeness	An explicit 'Use when...' trigger clause is present, but the 'what' is weak: the description reads as being about CI enforcement review rather than the skill's actual capability (mocking best-practice guidance for tests), leaving the skill's purpose implicit. It falls between the 'only when present without what' anchor (2) and the both-present-but-when-could-be-more-explicit anchor (4), so 3 fits best.	3 / 5
Trigger Term Quality	Relevant keywords are present ('mocking', 'CI coverage', 'test strategy', 'automated checks'), but common natural variations users would say — 'unit tests', 'test doubles', 'stubs', 'jest', 'spies' — are missing. This matches 'some relevant keywords but missing common variations or synonyms' rather than the good-coverage anchor, which would require a fuller spread of natural terms.	3 / 5
Distinctiveness Conflict Risk	'CI coverage, automated checks, or test strategy' spans broad testing territory that overlaps generic test-review and CI-review skills, though 'mocking best practices' carves out a partial niche. This is 'somewhat specific but could still overlap with similar skills' — not the minimal-conflict clear-niche anchor (5) nor the high-overlap anchor (2).	3 / 5
	Total	12 / 20 Passed

Validation

93%

Warnings & errors only

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

Criteria	Description	Result
metadata_version	'metadata.version' is missing	Warning

	Total	15 / 16 Passed

Repository: thedaviddias/Front-End-Checklist
Path: skills/mock-best-practices/SKILL.md
Commit: 7bfd868

Reviewed: 1 day ago

Table of Contents

Discovery Implementation Validation

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.