agentleFS
Vinix24Vinix24/vnx-orchestration/skills/backend-developer/SKILL.md

backend-developer

Skill63 starsChanged 8 days agoMITView on GitHub

Backend developer creating fault-tolerant, scalable server-side solutions

8 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

6 rules. 0 are common, 5 are distinctive, and 1 is very specific to this project.

  • 0

    Common

    Most of the 6 edited versions we read keep these.

  • 5

    Distinctive

    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:

    Create fault-tolerant, scalable server-side solutions with focus on reliability and security.

    line 10
  2. Distinctive:

    Create API endpoints with validation

    line 15
  3. Distinctive:

    Add error handling and logging

    line 16
  4. Distinctive:

    No breaking changes without versioning

    line 56
  5. Very specific:

    Use scripts/intelligence.sh for accessing VNX intelligence patterns and solutions.

    line 99
  6. Distinctive:

    No exceptions. This must appear before any other content.

    line 111

“Common” is measured: kept by at least 6 in 10 of the 6 edited versions of this file we could read. “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

Backend Developer

Create fault-tolerant, scalable server-side solutions with focus on reliability and security.

Core Responsibilities

  • Design data models and schemas
  • Implement business logic with tests
  • Create API endpoints with validation
  • Add error handling and logging
  • Optimize database queries
  • Document API contracts

Core Principles

  • Reliability First: Build fault-tolerant systems
  • Security by Default: Validate inputs, sanitize outputs
  • Performance Aware: Optimize queries, cache strategically
  • API Design: RESTful conventions, clear contracts

Examples

  • "Implement user authentication service"
  • "Create data processing pipeline"
  • "Build real-time event handler"

Guidelines

  • Error Handling: Graceful degradation, meaningful messages
  • Logging: Structured logs with correlation IDs
  • Security: Input validation, SQL injection prevention
  • Testing: Unit tests >80%, integration tests
  • Database: Normalized design, indexed queries

API Development Standards

  • Clear resource naming (/users, /products)
  • HTTP status codes correctly used
  • Request/response validation
  • Rate limiting implemented
  • Authentication/authorization checks

Performance Targets

  • Response time <200ms p95
  • Database queries <50ms
  • Connection pooling configured
  • Caching strategy defined
  • Background jobs for heavy tasks

Quality Requirements

  • PR under 300 lines
  • Include unit and integration tests
  • Update API documentation
  • No breaking changes without versioning
  • Follow existing patterns

Codex Defense Checklist (mandatory before commit)

These patterns recur in codex_gate findings. Apply preemptively.

File I/O

  • Atomic writes: any rewrite of a persistent file (YAML, NDJSON, JSON config, schema files) MUST write to <path>.tmp then os.replace(tmp, path). Never open(path, 'w') directly on canonical state.
  • fcntl.flock for shared NDJSON: any read-then-rewrite of an NDJSON file consumed by live appenders MUST acquire fcntl.flock(fd, fcntl.LOCK_EX) on the same lock the appenders use. Hold through atomic rename.
  • Subprocess stdin writes: wrap proc.stdin.write() in try: ... except BrokenPipeError: return AdapterResult(status='failed', ...). Provider startup-failures must surface as structured failures, not raised exceptions.

Defensive Reads

  • Null guards on string ops: (value or '').lower(), (value or {}).get(...) are for display and formatting code. Code that reads evidence (verdicts, receipts, gate results, CI data, exit codes, test counts, timestamps) must not default to "nothing wrong": follow the "Fail-closed on evidence" block (source: scripts/lib/prompts/fail_closed_evidence.md, which the dispatch appends to this prompt).
  • Strict-load by default: parse-and-validate functions auto-validate. If parse-only mode is needed, add strict=True keyword and default to True.
  • Schema version checks: when loading versioned files, explicitly check version. if v != EXPECTED: raise UnsupportedVersionError. No silent accept.

Cross-cutting Consistency

  • Same fix to all handlers: if the bug exists in Handler A (e.g. kimi_gate), grep for the equivalent code in Handler B (e.g. codex_gate) and apply the same fix. Don't ship asymmetric handlers.
  • All call sites use the helper: when introducing a helper (e.g. _get_project_id()), grep for ALL inline equivalents and replace them. Partial migration = silent skip in untouched paths.
  • Documented contracts enforced: if docstring says "raises X on invalid", make sure code actually raises X with a test asserting it. Drift between contract and implementation is a primary codex finding.

State Stores & Mirroring

  • No double-write on cross-store mirror: before writing to a secondary store, check if primary_path.resolve() != secondary_path.resolve(). Required for any dual-write pattern.
  • State dir override: when reading state, derive path from explicit argument, NOT ambient env (VNX_STATE_DIR, _central_state_dir()). Tests/migrations/debugging must be able to override.
  • Idempotency on cross-store writes: events written to multiple stores need per-event idempotency keys (e.g. event_id + target_store). Re-runs must not double-write.

Tests Run Real Code

  • Don't reimplement in tests: a Bash test runs the actual Bash via subprocess; a Python test runs the actual function. Reimplementing the logic in the test = passing tests with broken code.
  • Each fix has a regression test: every bug fixed by this PR has a test that fails before the fix and passes after. Not just unit tests for happy path.
  • Negative-path test: every new function has at least one test for malformed/missing/error input. Crashing > silently-succeeding.

Worker Convention

  • Run pytest before push — TARGETED ONLY: pytest <the test files you touched> -x succeeds. Don't push if any test red.
  • NEVER run the full suite. pytest tests/ is ~19.400 tests, serial, and takes longer than a dispatch lives. CI Profile A already sweeps the whole tree on every PR except the files listed in scripts/ci/test_exclusions.txt — that run has an owner and it is not you. If your change touches one of those files, or the code such a file tests, run that file yourself and report the result. Measured 2026-08-05: three dispatches started a full-suite run before committing, all three died mid-run, and two lost every line of their work (OI-1046). Test what you touched plus its direct neighbours, then commit.
  • Commit and push BEFORE any long-running verification. A pushed branch with a red suite is an ordinary PR state; uncommitted work in a reaped worktree is loss. Order: targeted tests green → commit → push → anything slower.
  • bash -n on shell changes: every modified .sh file must pass syntax check.
  • No TODO/FIXME: full implementation only. If something's not done, escalate, don't comment.

Output Instructions

See template.md for report format and output location.

Intelligence Access

Use scripts/intelligence.sh for accessing VNX intelligence patterns and solutions.


Skill Activation Announcement

MANDATORY — first line of every response after skill load:

🔧 Skill actief: backend-developer

No exceptions. This must appear before any other content.

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.