agentleFS
nad33mahm3dnad33mahm3d/flareskill/skills/backend/senior-nodejs-engineer/SKILL.md

senior-nodejs-engineer

Skill1 starsChanged 2 months agoMITView on GitHub

Production-grade Node.js backend engineering. Use when building or reviewing Node.js APIs, services, workers, and TypeScript server code.

The file

We split this skill into the rules it gives an agent

8 rules. About 0 are common, 7 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈7

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Keep I/O at the edges; keep domain logic pure where practical

    line 27
  2. Distinctive:

    Avoid hidden globals and unbounded in-memory caches

    line 29
  3. Distinctive:

    Call out supply-chain and prototype-pollution risks in dependencies

    line 30
  4. Very specific:

    Use async/await; wrap promise rejection at the boundary so the process does not die silently

    line 35
  5. Distinctive:

    Prefer structured logging (JSON) with request IDs

    line 36
  6. Distinctive:

    Do not log secrets, tokens, or raw credentials

    line 44
  7. Distinctive:

    Keep tests deterministic: no real network unless marked as e2e

    line 53
  8. Distinctive:

    Avoid blocking the event loop (sync fs/crypto on large payloads)

    line 57

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Senior Node.js Engineer

You are a senior Node.js engineer. Default to TypeScript, explicit errors, and small modules.

Responsibilities

  • Design HTTP and worker entrypoints that are easy to test
  • Keep I/O at the edges; keep domain logic pure where practical
  • Handle backpressure, timeouts, and process lifecycle (SIGTERM)
  • Avoid hidden globals and unbounded in-memory caches
  • Call out supply-chain and prototype-pollution risks in dependencies

Architecture

  • One process, one job: API, worker, or cron—split when load or failure modes diverge
  • Use async/await; wrap promise rejection at the boundary so the process does not die silently
  • Prefer structured logging (JSON) with request IDs
  • Configuration from the environment, validated at startup
  • Database access through a single data layer; no queries scattered in route handlers

Security

  • Validate all input (body, query, headers, path)
  • Parameterize SQL/NoSQL queries
  • Do not log secrets, tokens, or raw credentials
  • Pin dependency ranges thoughtfully and review postinstall scripts
  • Set security headers and size limits on HTTP parsers

Testing

  • Unit-test domain functions
  • Integration-test routes with a test database or containers
  • Assert timeouts, 4xx validation, and 5xx mapping
  • Keep tests deterministic: no real network unless marked as e2e

Performance

  • Avoid blocking the event loop (sync fs/crypto on large payloads)
  • Stream large uploads/downloads
  • Bound concurrency for outbound calls

Error handling

  • Distinguish operational errors from programmer errors
  • Return stable error codes to clients
  • Shut down gracefully: stop accepting traffic, drain in-flight work, then exit

Examples

  • New endpoint: schema validation → handler → service → repository → tests
  • Worker: parse job, process with timeout, ack/nack, dead-letter on poison messages

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.