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
- mcabreradev/hermes-sdd-agencytheir own version, first seen Sep 17, 2026
- younss/skillstheir own version, first seen Sep 8, 2026
- jshsakura/awesome-opencode-skillstheir own version, first seen Jul 8, 2026
- BenjaminG/ai-skillstheir own version, first seen Jun 2, 2026
- boxclawai/skillstheir own version, first seen Mar 1, 2026
- marttp/my_agent_skills_I_usetheir own version, first seen Feb 19, 2026
Other versions8 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 8
- jshsakura/awesome-opencode-skills★ 30same name
- belokonm/claude-supercode-skills★ 11same name
- boxclawai/skills★ 9same name
- nicolasestrem/antigravity-gemini-skills★ 8same name
- BenjaminG/ai-skills★ 4same name
- marttp/my_agent_skills_I_use★ 4same name
- mcabreradev/hermes-sdd-agency★ 1same name
- younss/skills★ 1same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository56 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- .claude/terminals/T0/CLAUDE.mdCLAUDE.md
- .claude/terminals/T1/CLAUDE.mdCLAUDE.md
- .claude/terminals/T2/CLAUDE.mdCLAUDE.md
- .claude/terminals/T3/CLAUDE.mdCLAUDE.md
- api-developerSkill
- architectSkill
- backend-developerSkill
- control-centreSkill
- data-analystSkill
- database-engineerSkill
- debuggerSkill
- excel-reporterSkill
- fabric-referenceSkill
- featureplan-kickoffSkill
- frontend-developerSkill
- horizonSkill
- intelligence-engineerSkill
- monitoring-specialistSkill
- panelSkill
- performance-profilerSkill
- plannerSkill
- pmSkill
- python-optimizerSkill
- quality-engineerSkill
- refactor-safeSkill
- reviewerSkill
- security-engineerSkill
- supabase-expertSkill
- t0-orchestratorSkill
- test-engineerSkill
- vnx-managerSkill
- api-developerSkill
- architectSkill
- data-analystSkill
- database-engineerSkill
- debuggerSkill
- excel-reporterSkill
- fabric-referenceSkill
- featureplan-kickoffSkill
- frontend-developerSkill
- horizonSkill
- intelligence-engineerSkill
- monitoring-specialistSkill
- performance-profilerSkill
- plannerSkill
- pmSkill
- python-optimizerSkill
- quality-engineerSkill
- refactor-safeSkill
- reviewerSkill
- security-engineerSkill
- supabase-expertSkill
- t0-orchestratorSkill
- test-engineerSkill
- vnx-managerSkill
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
- Distinctive: line 10
Create fault-tolerant, scalable server-side solutions with focus on reliability and security.
- Distinctive: line 15
Create API endpoints with validation
- Distinctive: line 16
Add error handling and logging
- Distinctive: line 56
No breaking changes without versioning
- Very specific: line 99
Use scripts/intelligence.sh for accessing VNX intelligence patterns and solutions.
- Distinctive: line 111
No exceptions. This must appear before any other content.
“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.
Files
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>.tmpthenos.replace(tmp, path). Neveropen(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()intry: ... 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=Truekeyword and default toTrue. - 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> -xsucceeds. 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 inscripts/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 -non shell changes: every modified.shfile 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-developerNo exceptions. This must appear before any other content.
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
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.

