Refactor high-complexity React components in Dify frontend. Use when `pnpm analyze-component --json` shows complexity > 50 or lineCount > 300, when the user asks for code splitting, hook extraction, or complexity reduction, or when `pnpm analyze-component` warns to refactor before testing; avoid for simple/well-structured components, third-party wrappers, or when the user explicitly wants testing without refactoring.
Install with Tessl CLI
npx tessl i github:langgenius/dify --skill component-refactoringOverall
score
88%
Does it follow best practices?
If you maintain this skill, you can automatically optimize it using the tessl CLI to improve its score:
npx tessl skill review --optimize ./path/to/skillEvaluation — 90%
↑ 1.27xAgent success when using this skill
Validation for skill structure
Discovery
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.
This is an excellent skill description that excels across all dimensions. It provides specific measurable triggers, concrete actions, clear scope boundaries, and explicit guidance on when NOT to use the skill. The inclusion of both positive and negative triggers makes it highly effective for skill selection.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: 'code splitting, hook extraction, or complexity reduction' and specifies the exact domain 'high-complexity React components in Dify frontend' with measurable thresholds (complexity > 50, lineCount > 300). | 3 / 3 |
Completeness | Clearly answers both what ('Refactor high-complexity React components') and when with explicit triggers ('Use when... complexity > 50 or lineCount > 300', 'when the user asks for code splitting'). Also includes helpful 'avoid when' guidance for negative triggers. | 3 / 3 |
Trigger Term Quality | Includes natural keywords users would say: 'code splitting', 'hook extraction', 'complexity reduction', 'refactor', plus specific tool commands like 'pnpm analyze-component'. These are terms developers naturally use when discussing React refactoring. | 3 / 3 |
Distinctiveness Conflict Risk | Highly distinctive with specific scope (Dify frontend, React components), measurable thresholds, and explicit exclusions ('avoid for simple/well-structured components, third-party wrappers'). Unlikely to conflict with general coding or testing skills. | 3 / 3 |
Total | 12 / 12 Passed |
Implementation
77%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a strong, actionable skill with excellent workflow clarity and concrete code examples specific to the Dify codebase. The main weakness is length - the six detailed refactoring patterns with full before/after examples could be extracted to a separate PATTERNS.md file, keeping SKILL.md as a leaner overview. Some explanatory text about basic React concepts (what hooks are, why to extract components) could be trimmed since Claude knows these fundamentals.
Suggestions
Extract the six detailed refactoring patterns (with full code examples) to a separate PATTERNS.md file, keeping only brief summaries and links in the main skill
Remove explanatory text about basic React concepts (e.g., 'When: Component has complex state management') - Claude understands these; just show the pattern
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is comprehensive but includes some redundant explanations (e.g., explaining what hooks do, basic React patterns Claude already knows). The before/after examples are valuable but could be more condensed in places. | 2 / 3 |
Actionability | Provides fully executable code examples, specific bash commands, concrete patterns with real file paths from the Dify codebase, and copy-paste ready snippets. The refactoring patterns include complete TypeScript examples. | 3 / 3 |
Workflow Clarity | Clear 5-step workflow with explicit validation checkpoints (lint, type-check, test after each extraction). Includes a visual feedback loop diagram and clear pass/fail decision points before proceeding. | 3 / 3 |
Progressive Disclosure | Content is well-organized with clear sections, but the document is quite long (~400 lines) with detailed patterns that could be split into separate reference files. The 'Related Skills' section at the end suggests good linking but most content is inline. | 2 / 3 |
Total | 10 / 12 Passed |
Validation
88%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 14 / 16 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
metadata_version | 'metadata' field is not a dictionary | Warning |
license_field | 'license' field is missing | Warning |
Total | 14 / 16 Passed | |
Table of Contents
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.