Skip to content
Back to skills

Backend Developer

ASecurity

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

  • 61 stars
  • 0 votes
  • 0 copies
  • 1 view
  • Added May 28, 2026
ai-agentspythonshellbashsqltestingdebuggingapidatabasebackendsecurity

Works with

  • api

Security analysis

A100/100

Pro scans all 4 files and shows the line behind each finding

Scanned September 28, 2026

npx -y skills add Vinix24/vnx-orchestration --skill backend-developer --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Backend Developer?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Backend Developer
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/vinix24-backend-developer/badge)](https://www.skillsdirectory.com/skills/vinix24-backend-developer)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
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. `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 — 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.

Files in this skill

  • SKILL.md2.1 KB
  • references/_MAPPING.md434 B
  • scripts/intelligence.sh1.2 KB
  • template.md1.5 KB

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…