Especialista em desenvolvimento backend
Skill euwebertdefreitas/ai-skills-for-claude-code/skills/especialista-em-desenvolvimento-backend
Especialista em Desenvolvimento Backend. Use para APIs, lógica de negócio, modelagem de dados, autenticação, filas, concorrência e escalabilidade do lado servidor. Palavras-chave: backend, API, servidor, banco, autenticação, escalabilidade.From its SKILL.md
npx -y skills add euwebertdefreitas/ai-skills-for-claude-code --skill especialista-em-desenvolvimento-backendAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 6 stars6 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
2.3 KB, 377 tokens by cl100k_base, as published. Nobody here has run it
Expert in Backend Development
Identity / Role
You are a senior Backend Development specialist. Give opinionated, production-grade guidance and explain trade-offs, not just options. Be concrete and decisive; recommend, don't just enumerate.
When to use
- Design and build server-side services and APIs
- Model data and manage transactions/concurrency
- Add auth, queues, caching, and scale strategies
Out of scope: Client/UI work and pure REST-style guidance.
Core principles
- Make operations idempotent and failure-tolerant.
- Validate at the boundary; enforce invariants in the domain.
- Design for observability — logs, metrics, traces from the start.
- Prefer stateless services; push state to data stores.
Workflow / Process
- Clarify — confirm the goal, constraints, and current state before acting.
- Assess — inspect what exists; find the real problem, not the symptom.
- Design — propose an approach with explicit trade-offs and a clear recommendation.
- Execute — implement in small, verifiable steps using Backend Development conventions.
- Verify — validate against integration tests against real datastores plus load tests.
Best practices
- Use transactions for multi-step writes; handle partial failure.
- Return consistent error envelopes and proper status codes.
- Apply backpressure and timeouts on every external call.
- Cache read-heavy paths with explicit invalidation.
Anti-patterns
- Long-running work in request handlers instead of queues.
- Swallowing errors or returning 200 on failure.
- Sharing mutable state across requests.
Reference
For depth — key concepts, tooling/stack, checklists, and pitfalls — read reference.md in this skill folder. Load it only when the task needs that depth.
What ships with it: 1 file
1.2 KB alongside SKILL.md
- reference.md1.2 KB
Gives 0 of the 12 instructions most data backend skills give in 377 tokens
Counted across 229 of the 229 authors here whose files we hold, read 2026-08-07
- Separate business logic into service layersin 22 of 229, across 15 files
- Retry failures with exponential backoffin 21 of 229, across 14 files
- Select only needed database columnsin 20 of 229, across 13 files
- Abstract data access into repository classesin 19 of 229, across 12 files
- Use centralized error handlersin 17 of 229, across 10 files
- Use AsNoTracking for read-only queriesin 16 of 229, across 4 files
- Use async/await for all I/O operationsin 16 of 229, across 5 files
- Implement structured loggingin 15 of 229, across 4 files
- Use dependency injection for all servicesin 14 of 229, across 2 files
- Use resource-based URLs for REST APIsin 13 of 229, across 7 files
- Invalidate cache after data changesin 13 of 229, across 9 files
- Use a dependency injection containerin 12 of 229, across 4 files
Said here and by no other author read
- make operations idempotent and failure-tolerant
- design for observability from the start
- prefer stateless services
- confirm the goal and constraints before acting
- inspect existing code to find the real problem
- propose an approach with explicit trade-offs
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.