Loading
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',
The skill file stays in the publisher's repository.
Paste the copied command in a terminal. It installs this SKILL.md into that agent.
npx skills add softaworks/agent-toolkit --skill frontend-to-backend-requirements -a cursor -y
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.
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.
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.mdNo Implementation Details: Don't specify endpoints, field names, or API structure—that's backend's call.
This mode is for frontend devs to communicate data needs:
You're requesting, not demanding. Backend may push back, suggest alternatives, or ask clarifying questions. That's healthy collaboration.
| 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 |
Before listing requirements:
For each screen/component, describe:
Data I need to display:
Actions user can perform:
States I need to handle:
List what you're unsure about:
These invite backend to clarify or push back.
End with open questions:
Create .claude/docs/ai/<feature-name>/backend-requirements.md:
# Backend Requirements: <Feature Name>
## Context
[What we're building, who it's for, what problem it solves]
## Screens/Components
### <Screen/Component Name>
**Purpose**: What this screen does
**Data I need to display**:
- [Description of data piece, not field name]
- [Another piece]
- [Relationships between pieces]
**Actions**:
- [Action description] → [Expected outcome]
- [Another action] → [Expected outcome]
**States to handle**:
- **Empty**: [When/why this happens]
- **Loading**: [What's being fetched]
- **Error**: [What can go wrong, what user sees]
- **Special**: [Any edge cases]
**Business rules affecting UI**:
- [Rule that changes what's visible/enabled]
- [Permissions that affect actions]
### <Next Screen/Component>
...
## Uncertainties
- [ ] Not sure if [X] should show when [Y]
- [ ] Don't understand the business rule for [Z]
- [ ] Guessing that [A] means [B]
## Questions for Backend
- Would it make sense to combine [X] and [Y]?
- Should I expect [Z] to always be present?
- Is there existing data I can reuse for [W]?
## Discussion Log
[Backend responses, decisions made, changes to requirements]
"I need a GET /api/contracts endpoint that returns an array with fields: id, title, status, created_at"
"I need to show a list of contracts. Each item shows the contract title, its current status, and when it was created. User should be able to filter by status."
"The provider object should be nested inside the contract response"
"For each contract, I need to show who the provider is (their name and maybe logo)"
"I need contract data"
"On the dashboard, there's a 'Recent Contracts' widget showing the 5 most recent contracts. User clicks one to go to detail page."
Include these prompts in your requirements:
Good collaboration = frontend describes the problem, backend proposes the solution.
Update the requirements doc:
The doc becomes the source of truth for what was agreed.