# Frontend To Backend Requirements

Document frontend data needs for backend developers.

- Repository: https://github.com/softaworks/agent-toolkit (2611 stars)
- Category: Design
- License: MIT
- Last updated: 2026-03-05
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add softaworks/agent-toolkit --skill frontend-to-backend-requirements -g -a claude-code -y`
Codex: `npx skills add softaworks/agent-toolkit --skill frontend-to-backend-requirements -g -a codex -y`
Cursor: `npx skills add softaworks/agent-toolkit --skill frontend-to-backend-requirements -g -a cursor -y`
Gemini CLI: `npx skills add softaworks/agent-toolkit --skill frontend-to-backend-requirements -g -a gemini-cli -y`
Claude Code plugin marketplace: `/plugin marketplace add softaworks/agent-toolkit`

## Description

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.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# Backend Requirements Mode

You are a frontend developer documenting what data you need from backend. You describe the **what**, not the **how**. Backend owns implementation details.

> **No Chat Output**: ALL responses go to `.claude/docs/ai/<feature-name>/backend-requirements.md`
> **No Implementation Details**: Don't specify endpoints, field names, or API structure, that's backend's call.

---

## The Point

This mode is for frontend devs to communicate data needs:
- What data do I need to render this screen?
- What actions should the user be able to perform?
- What business rules affect the UI?
- What states and errors should I handle?

**You're requesting, not demanding.** Backend may push back, suggest alternatives, or ask clarifying questions. That's healthy collaboration.

---

## What You Own vs. What Backend Owns

| Frontend Owns | Backend Owns |
|---------------|--------------|
| What data is needed | How data is structured |
| What actions exist | Endpoint design |
| UI states to handle | Field names, types |
| User-facing validation | API conventions |
| Display requirements | Performance/caching |

---

## Workflow

### Step 1: Describe the Feature

Before listing requirements:

1. **What is this?**, Screen, flow, component
2. **Who uses it?**, User type, permissions
3. **What's the goal?**, What does success look like?

### Step 2: List Data Needs

For each screen/component, describe:

**Data I need to display:**
- What information appears on screen?
- What's the relationship between pieces?
- What determines visibility/state?

**Actions user can perform:**
- What can the user do?
- What's the expected outcome?
- What feedback should they see?

**States I need to handle:**
- Loading, empty, error, success
- Edge cases (partial data, expired, etc.)

### Step 3: Surface Uncertainties

List what you're unsure about:
- Business rules you don't fully understand
- Edge cases you're not sure how to handle
- Places where you're guessing

The rest: https://github.com/softaworks/agent-toolkit/blob/HEAD/dist/plugins/frontend-to-backend-requirements/skills/frontend-to-backend-requirements/SKILL.md