frontend-to-backend-requirements_skill

Overview

This skill helps frontend developers clearly document the data and UI needs they expect from backend teams. It produces structured backend-requirements notes that describe what the UI needs to render, what actions users can take, and which states and business rules the frontend must handle. The goal is to request data and clarifications without prescribing implementation details.

How this skill works

You describe a feature, its users, and the success criteria. The skill converts that into a focused requirements document listing display data, user actions, UI states, uncertainties, and questions for backend. It deliberately avoids endpoint, field, or schema prescriptions so backend can own implementation choices.

When to use it

• When you need to tell backend what data is required to render a screen or component.
• When a designer or PM describes a UI and you must translate it into backend needs.
• When preparing an API contract discussion without deciding endpoint design or field names.
• When revealing business rules that affect visibility, permissions, or validation.
• When you want to surface edge cases and open questions for backend to clarify.

Best practices

• Start with context: what the feature is, who uses it, and what success looks like.
• Describe data in terms of intent and relationships, not field names or types.
• List explicit UI states (loading, empty, error, partial, success) and examples that trigger them.
• Surface uncertainties and invite backend pushback or alternative approaches.
• Keep the doc collaborative: record backend responses and update requirements accordingly.

Example use cases

• Documenting a dashboard widget: what items appear, sort/filter needs, and when it shows empty state.
• Specifying a form: which values the UI needs for previews, validation expectations, and success feedback.
• Describing an item detail page: what related entities must be shown and which actions should be enabled by permission.
• Requesting data for a list with client-side filtering and pagination hints without mandating API structure.
• Preparing a ticket for API design review that focuses on UI outcomes and open questions.