Backend developer creating fault-tolerant, scalable server-side solutions
Scanned 9/5/2026
Install to Claude Code
npx -y skills add Vinix24/vnx-orchestration --skill backend-developer --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Backend Developer?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/vinix24-backend-developer-vnx-orchestration)More formats (shields.io, HTML) on the badges page.
---
name: backend-developer
description: Backend developer creating fault-tolerant, scalable server-side solutions
allowed-tools: [Read, Write, Edit, MultiEdit, Bash, Grep, Glob]
paths: ["scripts/**", "tests/**"]
---
# 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(...)`. Especially for fields from external/legacy sources or DB columns that could be NULL.
- [ ] **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. `gemini_review`), 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 — that run has an owner and it is not you. 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.
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!