agentsclimarketplace
Sign in

Fec backend requirements handoff

Skill bovinphang/frontend-craft/skills/fec-backend-requirements-handoff

Use when frontend work needs to communicate data, action, state, permission, validation, or business-rule needs to backend teams without dictating endpoint design, field names, database shape, or implementation details; Chinese triggers include front-end and back-end requirements handover, back-end requirements, API requirements clarification, data requirements description.From its SKILL.md

Install
npx -y skills add bovinphang/frontend-craft --skill fec-backend-requirements-handoff

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 21 stars21 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

3.4 KB, 580 tokens by cl100k_base, as published. Nobody here has run it

Handover of front-end and back-end requirements

Purpose

Organize the data, actions, status, and questions required for front-end pages and interactions into discussion-ready requirements for the back-end.

Procedure

  1. Clarify the functional context
  • Describe what the page, process, or component is, what type of user it is intended for, and the success status of the user completing the task.
    • If there are existing designs, routes, user stories, or permission roles, use them as sources of truth first.

  1. Describe front-end display requirements

    • List information to be displayed by screen or component, relationships between information, sorting/filtering/pagination requirements and visibility rules.
    • Use business language to describe "what needs to be displayed" and do not specify endpoints, field names, DTOs, database tables or response nested structures in advance.

  2. Describe user actions and results

    • List the actions the user can perform, expected results, success feedback, failure feedback and whether optimistic updates are needed.
    • Mark behaviors that affect the UI such as idempotence, undo, confirm, dangerous operations, batch operations, or long task progress.

  3. Complete status and business rules

    • Override the status of loading, empty, error, partial, permission denied, expired, conflict, offline and retrying.
    • Document permissions, lifecycle, amounts/timezones/enumerations, validations, editable conditions, and boundary rules that affect the UI.

  4. Output discussion document

    • By default, it is written to docs/backend-requirements/<feature-name>.md; if the warehouse already has a requirements document directory, the existing location will be used.
    • Documentation includes Context, Screens/Components, Data Needs, User Actions, UI States, Business Rules, Uncertainties, Questions for Backend and Decision Log.
    • If the user only needs chat replies, they can directly output Markdown with the same structure without creating a file.

Constraints

  • Does not specify URLs, HTTP methods, field names, database schema, cache implementation, or service splitting for the backend.
  • Don't write front-end guesses into facts; uncertain business rules must go into Uncertainties or Questions.
  • Errors, empty states, permissions and partial data are not ignored; these states determine the quality of interface collaboration.
  • Do not expose internal error stacks, database fields, or sensitive implementation details to the UI.
  • Does not duplicate the API integration process: This skill describes the requirements, client boundaries, type sources and error mapping implementation should be handled in subsequent implementation phases.

Expected Output

Produce a back-end requirements handover description from a front-end perspective, clearly describing what data and behaviors the UI requires, which rules still need to be confirmed, and subsequent issues that need to be decided jointly by the front-end and back-end.

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Gives 0 of the 12 instructions most design frontend skills give in 580 tokens

Counted across 1,179 of the 2,086 authors here whose files we hold, read 2026-09-06

  • Commit to a bold aesthetic directionin 31 of 1179, across 24 files
  • Prefer component composition over inheritancein 28 of 1179, across 14 files
  • Animate only transform and opacity propertiesin 27 of 1179, across 22 files
  • Memoize expensive computations with useMemoin 26 of 1179, across 13 files
  • Use semantic HTML elementsin 24 of 1179, across 23 files
  • Virtualize long lists for performancein 21 of 1179, across 10 files
  • Use CSS variables for design tokensin 20 of 1179, across 14 files
  • Implement loading, empty, and error statesin 20 of 1179
  • Lazy load heavy components with Suspensein 19 of 1179, across 8 files
  • Respect prefers-reduced-motion media queriesin 18 of 1179, across 10 files
  • Prioritize CSS-only animations for HTMLin 18 of 1179, across 16 files
  • Use compound components for related UI elementsin 18 of 1179, across 7 files

Said here and by no other author read

  • Clarify the functional context of the feature
  • Describe information display requirements using business language
  • Document status and business rules
  • Include uncertainties and questions for the backend
  • Create a discussion document for the requirements

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 325,949. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.