tessl-labs/frontend-state-management
Proactively choose the right state management pattern: derived state, URL state, server state, local state, lifted state, Context, or external store. Always apply without being asked.
84
76%
Does it follow best practices?
Impact
97%
1.16xAverage score across 5 eval scenarios
Passed
No known issues
Quality
Discovery
67%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 description excels at specificity and distinctiveness by comprehensively listing concrete state management patterns and decisions. However, it lacks explicit trigger guidance ('Use when...') and could benefit from more natural user-facing keywords that match how developers actually ask for help with state management decisions.
Suggestions
Add a 'Use when...' clause with explicit triggers like 'Use when deciding where to store state, choosing between useState/useReducer/Context/Redux, or when the user asks about state architecture.'
Include natural user phrases as trigger terms: 'where should this state live', 'useState vs Context', 'global state', 'prop drilling', 'state management library'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete patterns: 'local state vs lifted state vs Context vs external stores, derived state vs stored state, server state vs client state, URL-as-state for filters/search, form state patterns, optimistic updates, and stale closure prevention.' | 3 / 3 |
Completeness | Clearly answers 'what' with comprehensive coverage of state management patterns, but lacks an explicit 'Use when...' clause. The phrase 'Apply these rules in every frontend component' implies when but doesn't provide explicit trigger guidance. | 2 / 3 |
Trigger Term Quality | Contains relevant technical terms like 'React', 'state management', 'Context', 'form state', 'optimistic updates' but lacks natural user phrases. Users might say 'where should I put this state' or 'useState vs Redux' which aren't captured. | 2 / 3 |
Distinctiveness Conflict Risk | Highly specific to React/JS state management decisions with distinct technical scope. The detailed enumeration of specific patterns (Context, URL-as-state, stale closures) creates a clear niche unlikely to conflict with general React or JavaScript skills. | 3 / 3 |
Total | 10 / 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 comprehensive, highly actionable skill with excellent workflow clarity through its decision tree and checklist. The code examples are production-ready and cover real-world scenarios well. However, the skill is verbose for a SKILL.md file—it reads more like a complete guide than a concise reference, and could benefit from splitting detailed patterns into separate referenced files.
Suggestions
Consider splitting detailed sections (Forms, Optimistic Updates, Vanilla JS) into separate referenced files to reduce the main skill to ~200 lines with a decision tree and quick reference table
Consolidate the multiple fetch/useEffect examples into one canonical pattern with brief notes on variations, rather than showing full WRONG/RIGHT pairs for each scenario
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | While the content is well-organized and avoids explaining basic React concepts, it is quite lengthy (~600 lines) with extensive WRONG/RIGHT examples that could be more condensed. Some sections repeat similar patterns (e.g., multiple fetch examples) where a single canonical example would suffice. | 2 / 3 |
Actionability | Excellent actionability with fully executable TypeScript/React code examples throughout. Every pattern includes copy-paste ready implementations with proper typing, error handling, and real-world scenarios like cart management, search, and form handling. | 3 / 3 |
Workflow Clarity | The decision tree at the beginning provides an explicit, numbered workflow for classifying state. Each section follows a clear WRONG/RIGHT pattern with explicit rules. The checklist at the end serves as a validation checkpoint for every component. | 3 / 3 |
Progressive Disclosure | Content is well-structured with clear sections and a quick reference table, but the entire skill is monolithic (~600 lines). The verifiers are referenced at the end, but detailed patterns that could be split into separate files (e.g., form patterns, optimistic updates) are all inline. | 2 / 3 |
Total | 10 / 12 Passed |
Validation
81%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 9 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
skill_md_line_count | SKILL.md is long (667 lines); consider splitting into references/ and linking | Warning |
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 9 / 11 Passed | |
Reviewed
Table of Contents