frontend-to-backend-requirements
Document frontend data needs for backend developers. Use when frontend needs to communicate API requirements to backend, or user says 'backend requirements', 'what data do I need', 'API requirements', or is describing data needs for a UI.
86
79%
Does it follow best practices?
Impact
99%
1.70xAverage score across 3 eval scenarios
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./dist/plugins/frontend-to-backend-requirements/skills/frontend-to-backend-requirements/SKILL.mdQuality
Discovery
82%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 a solid description with strong trigger terms and complete what/when coverage. The main weakness is the lack of specific concrete actions - it describes the general purpose but not the specific outputs or artifacts the skill produces. The distinctiveness could also be improved with more unique identifiers.
Suggestions
Add specific concrete actions like 'generate API contracts', 'create data requirement documents', or 'produce endpoint specifications' to improve specificity.
Include more distinctive terms like 'frontend-backend handoff', 'data contract', or specific output formats to reduce potential overlap with general API documentation skills.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description names the domain (frontend/backend communication) and a general action ('Document frontend data needs'), but lacks specific concrete actions like 'generate API contracts', 'create data schemas', or 'produce endpoint specifications'. | 2 / 3 |
Completeness | Clearly answers both what ('Document frontend data needs for backend developers') and when ('Use when frontend needs to communicate API requirements to backend') with explicit trigger phrases listed. | 3 / 3 |
Trigger Term Quality | Good coverage of natural terms users would say: 'backend requirements', 'what data do I need', 'API requirements', 'data needs for a UI'. These are realistic phrases a developer would use when needing this skill. | 3 / 3 |
Distinctiveness Conflict Risk | While it targets frontend-backend communication specifically, terms like 'API requirements' could overlap with general API documentation skills, and 'data needs' is somewhat generic. The niche is reasonably clear but not fully distinct. | 2 / 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 well-structured, actionable skill that clearly defines a collaborative workflow between frontend and backend developers. Its main strengths are the concrete output template and clear good/bad examples. The content could be tightened slightly and potentially split across files for better progressive disclosure.
Suggestions
Trim redundant explanations—the 'Good vs. Bad Requests' section largely repeats the 'What You Own vs. What Backend Owns' table concepts
Consider moving the detailed output template to a separate TEMPLATE.md file and referencing it from the main skill
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The content is reasonably efficient but includes some redundancy—the 'Good vs. Bad Requests' section repeats concepts already covered, and some explanatory text could be tightened. The tables and examples are useful but the overall document could be ~20% shorter. | 2 / 3 |
Actionability | Provides a complete, copy-paste ready markdown template with clear structure. The workflow steps are concrete, the output format is fully specified, and the good/bad examples give Claude exactly what to produce vs. avoid. | 3 / 3 |
Workflow Clarity | Clear 4-step workflow (Describe → List → Surface Uncertainties → Leave Room) with explicit guidance at each stage. The 'After Backend Responds' section provides a feedback loop for iterating on the document. | 3 / 3 |
Progressive Disclosure | Content is well-organized with clear sections and a table, but everything is in one file. For a skill of this length (~150 lines), some content like the detailed output template or examples could be split into referenced files for cleaner navigation. | 2 / 3 |
Total | 10 / 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
- softaworks/agent-toolkit
- Commit
3027f20
- 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.