agentsclimarketplace
Sign in

Backend basics

Skill protosphinx/sphinxstack/skills/backend-basics

Build and deploy their first small server. Covers a few real endpoints, frontend requests, current host limits, server-side secrets, and failure handling. Use when a frontend needs a hidden key, when they ask "what is a backend", or when localStorage stops being enough.From its SKILL.md

Install
npx -y skills add protosphinx/sphinxstack --skill backend-basics

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

2 things to look at

  • 12 days oldThe repository was created 12 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
  • 1 stars1 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.0 KB, 624 tokens by cl100k_base, as published. Nobody here has run it

backend-basics

Build someone's first backend: a small API they wrote, deployed on a current no-card plan, answering requests from their own frontend. The point is to make "server" concrete. Code that runs on a machine that is always on, holds secrets the browser can't see, and answers HTTP requests.

Ground rules

  • The backend must serve a real need from their existing project: hiding an API key, sharing data between visitors, or doing work the browser can't. If nothing exists yet, run build-web-app first, or build the frontend and backend as one small pair.
  • Compare current official plan and runtime documentation before choosing a host. Serverless functions or a small Node server are both reasonable. Record the limits and what happens at the edge of them, including request caps, sleeping instances, and retention. No card details anywhere; if a supposedly free host demands a card, pick another host.
  • Their accounts, their keys. They sign up themselves; secrets go in the host's env-var settings and a local .env that is gitignored before it is created. git status proves it.
  • Two or three endpoints, no more. A backend that does one job completely beats a scaffold with ten empty routes.
  • They run every deploy and every curl. You narrate what each command does in one line first.

The path

  1. Say the shape out loud together: browser calls your API, your API does the private work, JSON comes back. Draw it as three boxes if that helps. Then pick the two endpoints this project needs.
  2. Hello endpoint, locally: one route returning JSON. Hit it with curl and with the browser so both feel the same.
  3. Deploy that hello endpoint before writing anything else. Free tiers make this a ten-minute step; a live URL early keeps the rest honest.
  4. Real endpoints: the private fetch with the hidden key, or the shared read/write the project needs. Env vars set in the host dashboard by them, mirrored in local .env.
  5. Wire the frontend to it with fetch. Handle CORS when it bites (it will) and explain in two sentences why the browser blocked the call.
  6. Unhappy paths: bad input gets a 400 with a message, a down upstream gets caught, and they test both with curl.

Done

  • A deployed API at a URL, written by them, with 2 to 3 endpoints
  • Their frontend calling it and rendering the result
  • Secrets only in host env vars and a gitignored .env; nothing secret in the repo or the browser dev tools
  • They can trace one request from click to response out loud

Then: database-basics when the API needs memory that survives a redeploy, or auth-basics when different users should see different things.

What ships with it: 1 file

217 B alongside SKILL.md

agents/

Gives 0 of the 12 instructions most data backend skills give in 624 tokens

Counted across 229 of the 229 authors here whose files we hold, read 2026-08-07

  • Separate business logic into service layersin 22 of 229, across 15 files
  • Retry failures with exponential backoffin 21 of 229, across 14 files
  • Select only needed database columnsin 20 of 229, across 13 files
  • Abstract data access into repository classesin 19 of 229, across 12 files
  • Use centralized error handlersin 17 of 229, across 10 files
  • Use AsNoTracking for read-only queriesin 16 of 229, across 4 files
  • Use async/await for all I/O operationsin 16 of 229, across 5 files
  • Implement structured loggingin 15 of 229, across 4 files
  • Use dependency injection for all servicesin 14 of 229, across 2 files
  • Use resource-based URLs for REST APIsin 13 of 229, across 7 files
  • Invalidate cache after data changesin 13 of 229, across 9 files
  • Use a dependency injection containerin 12 of 229, across 4 files

Said here and by no other author read

  • serve a real existing project need
  • compare current host plan documentation
  • record host limits and edge behaviour
  • let them sign up and run deploys
  • store secrets in env vars and gitignored dot env
  • verify gitignore excludes dot env

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 326,834. 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.