cohesion-over-testability

Detect and collapse production code that was split into two pieces (a 'pure' inner function and a thin wrapper/handler/component that calls it) for the single purpose of letting a unit test reach the inner piece. The smell is structure shaped by the test suite, not by the system. Use when reviewing a helper paired with a `.test.ts` of similar or greater size, when an exported function has exactly one production caller next door, when a function takes optional `deps` whose only non-default value lives in the test, when a getter/setter pair injects state the production code already owns, or when the user says "is this earning its keep", "why is this exported", "trace the callers", "is this split for the test", "the test is shaping the API", "could this be one function". Prefer cohesion over unit-testability; pay the regression-coverage cost a different way (integration tests, type safety, deletion).

Quality

86%

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

Quality

Content

72%

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

A well-structured, highly actionable skill body with a clear procedure and a real worked example, held back only by repetition of its central question and a missing post-inline verification checkpoint for a destructive workflow.

Suggestions

Consolidate the 'would the inner exist without the test?' question into one canonical statement; later sections can reference it instead of restating it.

Add an explicit verification step after inlining — e.g. 'run the integration test / suite and confirm coverage of the collapsed branch' — so the destructive workflow has a clear feedback loop.

Consider moving the Common Forms (1–5) into the sweep-procedure reference if the main file's token budget matters, since they overlap with the audit-sweep signals.

Dimension	Reasoning	Score
Conciseness	The body is dense and assumes Claude's competence (no explanation of what a unit test or cohesion is), but the central diagnostic question — 'if the test didn't exist, would the inner function exist as a separate piece?' / 'without the test, would I have written this as two pieces?' — is restated nearly verbatim across 'The Signal vs The Reason', 'The Procedure', and 'When NOT to Inline', which could be tightened.	2 / 3
Actionability	Provides copy-pasteable audit greps (find/wc loop, grep for optional deps, getter/setter pattern), a concrete six-step procedure, and a real worked example with file LOC counts and a commit hash — fully executable guidance rather than abstract direction.	3 / 3
Workflow Clarity	The six-step procedure is clearly sequenced with a decision checkpoint in step 1 ('If the count is one, continue... stop and reassess'), but inlining is a destructive operation (deleting code and tests) and step 6 picks a coverage strategy without an explicit verification step confirming the collapse preserved behavior, so the cap applies.	2 / 3
Progressive Disclosure	SKILL.md is a well-sectioned overview and the one bundle file, references/sweep-procedure.md, is signaled with a clear 'Load on demand based on the task' cue and an explicit description of when to read it; the reference is one level deep and the file exists.	3 / 3
	Total	10 / 12 Passed

Description

100%

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 strong description: third-person voice, concrete actions, explicit 'Use when' triggers with natural user phrasing, and a narrow, distinctive niche. It earns full marks on every dimension without padding.

Dimension	Reasoning	Score
Specificity	Lists multiple concrete actions — 'Detect and collapse production code that was split into two pieces', 'drop the export', 'pay the regression-coverage cost a different way (integration tests, type safety, deletion)' — naming both the detection and the remediation path.	3 / 3
Completeness	Explicitly answers both what (detect and collapse test-shaped splits) and when via an explicit 'Use when reviewing a helper paired with a .test.ts...' clause enumerating several triggering conditions.	3 / 3
Trigger Term Quality	Includes natural phrases a user would actually say — 'is this earning its keep', 'why is this exported', 'trace the callers', 'is this split for the test', 'the test is shaping the API', 'could this be one function' — alongside structural triggers like a paired .test.ts.	3 / 3
Distinctiveness Conflict Risk	Occupies a clear niche — structure shaped by the test suite rather than the system — with distinctive triggers (one production caller next door, optional deps only non-default in the test) unlikely to fire for general refactoring skills.	3 / 3
	Total	12 / 12 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
relative_links	Relative link issues: 6 suspicious	Warning

	Total	15 / 16 Passed

Repository: EpicenterHQ/epicenter
Path: .agents/skills/cohesion-over-testability/SKILL.md
Commit: cb12bcc

Reviewed: 3 days 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.