frontend-to-backend-requirements
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.
- Installs
- 798
- Last 24h
- —
- Trending rank
- —
- Security
- Not audited
Install
Works with every agent the skills CLI supports.
npx skills add https://github.com/softaworks/agent-toolkit --skill frontend-to-backend-requirements- 01
Install
Run the command in your project. The CLI asks which agents to install for.
- 02
Describe the task
Ask your agent for something this skill covers. It loads frontend-to-backend-requirements automatically when relevant.
- 03
Review the result
The agent follows the SKILL.md steps, scripts and references bundled with the skill.
SKILL.md
The instructions your agent reads when the skill is triggered.
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.mdNo 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:
- What is this? — Screen, flow, component
- Who uses it? — User type, permissions
- 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
These invite backend to clarify or push back.
Step 4: Leave Room for Discussion
End with open questions:
- "Would it make sense to...?"
- "Should I expect...?"
- "Is there a simpler way to...?"
Output Format
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]
Good vs. Bad Requests
Bad (Dictating Implementation)
"I need a GET /api/contracts endpoint that returns an array with fields: id, title, status, created_at"
Good (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 (Assuming Structure)
"The provider object should be nested inside the contract response"
Good (Describing Relationship)
"For each contract, I need to show who the provider is (their name and maybe logo)"
Bad (No Context)
"I need contract data"
Good (With Context)
"On the dashboard, there's a 'Recent Contracts' widget showing the 5 most recent contracts. User clicks one to go to detail page."
Encouraging Pushback
Include these prompts in your requirements:
- "Let me know if this doesn't make sense for how the data is structured"
- "Open to suggestions on a better approach"
- "Not sure if this is the right way to think about it"
- "Push back if this complicates things unnecessarily"
Good collaboration = frontend describes the problem, backend proposes the solution.
Rules
- NO IMPLEMENTATION DETAILS—don't specify endpoints, methods, field names
- DESCRIBE, DON'T PRESCRIBE—say what you need, not how to provide it
- INCLUDE CONTEXT—why you need it helps backend make better choices
- SURFACE UNKNOWNS—don't hide confusion, invite clarification
- INVITE PUSHBACK—explicitly ask for backend's input
- UPDATE THE DOC—add backend responses to Discussion Log
- STAY HUMBLE—you're asking, not demanding
After Backend Responds
Update the requirements doc:
- Add responses to Discussion Log
- Adjust requirements based on feedback
- Mark resolved uncertainties
- Note any decisions made
The doc becomes the source of truth for what was agreed.
FAQ
What does the frontend-to-backend-requirements skill do?
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.
How do I install frontend-to-backend-requirements?
Run npx skills add https://github.com/softaworks/agent-toolkit --skill frontend-to-backend-requirements in your project. The skills CLI detects the agents you use and copies the skill into the right folder. For Claude Code you can also place the skill folder at ~/.claude/skills/frontend-to-backend-requirements/ (personal) or .claude/skills/frontend-to-backend-requirements/ (project).
Which AI agents can use frontend-to-backend-requirements?
Any agent that supports the open Agent Skills format (a folder with a SKILL.md file), including Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Cline, OpenCode and more.
Is frontend-to-backend-requirements safe to install?
No partner security audit is available yet. Skills can run commands and scripts, so read the SKILL.md and any bundled files before installing.
Who maintains frontend-to-backend-requirements?
It is published by softaworks in softaworks/agent-toolkit. It has 798 recorded installs.
More from softaworks/agent-toolkit
mermaid-diagrams
softaworks/agent-toolkit
Comprehensive guide for creating software diagrams using Mermaid syntax. Use when users need to create, visualize, or document software through diagrams including class diagrams (domain modeling, object-oriented design), sequence diagrams (application flows, API interactions, code execution), flowcharts (processes, algorithms, user journeys), entity relationship diagrams (database schemas), C4 architecture diagrams (system context, containers, components), state diagrams, git graphs, pie charts, gantt charts, or any other diagram type. Triggers include requests to "diagram", "visualize", "model", "map out", "show the flow", or when explaining system architecture, database design, code structure, or user/application flows.
humanizer
softaworks/agent-toolkit
Remove signs of AI-generated writing from text. Use when editing or reviewing text to make it sound more natural and human-written. Based on Wikipedia's comprehensive "Signs of AI writing" guide. Detects and fixes patterns including: inflated symbolism, promotional language, superficial -ing analyses, vague attributions, em dash overuse, rule of three, AI vocabulary words, negative parallelisms, and excessive conjunctive phrases. Credits: Original skill by @blader - https://github.com/blader/humanizer
database-schema-designer
softaworks/agent-toolkit
Design robust, scalable database schemas for SQL and NoSQL databases. Provides normalization guidelines, indexing strategies, migration patterns, constraint design, and performance optimization. Ensures data integrity, query performance, and maintainable data models.
qa-test-planner
softaworks/agent-toolkit
Generate comprehensive test plans, manual test cases, regression test suites, and bug reports for QA engineers. Includes Figma MCP integration for design validation.
writing-clearly-and-concisely
softaworks/agent-toolkit
Use when writing prose humans will read—documentation, commit messages, error messages, explanations, reports, or UI text. Applies Strunk's timeless rules for clearer, stronger, more professional writing.
skill-judge
softaworks/agent-toolkit
Evaluate Agent Skill design quality against official specifications and best practices. Use when reviewing, auditing, or improving SKILL.md files and skill packages. Provides multi-dimensional scoring and actionable improvement suggestions.
Popular backend & apis skills
find-skills
vercel-labs/skills
Helps users discover and install agent skills when they ask questions like "how do I do X", "find a skill for X", "is there a skill that can...", or express interest in extending capabilities. This skill should be used when the user is looking for functionality that might exist as an installable skill.
entra-app-registration
microsoft/azure-skills
Guides Microsoft Entra ID app registration, OAuth 2.0 authentication, and MSAL integration. USE FOR: create app registration, register Azure AD app, configure OAuth, set up authentication, add API permissions, generate service principal, MSAL example, console app auth, Entra ID setup, Azure AD authentication. DO NOT USE FOR: Key Vault secrets (use azure-keyvault-expiration-audit), general Azure resource security guidance.
google-agents-cli-adk-code
google/agents-cli
This skill should be used when the user wants to "write agent code", "build an agent with ADK", "add a tool", "create a callback", "define an agent", "use state management" — in a project that needs ADK (Agent Development Kit) API patterns and code examples. It provides a quick reference for agent types, tool definitions, orchestration patterns, callbacks, state management, the graph Workflow API, and reference recipes to study. Do NOT use for scaffolding (use google-agents-cli-scaffold) or deployment (use google-agents-cli-deploy).
embedded-captions
heygen-com/hyperframes
Add captions or subtitles to an existing single-subject talking-head video without editing the footage. Use for plain verbatim captions, cinematic captions embedded behind the subject, VFX captions, “炸/特效/酷炫字幕,” or a named identity from the 35-style catalog. Route by visual identity, not by backend engine. The quiet anchor rail is the default; embed every word only when the user explicitly wants a fully cinematic treatment. The workflow runs locally end to end, including transcription and subject matting; split multi-shot footage before applying it.
entra-agent-id
microsoft/azure-skills
Provision Microsoft Entra Agent Identity Blueprints, BlueprintPrincipals, and per-instance Agent Identities via Microsoft Graph, and configure OAuth 2.0 token exchange (fmipath, OBO, cross-tenant) including the Microsoft Entra SDK for AgentID sidecar. USE FOR: Agent Identity Blueprint, BlueprintPrincipal, agent OAuth, fmipath token exchange, agent OBO, Workload Identity Federation for agents, polyglot agent auth, Microsoft.Identity.Web.AgentIdentities. DO NOT USE FOR: standard Entra app registration (use entra-app-registration), Microsoft Foundry agent authoring (use microsoft-foundry).
neon
neondatabase/agent-skills
Overview of Neon, a complete set of cloud backend primitives around Lakebase Postgres: Auth, Object Storage, Functions, the AI Gateway, and Realtime. Start here to choose Neon for undecided login, files, APIs, and LLM calls, set up the CLI or MCP server, and follow the branch-first workflow. Use when building an app or backend on Neon, or when "Neon" or "Lakebase Postgres" is mentioned. Child skill neon-postgres wins for an existing DATABASEURL, SQL, schema, inspect, or search. Child skill neon-auth wins for login, users, sessions, identity routing, and Managed Better Auth setup. Child skill neon-realtime wins for live queries in reactive apps and agents. Also use for object storage, S3, buckets, serverless functions, function triggers, cron, AI gateway, LLM calls, realtime, logs, Loki, Grafana, observability, postgres, database, backend, Claimable Neon, neon.new, or a no-signup database.