CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

code-style-patterns

Apply community code styles from shadcn, sindresorhus, or ahmadawais. Use when the user names those styles or wants a community pattern applied to code. It does not design plugins (that's `plugin-craft`).

Quality

76%

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

Fix and improve this skill with Tessl

tessl review fix ./plugins/tooling/skills/code-style-patterns/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

67%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 routing skill: modes table, explicit load triggers, verified one-level-deep references, golden rules, and a closing feedback loop. The main costs are token inefficiency from boilerplate repeated across the three style sections and abstract directives whose substance lives entirely in the reference files.

Suggestions

State the shared four-step workflow (identify repos → inspect → adapt → return) once in a single section and have each style section link to it, cutting ~12 repeated lines.

Merge the "Did this help?" section into the Quality Checklist item that already mandates the closing question to remove the duplication.

Make the abstract directives executable, e.g. replace "produce output that feels like it came from that style" with the concrete check the reference applies (name key repos, mirror naming/structure conventions, show a before/after snippet).

DimensionReasoningScore

Conciseness

The body is mostly efficient (tables, terse principle bullets, no explanations of concepts Claude already knows), but the identical four-step "How To Use This Style" block ("Identify relevant repos from the map / Inspect them (clone to /tmp...) / Adapt patterns responsibly / Return to the user's codebase...") is repeated nearly verbatim in all three style sections, and the "Did this help?" section duplicates a Quality Checklist item. This matches "mostly efficient but could be tightened"; not a 4 because the triplicated boilerplate is a clear trim target, not a minor instance.

3 / 5

Actionability

As an instruction/routing skill it gives concrete executable guidance: exact reference paths per mode in the Modes table ("references/shadcn.md"), bold load directives with specific trigger conditions, and a defined per-style procedure (identify repos from the map, clone to /tmp, adapt, return to the codebase). Not a 5 because some directives stay abstract ("produce output that feels like it came from that style", "adapt patterns responsibly") with the concrete specifics fully deferred to references; not a 3 because the routing and steps are specific and executable, not high-level hints.

4 / 5

Workflow Clarity

The multi-step process is clearly sequenced: pick a mode from the table, load the matching reference, follow its "How To Use This Style" steps, apply the Golden Rules, then run the Quality Checklist, ending with a feedback question ("Did this solve what you were trying to do?"). The checklist provides checkpoints and the closing question a feedback loop. Not a 5 because there are no error-recovery loops (e.g. what to do when a repo can't be inspected or a pattern doesn't fit) and the sequence is spread across sections rather than stated once.

4 / 5

Progressive Disclosure

Scored against the actual bundle: references/shadcn.md, references/sindresorhus.md, and references/ahmadawais.md all exist with the sections the body cites ("How To Use This Style", repo maps), references are one level deep, and they are clearly signaled via the Modes table's Load column and bold "Always load" directives. Not a 5 because the inline "Key principles from the reference (internalize these)" lists duplicate reference content that belongs behind the disclosure boundary, and the routing table's "Relevant reference(s)" / "Load target reference + current code" entries are less precise than the named files.

4 / 5

Total

15

/

20

Passed

Description

73%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 strong description with an explicit Use-when clause, concrete named style sources, and a useful boundary exclusion. Its main weakness is thin action coverage and trigger phrasing that relies entirely on the developer names rather than also covering the task domains those styles apply to.

Suggestions

List the concrete actions available (e.g. refactor existing code toward a style, curate or add a new developer reference, translate patterns across stacks) instead of the single generic verb "apply".

Add task-domain trigger phrases to the Use-when clause, e.g. "Use when the user mentions shadcn/ui, Next.js component conventions, tiny TypeScript utilities, awesome lists, or polished CLI tooling".

Include common synonym spellings (e.g. "shadcn/ui", "Sindre Sorhus") so the description matches how users naturally phrase these requests.

DimensionReasoningScore

Specificity

"Apply community code styles from shadcn, sindresorhus, or ahmadawais" names the domain with three concrete style targets but offers only one action ("apply"), matching the anchor for domain plus 1-2 concrete actions that are not comprehensive. Not a 4 because no additional specific actions (refactor, curate, translate patterns) are listed; not a 2 because the named developers make the domain far more concrete than a generic phrase.

3 / 5

Completeness

Both parts are explicit: "what" is applying community code styles from the three named developers, and "when" is stated via "Use when the user names those styles or wants a community pattern applied to code", plus a boundary clause ("It does not design plugins"). Not a 5 because the "when" clause is meta ("names those styles") rather than concrete trigger phrases like "shadcn/ui patterns" or "tiny utility style"; not a 3 because the "when" is explicit, not merely implied.

4 / 5

Trigger Term Quality

Good natural keyword coverage — "shadcn", "sindresorhus", "ahmadawais", "code styles", "community pattern" are exactly what a user would say when requesting these styles. Not a 5 because it lacks synonyms and task-domain triggers (e.g. "shadcn/ui", "Next.js component", "CLI patterns", "WordPress") that would catch requests describing the domain without naming the developer; not a 3 because the primary trigger terms are present and natural rather than missing variations.

4 / 5

Distinctiveness Conflict Risk

Naming three specific developers creates a clear niche with distinct triggers, and the explicit exclusion "It does not design plugins (that's `plugin-craft`)" actively reduces conflict with adjacent skills — minimal conflict risk. Not a 4 because no overlap risk with closely related skills is identifiable from the text.

5 / 5

Total

16

/

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

saif-shines/devex-kit

Path

plugins/tooling/skills/code-style-patterns/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.