Frontend to Backend Engine

A structured skill for frontend developers to document backend data requirements — covering API contract definitions, data shape specifications, feature requirement documents, and frontend-backend handoff workflows without dictating implementation details.

When to Use This Skill

Choose Frontend to Backend Engine when you need to:

• Document what data the frontend needs from the backend
• Create structured requirement files for backend teams
• Define data shapes, relationships, and constraints for new features
• Bridge the communication gap between frontend and backend developers
• Generate API requirement documents from UI mockups or user stories

Consider alternatives when:

• You need to design REST or GraphQL APIs (use an API design skill)
• You're implementing backend endpoints (use a backend development skill)
• You need database schema design (use a database modeling skill)

Quick Start

Copy
# Generate backend requirements for a feature
claude "Document the backend data requirements for a user profile page that shows user info, recent activity, and subscription status. Output to .claude/docs/ai/user-profile/backend-requirements.md"

Copy
# Backend Requirements: User Profile Page

## Data Requirements

### User Info
I need:
- Display name (string, max 100 chars)
- Email (string, validated format)
- Avatar URL (string, nullable)
- Account created date (ISO 8601)
- Last login timestamp (ISO 8601)

### Recent Activity (last 30 days)
I need a list of activities, each containing:
- Activity type (enum: "login", "purchase", "comment", "upload")
- Timestamp (ISO 8601)
- Description (string, max 200 chars)
- Related resource ID (string, nullable)

Sorting: newest first
Limit: 20 items maximum
Pagination: cursor-based preferred

### Subscription Status
I need:
- Plan name (string: "free", "pro", "enterprise")
- Status (enum: "active", "past_due", "canceled", "trialing")
- Current period end date (ISO 8601)
- Cancel at period end (boolean)
- Features list (array of strings)

## Constraints
- All timestamps in UTC
- Null fields should be omitted, not sent as null
- Activity list must be pre-sorted (frontend won't re-sort)

Core Concepts

Requirement Document Structure

Section	Purpose	Contains
Data Requirements	What fields the frontend needs	Field names, types, formats
Relationships	How data entities relate	Parent-child, references
Constraints	Rules and limitations	Sorting, limits, formats
States	Possible data states	Enums, nullable, defaults
Timing	When data is needed	Load priority, lazy loading

Data Shape Specification

Copy
## Specifying What You Need (Not How)

### ✅ Good (Describes the "what")
"I need a list of the user's 5 most recent orders,
each with: order ID, total amount, status, and
item count."

### ❌ Bad (Dictates implementation)
"Create a GET /api/orders endpoint that JOINs the
orders table with order_items and returns JSON
with a 200 status code."

### The Rule
Frontend describes:
- What data is needed
- What shape it should be in
- What constraints apply (sorting, filtering, limits)

Backend decides:
- API structure (REST, GraphQL, RPC)
- Database queries and joins
- Caching strategy
- Authentication/authorization implementation

Feature Handoff Template

Copy
## Feature: [Feature Name]

### User Story
As a [role], I want [capability] so that [benefit].

### Screens/Components That Need Data
1. **[Component Name]**
   - Data: [list fields]
   - Refresh: [on load / real-time / user action]
   - Error state: [what to show if data unavailable]

2. **[Component Name]**
   - Data: [list fields]
   - Refresh: [frequency]
   - Error state: [fallback behavior]

### Write Operations
1. **[Action Name]**
   - Sends: [field list with types]
   - Expects back: [success response shape]
   - Optimistic update: [yes/no]

### Edge Cases
- What if the list is empty?
- What if the user has no subscription?
- What if an activity references a deleted resource?

Configuration

Parameter	Description	Example
feature_name	Feature being documented	"user-profile"
output_path	Where to save requirement docs	".claude/docs/ai/{feature}/"
format	Output format for requirements	"markdown"
include_states	Document all possible data states	true
include_errors	Document error scenarios	true

Best Practices

1. Describe data by its purpose, not its source — Say "I need the user's display name" not "I need the name column from the users table." The frontend shouldn't know or care about backend data structures. This keeps the contract clean when the backend refactors.

2. Specify all possible states for every field — For each data field, document: What's the default? Can it be null? What happens if it's missing? Backend developers make different assumptions than frontend developers unless states are explicit.

3. Group requirements by screen or component — Organize your requirements around where data appears in the UI, not around backend entities. This makes it obvious what data loads together and helps the backend team design efficient data fetching.

4. Include error states and empty states — Every data request can fail or return nothing. Document what the frontend will show in both cases, so the backend team knows which error responses matter and which empty-state fields need specific values.

5. Version your requirement documents — As features evolve, requirements change. Add a version number and changelog to each requirement doc so both teams can track what changed, when, and why.

Common Issues

Requirements are too vague for backend to implement — "I need user data" forces the backend team to guess which fields you actually render. Be explicit about every field, its type, and its format. A well-specified requirement doc should let a backend developer build the API without asking follow-up questions.

Frontend and backend disagree on data shapes — The frontend expects { user: { name, email } } but the backend sends { userName, userEmail }. Create a shared contract document that both teams review before implementation begins. Disagreements caught in a document review are free; disagreements caught during integration cost days.

Requirements drift during development — The frontend adds a "last seen" badge after requirements were finalized, but never updates the requirement doc. Treat requirement documents as living artifacts — update them when scope changes, and notify the backend team of additions.