playbooks

home / skills / atrislabs / atris / backend

backend skill

/atris/skills/backend

This skill helps you design backend APIs and services without over-engineering by applying Atris policy patterns and best practices.

npx playbooks add skill atrislabs/atris --skill backend

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
1.7 KB
---
name: backend
description: Backend architecture policy. Use when building APIs, services, data access, or any backend work. Prevents over-engineering.
version: 1.0.0
allowed-tools: Read, Write, Edit, Bash, Glob, Grep
tags:
  - backend
  - architecture
  - anti-patterns
---

# atris-backend

Part of the Atris policy system. Prevents ai-generated backend from being over-engineered.

## Atris Integration

This skill uses the Atris workflow:
1. Check `atris/MAP.md` for existing patterns before building
2. Reference `atris/policies/atris-backend.md` for full guidance
3. After building, run `atris review` to validate against this policy

## Quick Reference

**Naming:** avoid `data`, `result`, `handler`, `manager`, `service`, `utils`. names reveal intent.

**Abstractions:** three concrete examples before you abstract. copy-paste until patterns emerge.

**Errors:** let errors bubble. include context: what were you doing? what input caused this?

**Data Access:** no n+1 queries. think about patterns upfront. batch when possible.

**API Design:** boring and consistent. same patterns everywhere.

## Before Shipping Checklist

Run through `atris/policies/atris-backend.md` "before shipping" section:
- can you explain this in one sentence?
- are abstractions earning their keep?
- do error messages help debugging?
- anything "just in case" you could delete?

## Atris Commands

```bash
atris            # load workspace context
atris plan       # break down backend task
atris do         # build with step-by-step validation
atris review     # validate against this policy
```

## Learn More

- Full policy: `atris/policies/atris-backend.md`
- Navigation: `atris/MAP.md`
- Workflow: `atris/PERSONA.md`

Overview

This skill enforces a practical backend architecture policy to keep APIs, services, and data access simple, consistent, and maintainable. It focuses teams on preventing over-engineering while ensuring safe patterns for naming, abstraction, error handling, and data access. Use it as a lightweight guardrail for any backend work in JavaScript projects.

How this skill works

The skill inspects code and design decisions against a concise checklist: naming conventions, abstraction maturity, error context, and data-access patterns. It encourages checking an existing pattern map before building, requires concrete examples before creating abstractions, and flags anti-patterns like n+1 queries or vague names. It integrates with a simple workflow to plan, build step‑by‑step, and run a final policy review for validation.

When to use it

  • Designing or changing API endpoints
  • Implementing service or data-access layers
  • Refactoring or introducing new abstractions
  • Preparing backend code for review or release
  • Onboarding teammates to consistent backend patterns

Best practices

  • Check existing patterns before creating new ones to avoid duplication
  • Provide three concrete examples before extracting an abstraction
  • Prefer explicit, intention-revealing names over generic terms
  • Let errors bubble with actionable context (operation, inputs) for easier debugging
  • Avoid n+1 queries: design for batching and predictable access patterns
  • Keep APIs boring and consistent across the codebase

Example use cases

  • Building a new REST or GraphQL endpoint while ensuring consistent naming and error messages
  • Refactoring data access to prevent n+1 queries and introduce batching
  • Evaluating whether a proposed helper deserves extraction into a reusable abstraction
  • Running a pre-shipping checklist to remove unnecessary "just in case" code
  • Using the plan/do/review workflow to break down backend tasks and validate outcomes

FAQ

What counts as over-engineering here?

Over-engineering is adding abstractions, indirection, or features before there is clear repeated need—extract only after three concrete examples and measurable reuse.

How should errors be reported?

Allow them to propagate with context: describe the operation, include relevant input identifiers, and avoid swallowing exceptions so reviewers can trace failures quickly.