CtrlK
BlogDocsLog inGet started
Tessl Logo

business-logic-in-components

Use whenever discussing, designing, implementing, modifying, reviewing, or refactoring component-based UI development (React, Vue, Angular, Svelte, SolidJS, Astro, Flutter widgets, SwiftUI views, etc.). Provides the meanings and boundaries of domain and presentation concerns.

60

Quality

70%

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

Fix and improve this skill with Tessl

tessl review fix ./skills/knowledge/business-logic-in-components/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

61%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 delivers focused, well-structured conceptual guidance with illustrative code examples and no unnecessary padding. It is weaker on actionability and workflow clarity because the guidance is diagnostic/conceptual rather than a concrete executable procedure with explicit checkpoints.

Suggestions

Add a short, explicit procedure for applying the guidance (e.g., 1) locate rules coupled to a component, 2) mark as Domain Logic candidate, 3) extract into a UI-free domain module, 4) verify the module has no component/UI imports) with a validation checkpoint confirming the extracted domain code has zero UI dependencies.

Make at least one code example complete and copy-paste runnable (with imports/types) so the extraction pattern is unambiguous, rather than illustrative snippets.

Tighten the 'For some people... For others...' paragraph, which explains term ambiguity at a length that could be trimmed without losing the core directive.

DimensionReasoningScore

Conciseness

The body is lean and focused on value-add term distinctions (Business Rules vs Domain Logic vs Presentation Logic vs UI Logic) plus a directive to stop using 'Business Logic'; it avoids explaining basics Claude already knows, with only minor instances of explanatory padding around the term ambiguity.

4 / 5

Actionability

Provides concrete directives ('treat it as a Domain Logic candidate worth isolating') and illustrative tsx/ts snippets, but the code examples lack imports/types and are illustrative rather than copy-paste executable, and the identification/extraction procedure is left partly to judgment, matching the 'some concrete guidance but incomplete' anchor.

3 / 5

Workflow Clarity

The content presents a logical progression of principles (distinguish by layer, identify candidates, isolate, don't confuse physical separation with layer separation) but is not a sequenced procedural workflow with explicit checkpoints; no destructive/batch operations are present so the validation cap does not apply.

3 / 5

Progressive Disclosure

The body is a single self-contained document with clear section headers (Core Principle, Distinguish Them by Layer, Not Every Code Extraction Is Layer Separation) and no nested or buried references; no bundle files exist, and the ~75-line content is well-organized with only minor organization gaps.

4 / 5

Total

14

/

20

Passed

Description

78%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 clearly states both what the skill provides and when to use it, with strong trigger-term coverage including a wide framework list. It is slightly held back by activity-verb actions that are generic rather than concrete, and a broad component-UI trigger that risks minor overlap with related skills.

DimensionReasoningScore

Specificity

Names the domain ('component-based UI development') and several activity verbs ('discussing, designing, implementing, modifying, reviewing, or refactoring') plus a clear 'what' ('Provides the meanings and boundaries of domain and presentation concerns'), but the actions are generic activity types rather than concrete distinct capabilities, matching the anchor that names domain and 1-2 actions without comprehensive coverage.

3 / 5

Completeness

Explicitly answers both 'when' ('Use whenever discussing, designing, implementing, modifying, reviewing, or refactoring...') and 'what' ('Provides the meanings and boundaries of domain and presentation concerns') with concrete trigger phrases, matching the top anchor.

5 / 5

Trigger Term Quality

Includes natural terms users would say ('refactoring', 'reviewing', 'component-based UI development') plus a broad framework list (React, Vue, Angular, Svelte, SolidJS, Astro, Flutter widgets, SwiftUI views), giving good keyword coverage with only a few natural variations missing.

4 / 5

Distinctiveness Conflict Risk

The niche (meanings and boundaries of domain vs presentation concerns) is mostly distinct with a clear focus, but the broad trigger ('component-based UI development') creates minor overlap risk with general component/UI skills rather than minimal conflict.

4 / 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
choegyumin/agent-skills
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.