Backend Development Standards

Core Philosophy

1. Documentation is Truth: Never guess syntax or patterns. If unsure, use

   search_web

   to find official docs.
2. Security First: Every input is malicious until validated. Every endpoint needs explicit AuthN/AuthZ.
3. Simplicity: Prefer boring technology that works. Complexity must be justified.

1. Dynamic Context Loading

1. Check the user's request and open files.
2. Load the relevant references using

   view_file

   .

references/general-patterns.md

references/node-express.md

references/node-nestjs.md

references/python-django.md

references/python-fastapi.md

references/go-gin.md

references/go-echo.md

references/java-springboot.md

[!NOTE] If the user asks a general question (e.g., "How do I secure my API?"), load

references/general-patterns.md

.

2. Core Responsibilities

A. API Design (Contract First)

• REST: Use clear resource naming (Plural nouns), standard status codes.
• GraphQL: Schema-first design.
• Documentation: All APIs must be documented (OpenAPI/Swagger).

B. Database Design

• Schema: 3rd Normal Form for Relational. Access-pattern driven for NoSQL.
• Indexes: Mandatory for foreign keys and query predicates.
• Migrations: Database changes must be versioned and reversible.

C. Security (Zero Trust)

• Validation: Use strict schema validation (Zod, Pydantic, Joi) at the entry point.
• Auth: JWT for stateless, Sessions for stateful. Always validate scopes/permissions.
• Secrets: NEVER hardcode secrets. Use Environment Variables.

D. Testing (Confidence)

• Unit: Test logic in isolation. Mock dependencies.
• Integration: Test DB interactions and API endpoints.

3. Collaboration with Lead Architect

lead-architect

1. System Design: Deciding between Monolith vs. Microservices.
2. Complex Security: Implementing Zero Trust, complex OAuth2/OIDC flows, or Threat Modeling.
3. Process: Defining CI/CD standards or DORA metrics.

lead-architect

.agent/skills/lead-architect/references/system-architecture.md

4. Interaction Rules

• Code Reviews: Be pedantic about security, performance (N+1 queries), and readability.
• Explanations: Explain WHY an architectural decision was made (Trade-offs).
• Unknowns: If you encounter a library or tool you don't know detailed syntax for, use

  search_web

  immediately.