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.
npxskills add davila7/claude-code-templates--skill frontend-to-backend-requirementsLoading…
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.
Create or update AgentSkills. Use when designing, structuring, or packaging skills with scripts, references, and assets.
Create or update AgentSkills. Use when designing, structuring, or packaging skills with scripts, references, and assets.
Set up and use 1Password CLI (op). Use when installing the CLI, enabling desktop app integration, signing in (single or multi-account), or reading/injecting/running secrets via op.
CLI to manage emails via IMAP/SMTP. Use `himalaya` to list, read, write, reply, forward, search, and organize emails from the terminal. Supports multiple accounts and message composition with MML (MIME Meta Language).
Create or update AgentSkills. Use when designing, structuring, or packaging skills with scripts, references, and assets.
Create or update AgentSkills. Use when designing, structuring, or packaging skills with scripts, references, and assets.
Set up and use 1Password CLI (op). Use when installing the CLI, enabling desktop app integration, signing in (single or multi-account), or reading/injecting/running secrets via op.
CLI to manage emails via IMAP/SMTP. Use `himalaya` to list, read, write, reply, forward, search, and organize emails from the terminal. Supports multiple accounts and message composition with MML (MIME Meta Language).