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.
Install with Tessl CLI
npx tessl i github:softaworks/agent-toolkit --skill frontend-to-backend-requirements83
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/skillAgent success when using this skill
Validation for skill structure
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 reasonably well-constructed 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 capabilities. The distinctiveness could also be improved to avoid overlap with general API or documentation skills.
Suggestions
Add specific concrete actions like 'generate endpoint specifications', 'list required fields and data types', or 'create API contracts' to improve specificity.
Consider adding distinguishing details like output format (e.g., 'produces structured requirements documents') to reduce potential overlap with general API documentation skills.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (frontend/backend communication) and the general action (document data needs), but lacks specific concrete actions like 'generate API contracts', 'create endpoint specifications', or 'list required fields and types'. | 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 terms 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 developers would use. | 3 / 3 |
Distinctiveness Conflict Risk | Somewhat specific to frontend-backend communication, but could overlap with general API documentation skills or backend development skills. The focus on 'data needs' helps but isn't 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 skill with strong actionability and clear workflow guidance. The output template is concrete and immediately usable, and the good/bad examples effectively illustrate the desired behavior. Main weaknesses are moderate verbosity and keeping all content inline rather than using progressive disclosure for the detailed template and examples.
Suggestions
Trim redundant explanations—the 'Good vs. Bad Requests' section largely repeats the 'What You Own vs. What Backend Owns' table concepts
Consider extracting the full output template to a separate TEMPLATE.md file and referencing it, keeping only a brief example in 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 rules are well-structured but the overall document could be 20-30% shorter. | 2 / 3 |
Actionability | Provides concrete, copy-paste ready output format with a complete markdown template. The workflow steps are specific, the good/bad examples are concrete and illustrative, and the rules section gives clear directives Claude can follow immediately. | 3 / 3 |
Workflow Clarity | Clear 4-step workflow with explicit sequence (Describe → List → Surface Uncertainties → Leave Room). Includes a feedback loop via 'After Backend Responds' section for updating the document. Each step has clear sub-items explaining what to do. | 3 / 3 |
Progressive Disclosure | Content is well-organized with clear sections and headers, but it's a monolithic document that could benefit from splitting—the output template and examples could be separate reference files. For a skill of this length (~150 lines), some content is inline that could be referenced. | 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.
- 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.