architecture-boundaries
Architecture and layer boundaries
When to use: Layering and boundaries, web vs public API, app layout (clients, routes, logging), ports/adapters, runtime-portable domain/shared/utils code, multi-tenancy, DDD layout, or anti-patterns.
App boundaries (apps/*)
Apps only handle:
- Input validation
- Authentication and authorization
- Organization access enforcement
- Routing to domain use-cases
No business logic in handlers, controllers, or jobs.
Application layout (apps/*)
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