Frontend To Backend Requirements
Produce a collaborative API and data-needs brief from the UI side so backend can implement without frontend dictating schema names.
Overview
Frontend-to-backend-requirements is an agent skill most often used in Validate (also Build frontend and pm) that structures UI data and action needs for backend partners without prescribing implementation.
Install
npx skills add https://github.com/softaworks/agent-toolkit --skill frontend-to-backend-requirementsWhat is this skill?
- Five-part structure: feature description, data needs, user actions, UI states, uncertainties
- Non-prescriptive: describes what to display and do without mandating field names or DB design
- Surfaces loading, empty, error, and edge cases backend must support
- Triggered by phrases like backend requirements, API requirements, what data do I need
- Collaborative handoff document for frontend–backend splits on solo or small teams
- Five documentation sections: feature, data needs, actions, states, uncertainties
Adoption & trust: 506 installs on skills.sh; 2k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You know what the screen should do but struggle to tell backend what data and behaviors you need without over-specifying APIs or field names.
Who is it for?
Frontend-leaning solo builders scoping a new screen or feature before pairing on API design.
Skip if: Backend-only refactors with no UI change, or when an OpenAPI spec is already signed off and frozen.
When should I use this skill?
User needs backend/API requirements from a frontend perspective, plans a feature needing server support, or says backend requirements, API requirements, or what data do I need.
What do I get? / Deliverables
You get a structured requirements document covering data needs, actions, states, and open questions ready for backend design or ticket breakdown.
- Structured frontend-to-backend requirements document
- List of uncertainties and assumptions for backend clarification
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Scoping what the product must fetch and mutate belongs in Validate before full build commits both teams to the wrong contract. Scope subphase is where you nail feature boundaries, data surfaces, and actions—not implementation—in a shared artifact.
Where it fits
Before building a dashboard, list metrics and filters the UI must show so API scope stays honest.
While implementing a checkout step, document payment and error states backend must return.
Turn a Figma flow into action-outcome bullets for a solo builder’s later backend sprint.
How it compares
Requirements facilitator—not an OpenAPI generator or automatic CRUD scaffolder.
Common Questions / FAQ
Who is frontend-to-backend-requirements for?
Frontend developers and solo builders who need to hand backend a clear, respectful brief about UI data and actions without dictating database or endpoint design.
When should I use frontend-to-backend-requirements?
Use it in Validate when scoping a feature that needs server support, and in Build when planning frontend work that requires new APIs; also when you say backend requirements, API requirements, or what data do I need for this component.
Is frontend-to-backend-requirements safe to install?
It is documentation-oriented; still review the Security Audits panel on this page before enabling any agent toolkit in production repos.
SKILL.md
READMESKILL.md - Frontend To Backend Requirements
# Frontend to Backend Requirements A Claude Code skill for frontend developers to document data needs and API requirements for backend developers in a collaborative, non-prescriptive way. ## Purpose This skill helps frontend developers communicate **what data they need** without dictating **how backend should implement it**. It creates a structured requirements document that describes UI needs, user actions, states to handle, and business rules—leaving implementation details to the backend team. ## When to Use This Skill Use this skill when: - You need to communicate API requirements from frontend to backend - You're planning a new feature that requires backend support - You want to document what data your UI needs to display - You're describing user actions that require backend operations - The user says phrases like: - "backend requirements" - "what data do I need" - "API requirements" - "what should the backend provide" - Describing data needs for a UI component ## How It Works The skill guides you through documenting your requirements in a structured format that: 1. **Describes the feature** - What screen/component you're building and its purpose 2. **Lists data needs** - What information needs to be displayed (without specifying field names) 3. **Identifies actions** - What users can do and expected outcomes 4. **Defines states** - Loading, empty, error, and edge cases to handle 5. **Surfaces uncertainties** - Questions and assumptions that need clarification 6. **Invites collaboration** - Opens discussion for backend input and pushback All output goes to `.claude/docs/ai/<feature-name>/backend-requirements.md` - no chat output. ## Key Features ### Frontend Owns - What data is needed - What actions exist - UI states to handle - User-facing validation - Display requirements ### Backend Owns - How data is structured - Endpoint design - Field names and types - API conventions - Performance and caching strategies ### Collaboration Principles - **Describe, don't prescribe** - Say what you need, not how to provide it - **Include context** - Why you need it helps backend make better decisions - **Surface unknowns** - Don't hide confusion, invite clarification - **Invite pushback** - Explicitly ask for backend's input - **Stay humble** - You're requesting, not demanding ## Output Format The skill creates a markdown document with this structure: ```markdown # 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] - [Relationships between pieces] **Actions**: - [Action description] → [Expected outcome] **States to handle**: - **Empty**: [When/why this happens] - **Loading**: [What's being fetched] - **Error**: [What can go wrong, what user sees] **Business rules affecting UI**: - [Rule that changes what's visible/enabled] ## Uncertainties - [ ] Not sure if [X] should show when [Y] ## Questions for Backend - Would it make sense to combine [X] and [Y]? ## Discussion Log [Backend responses, decisions made, changes to requirements] ``` ## Usage Examples ### Good Request (Describing Needs) > "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." ### Bad Request (Dictating Implementation) > "I need a GET /api/contracts endpoint that returns an array with fields: id, title, status, created_at" ### Good Request (Describing Relationship) > "For each contract, I need to show who the provider is (their name and maybe logo)" ### Bad Request (Assuming Structure) > "The provider object should be nested inside the contract response" ## Workflow 1. **Describe the feature** - What is it, who uses it, what's the goal 2. **List data needs** - Information to display, actions to perform, states to h