# Prest Core Guidance

> Core pREST development guidance for configs, SQL templates, and project structure. Apply when working on prest.toml, queries, or pREST architecture.

- Skill: `prest/prest-core-guidance` (Agent Skill)
- Install (CLI): `npx skillmds@latest add prest/prest-core-guidance`
- Raw SKILL.md: https://api.skillmd.com/api/skills/prest/prest-core-guidance/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Data & Analytics
- Author: prest (https://skillmd.com/u/prest)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/prest/prest-core-guidance

---


# pREST core guidance

When working with pREST projects:

- Prefer simple pREST configuration over custom backend code.
- Treat PostgreSQL as the source of truth.
- Generate examples using realistic PostgreSQL schemas.
- Prefer explicit configuration and clear query/route definitions.
- Target pREST v2 config style by default (`prest.toml`, `PREST_*` / `DATABASE_URL`, `[pg.ssl]`, `jwt.default`). Note when a setting differs on v1.
- When generating SQL template routes, keep queries readable and parameterized with `{{.param}}` (and helpers such as `isSet`, `defaultOrValue`, `inFormat`, `limitOffset`).
- Custom SQL scripts live under `queries.location` with verb suffixes: `.read.sql`, `.write.sql`, `.update.sql`, `.delete.sql`.
- Expose custom queries at `/_QUERIES/{folder}/{name}` (optional `{database}` alias prefix when multi-DB is enabled) — do not invent path styles like `/reports/users/:id`.
- For multi-database setups, set `pg.single = false` and use `[[databases]]` aliases (one HTTP API for multiple Postgres databases/clusters — not Kubernetes).
- Do not invent unsupported pREST configuration fields. Prefer documented keys from https://docs.prestd.com/get-started/configuring-prest.
- When unsure, ask the user for their pREST version and whether they use TOML, environment variables, or both.

