form-auto-save
Automatic form submission after user input changes using a debounce mechanism to prevent excessive server requests. Creates a seamless auto-save experience for forms with rich text editors or multiple fields.
48
50%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./skills/form-auto-save/SKILL.mdQuality
Discovery
50%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 communicates the core concept of debounced form auto-submission reasonably well, but lacks an explicit 'Use when...' clause that would help Claude know exactly when to select this skill. It would benefit from more specific trigger terms and clearer delineation of when this skill should be chosen over related form or debounce skills.
Suggestions
Add an explicit 'Use when...' clause, e.g., 'Use when the user wants forms to auto-submit on input change, needs debounced form submission, or asks about auto-save for form fields.'
Include more natural trigger term variations users might say, such as 'auto-submit', 'delayed submit', 'throttle requests', 'onChange submit', or specific framework contexts like 'React form debounce'.
List more concrete actions to improve specificity, e.g., 'Implements debounced onChange handlers, configures delay timing, integrates with rich text editors like TipTap or Quill, and handles form serialization for background submission.'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (form submission, debounce mechanism) and some actions (auto-save, preventing excessive server requests), but doesn't list multiple concrete implementation actions like specific code patterns, frameworks, or techniques. | 2 / 3 |
Completeness | The 'what' is reasonably covered (automatic form submission with debounce), but there is no explicit 'Use when...' clause or equivalent trigger guidance, which per the rubric caps completeness at 2. | 2 / 3 |
Trigger Term Quality | Includes some relevant keywords like 'debounce', 'auto-save', 'form submission', 'rich text editors', but misses common user variations like 'auto-submit', 'throttle', 'onChange', 'delayed submit', or specific framework names users might mention. | 2 / 3 |
Distinctiveness Conflict Risk | The combination of debounce + form submission + auto-save is somewhat specific, but could overlap with general form handling skills, debounce utility skills, or auto-save skills in a large skill library. | 2 / 3 |
Total | 8 / 12 Passed |
Implementation
50%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
The skill excels at actionability with complete, executable code examples and clear file paths, but is significantly too verbose—explaining concepts like debouncing, passive listeners, and auto-save that Claude already understands. The testing section, while thorough, nearly doubles the document length and would benefit from being in a separate file. Trimming explanatory prose and restructuring into a concise overview with referenced details would substantially improve this skill.
Suggestions
Remove the 'When to Use', 'Related Patterns', and 'References' sections entirely—Claude already knows when auto-save is appropriate and can look up Stimulus/Turbo docs.
Trim 'Important Considerations' to a brief bullet list of non-obvious gotchas (e.g., 'turbo_permanent: true required to preserve timers across navigation') without explaining what passive listeners or debouncing are.
Extract the testing section (turbo-fetch controller, helper, specs) into a separate TESTING.md file and reference it with a single link.
Add a brief validation step after controller creation, e.g., 'Verify: open browser DevTools Network tab, edit a field, confirm PATCH request fires after 8s.'
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is quite verbose, explaining concepts Claude already knows (what auto-save is, when to use it, what debounce means, what passive event listeners do). The 'When to Use' section, 'Important Considerations' explanations, and 'Related Patterns' section add little actionable value. The testing section is extensive and could be significantly trimmed. | 1 / 3 |
Actionability | The skill provides fully executable, copy-paste ready code for the Stimulus controller, view integration (Slim templates), test helpers, and system specs. File paths are specified, and the code is complete and runnable. | 3 / 3 |
Workflow Clarity | The steps are presented (controller creation, view integration, testing) but lack explicit sequencing or validation checkpoints. There's no 'verify the controller is loaded' step or feedback loop for confirming auto-save works during implementation. The troubleshooting section partially compensates but is reactive rather than proactive. | 2 / 3 |
Progressive Disclosure | The content is a monolithic document with everything inline. The testing section (turbo-fetch controller, helper, specs) could be split into a separate file. No bundle files are provided to reference, but the skill doesn't attempt any structural separation despite being ~180 lines long. | 2 / 3 |
Total | 8 / 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.
Validation — 11 / 11 Passed
Validation for skill structure
No warnings or errors.
- Repository
- RoleModel/rolemodel-skills
- Commit
4d83977
- 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.