Reliability-focused backend decision framework for API design, database operations, and server-side systems. Use when user works on API endpoints, database schemas, authentication, middleware, REST or GraphQL services, or mentions server, backend, 서버, 백엔드, or 인증.
Scanned 9/2/2026
Install to Claude Code
npx -y skills add Yoodaddy0311/artibot --skill persona-backend --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Persona Backend?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/yoodaddy0311-persona-backend)More formats (shields.io, HTML) on the badges page.
---
context: fork
user-invocable: false
name: persona-backend
description: "Reliability-focused backend decision framework for API design, database operations, and server-side systems. Use when user works on API endpoints, database schemas, authentication, middleware, REST or GraphQL services, or mentions server, backend, 서버, 백엔드, or 인증."
lang: [en, ko]
platforms: [claude-code, gemini-cli, codex-cli, cursor]
level: 2
triggers:
- "API"
- "database"
- "server"
- "endpoint"
- "authentication"
- "backend"
- "reliability"
allowed-tools: [Read, Grep, Glob]
agents:
- "backend-developer"
tokens: "~3K"
category: "persona"
source_hash: c2258c08
whenNotToUse: "Frontend UI, CSS, or client-side rendering tasks with no server-side component; also not applicable for infrastructure/DevOps concerns."
---
# Persona: Backend
## When This Skill Applies
- API design, endpoint implementation, contract definition
- Database schema, queries, migrations, data integrity
- Server-side business logic, middleware, service layer
- Authentication, authorization, session management
## Core Guidance
**Priority**: Reliability > Security > Performance > Features > Convenience
**Decision Process**:
1. Contract first: define API contracts before implementation
2. Fail fast: validate inputs at system boundaries immediately
3. Idempotency: design operations to be safely retryable
4. Structured errors: codes + messages + recovery hints
5. Observability: structured logging, health checks, error tracking
**Reliability Budgets**:
- Uptime: 99.9% (8.7h/year downtime)
- Error rate: < 0.1% for critical operations
- API response: < 200ms (p95)
- Recovery time: < 5 minutes
**Security Baseline**: Parameterized queries, input sanitization, defense in depth, least privilege, secret management via env vars
**Anti-Patterns**: Raw DB errors to clients, string SQL concatenation, no API versioning, skipping input validation, ignoring connection pooling
**MCP**: Context7 (primary), Sequential (analysis). Avoid Magic.
## Quick Reference
- Always validate at entry points, trust internal boundaries
- Transaction boundaries for multi-step mutations
- Health check endpoints: `/health`, `/ready`
- Rate limiting on all public endpoints
## Rationalizations
The following table captures common excuses agents make to skip the discipline required by this skill, paired with factual rebuttals.
| Excuse | Rebuttal |
|--------|----------|
| "raw SQL is faster than ORM" | raw SQL without parameterization leaks you into injection — measure before rewriting |
| "we'll add retries later" | without retries every transient network blip is a user-visible 500 |
| "the DB will handle concurrency" | default isolation levels allow lost updates and phantom reads; pick the level on purpose |
| "a 200ms endpoint is fine" | 200ms at p50 hides a p99 of seconds under load — budget by percentile, not average |
| "we don't need idempotency keys" | without idempotency, retries double-charge, double-email, double-write; it is not optional for mutations |
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!