CtrlK
BlogDocsLog inGet started
Tessl Logo

asymmetric-wins

Find the small promise to refuse when preserving it forces a large implementation family: trade a measured amount of fidelity, compatibility, modes, or reproducibility to delete disproportionate complexity. Use when the user says "asymmetric wins", "asymmetric win", "what can we refuse", "what collapses the most code", "does this UI refactor need to be pixel perfect", or when a design adds a fast path, fallback parser, provider-specific SDK, second transport, compatibility alias, exact reproduction requirement, or rare mode beside the canonical path.

76

Quality

93%

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

SKILL.md
Quality
Evals
Security

Quality

Content

87%

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

A tightly written, well-structured instruction skill with concrete templates, an explicit procedure, and a fully worked example. The only gap is that the destructive refusal lacks an explicit in-skill verification checkpoint, leaving the safety gate implicit.

Suggestions

Add an explicit validation checkpoint in the Procedure (e.g., a numbered step 'Count the code family via refactoring and confirm it disappears; if it only relocates complexity, keep the feature') before the refusal is committed, so the destructive refusal has an in-skill verify gate.

Make the safety/rollback condition a labeled checkpoint rather than prose: e.g., a 'Gate: refuse only if product sentence survives AND deletion prize is real' step with a keep/refuse branch.

For destructive refusals executed via greenfield-clean-breaks, state an explicit post-deletion verification (tests still pass, callers all migrated) as part of the workflow.

DimensionReasoningScore

Conciseness

Lean throughout with no explanation of concepts Claude already knows; every section (spine, procedure, templates, ladder, worked example) earns its place and assumes competence. Not 2 because there is no padding or unnecessary context to tighten.

3 / 3

Actionability

A copy-paste-ready decision template with explicit fill-in fields, a six-step procedure naming concrete candidate types and deletion prizes, and a fully worked social-sign-in example populating every field. Not 2 because the guidance is concrete and instantiated rather than abstract or pseudocode.

3 / 3

Workflow Clarity

The procedure is well sequenced with a safety gate ("Keep the feature when the user loss is load-bearing"), but the refusal deletes a code family (destructive) and the verification checkpoint is implicit and partly delegated to the refactoring skill rather than an explicit validate/retry step. Capped at 2 per the destructive-operation rule rather than 3.

2 / 3

Progressive Disclosure

A single self-contained file organized into well-labeled sections, with one clearly signaled one-level-deep optional pointer to a narrative article. No bundle files exist, and the structure is appropriate for a single-file skill. Not 2 because organization is clean and the lone reference is explicitly signaled and shallow.

3 / 3

Total

11

/

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 precise, third-person description that states a concrete action, enumerates specific triggering design patterns, and provides an explicit Use-when trigger list. It is concise yet complete and clearly distinguishable from sibling skills.

DimensionReasoningScore

Specificity

Lists concrete actions ("Find the small promise to refuse") plus an enumerated catalog of refusal points (fast path, fallback parser, provider-specific SDK, compatibility alias, exact reproduction, rare mode), matching the multiple-specific-actions anchor. Not 2 because it goes beyond naming a domain into a concrete pattern inventory.

3 / 3

Completeness

Answers both what (find the small promise to refuse and trade measured fidelity/compatibility/modes/reproducibility to delete complexity) and when via an explicit "Use when..." clause with triggers. Not 2 because the when is explicit, not merely implied.

3 / 3

Trigger Term Quality

Explicitly quotes natural user phrases ("asymmetric wins", "asymmetric win", "what can we refuse", "what collapses the most code", "does this UI refactor need to be pixel perfect") as first-class triggers. Not 2 because these are real conversational phrases rather than only technical jargon.

3 / 3

Distinctiveness Conflict Risk

Distinct niche (the asymmetric-wins refusal move) anchored by skill-specific trigger phrases unlikely to fire for other skills. Not 2 because the triggers are specific enough to avoid generic refactoring-skill overlap.

3 / 3

Total

12

/

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
EpicenterHQ/epicenter
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.