env-configuration
Environment configuration
When to use: Adding or reading env vars, updating .env.example, or validating config at startup with parseEnv / parseEnvOptional.
LAT_ prefix convention
All application environment variables must be prefixed with LAT_ so they do not collide with third-party services, Docker, or common names.
Use LAT_ for:
- Database URLs and pool settings (
LAT_DATABASE_URL,LAT_PG_POOL_MAX, …) - Service endpoints the app reads (
CLICKHOUSE_URL,LAT_REDIS_HOST, …) - App ports (
LAT_API_PORT,LAT_WEB_PORT,LAT_INGEST_PORT) - Auth, email, OAuth, billing, CORS (
LAT_BETTER_AUTH_SECRET,LAT_MAILPIT_HOST, …) - Any new variable consumed by Latitude application code
Do not use LAT_ for:
More from latitude-dev/latitude-llm
gh-issue
Create clear, actionable GitHub issues for bugs, features, and improvements. Issues are primarily consumed by LLMs, so optimize for agent readability and actionability.
4testing
Writing or debugging tests, choosing unit vs integration style, Postgres/ClickHouse tests, regenerating ClickHouse test schema, or exporting test helpers from packages without pulling test code into production bundles.
4docs
Review the current conversation context and git changes, then persist durable repository knowledge into `dev-docs/*.md` by domain and into `AGENTS.md` for cross-cutting repo rules. Use after features, fixes, refactors, architecture changes, schema changes, or when the user mentions docs, documentation, design, architecture, business logic, conventions, or `AGENTS.md`.
4create-pr
Patterns and conventions for creating a good PR
4authentication
Sessions, sign-in/sign-up flows, OAuth, magic links, or organization context on the session.
4analyze-problem
>-
4