lane-backend-api

Files (1)

• SKILL.md

SKILL.md (first lines)

# Lane: Backend API

## Focus

- Input validation and output consistency.
- Server-side authorization checks.
- Clear error models and status codes.

## Starter Checklist

- [ ] Inputs validated at trust boundaries.
- [ ] Sensitive operations enforce server-side auth.
- [ ] Error responses are structured and safe.
- [ ] Timeouts/retries considered for external integrations.
- [ ] Logs include actionable context without secrets.

## Guardrails

- Do not trust client checks for authorization.
- Prefer explicit contracts over implicit request assumptions.

## Implementation Pattern

Evidence: 4-repo field extraction (3x Next.js, 1x Python/FastAPI) — see `.ai/MERGE_REPORT.md`.

- API route handlers stay a thin boundary: validate input, call a service/orchestrator
  function, return a structured response envelope. Never inline business logic in the handler.
- Reject unsupported HTTP methods and malformed input explicitly with a defined status code;
  never silently accept them.
- Route auth/session checks through one shared helper or middleware, never re-implemented per
  handler.
- New/greenfield routes validate their input with a runtime schema (e.g. Zod, pydantic), not
  just compile-time types or manual casts — this is a kit default even where an existing repo
  is inconsistent about it (confirmed: 3 of 4 field repos already do this; the 4th is
  inconsistent, not a counter-example to follow).

If the current project already has an established pattern for any of these, follow the existing
pattern instead of this default — except runtime validation on new routes, which is a kit
baseline regardless of an inconsistent existing repo.

From JahacksV1/day-one-agent-kit, MIT.

More from JahacksV1/day-one-agent-kit