New: 98,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Agent skill

Architecture Boundaries

by latitude-dev in latitude-dev/latitude-llm

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.

MITAuto-check passedBackend & APIs

Install Architecture Boundaries

skills CLI
$ npx skills add latitude-dev/latitude-llm --skill architecture-boundaries -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install latitude-dev/latitude-llm architecture-boundaries --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/latitude-dev/latitude-llm.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.agents/skills/architecture-boundaries .claude/skills/architecture-boundaries && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
architecture-boundaries
GitHub stars
4.7k
Token cost
~3.2k tokens
SKILL.md length
1,461 words
Files
1
Skills in repo
28
Repo updated
First seen
Licence
MIT

At a glance

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.

  • Works in 6 steps: Primary constructor is an Effect —… → Typed errors — Model connection,… → Configuration — Resolve settings with… → …
  • Tasks that involve Domain-driven design
  • SKILL.md covers App boundaries (apps/*), Application layout (apps/*), Web vs public API (apps/web,… and Cross-cutting implementation…, plus 11 more sections
  • Calls pnpm

What it does

Architecture Boundaries is an agent skill from latitude-dev/latitude-llm. 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.

Its SKILL.md is about 3.2k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Backend & APIs, covering Domain-driven design and Multi-tenancy. The repository describes itself as: Open-source observability for AI agents. Find where your agents fail, dispatch your coding agent to fix it, and verify the fix against real traces. The licence is MIT.

When your agent uses it

  • Tasks that involve Domain-driven design
  • Tasks that involve Multi-tenancy

Example prompts

  • “/architecture-boundaries”

Requirements

  • Python 3

Workflow steps

6 steps, taken from the first numbered list in SKILL.md.

  1. Primary constructor is an Effect — Export createXClientEffect(...): Effect.Effect (or with requirements R if unavoidable). Scripts and…
  2. Typed errors — Model connection, validation, and bootstrap failures with Data.TaggedError (or shared env errors from @platform/env). Union…
  3. Configuration — Resolve settings with parseEnv / parseEnvOptional from @platform/env inside the Effect pipeline, not ad hoc process.env…
  4. Interop — Wrap promise-based SDK calls in Effect.tryPromise and map failures to tagged errors. Compose steps with Effect.pipe…
  5. Bootstrap in the pipeline — If the client must apply schema/migrations/health checks before use, run those as Effects in the same pipeline…
  6. Live layers — Expose a thin XClientLive(client, scope...) layer for the external SDK client and keep repository adapters as Layer.effect…

What it can do on your machine

Read from SKILL.md and the folder at commit 3aae477. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • pnpm

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use pnpm, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Architecture Boundaries loads about 3.2k tokens when it runs. Until then it costs about 53 tokens; SKILL.md has 1,461 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~53
When it runs · the whole SKILL.md, loaded when a task matches
~3.2k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from latitude-dev/latitude-llm at commit 3aae477, republished under its MIT licence (© latitude-dev). 1,461 words, ~3,177 tokens.

Download SKILL.mdSave it as .claude/skills/architecture-boundaries/SKILL.md (or your agent's skills folder).
name
architecture-boundaries
description
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.

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/*)

  • Clients: Initialize integrations in apps/*/clients.ts and import from boundaries — avoid scattering raw clients.
  • Routes: Use apps/*/routes/ with a registerRoutes() (or equivalent) pattern so the HTTP surface stays modular.
  • Logging: Use createLogger() from @repo/observability with a stable service name per app.
  • Tracing: Every Effect.runPromise call site must include withTracing from @repo/observability in the pipe chain to connect Effect spans to the OTel pipeline. See effect-and-errors for the full tracing rules.
  • Configuration values: Read env through parseEnv / parseEnvOptional — see env-configuration.

Web vs public API (apps/web, apps/api, @repo/operations)

  • The public API's operation definitions (route config + transport-neutral execute logic) live in packages/operations (@repo/operations) — the boundary-contract layer between apps and domain. One definition fans out to the HTTP route, OpenAPI, MCP tool, SDK methods, CLI command, and in-process agent tools.
  • apps/api is the transport shell: middleware (auth, org context, rate limiting), the MCP HTTP transport, mounting operationModules, and the manifest emit scripts. Treat the operation contracts as externally consumed and evolve them carefully.
  • @repo/operations sits above domain: operations validate input, map to public schemas, and orchestrate @domain/* use-cases — the same boundary responsibilities apps own, factored into a package so non-HTTP consumers (worker-side agents) can run execute in-process.
  • apps/web must not call or proxy through apps/api for internal product features.
  • For web product development, implement backend behavior in apps/web server functions by composing domain use-cases and platform adapters directly.
  • Keep iteration velocity in apps/web by adding web-private server functions/stores while preserving apps/api stability.
  • Shared business rules still belong in domain packages; apps/web and @repo/operations should both orchestrate domain use-cases rather than duplicating policy.
  • Latitude product capabilities should be equally accessible to humans through the web UI and to other LLM agents through MCP/API surfaces.
  • Do not dead-end product behavior into UI-only flows. Preserve the boundary rules above, but design schemas, use-cases, and public capabilities so machine-facing access can exist without redesign.
  • For the concrete recipe — defineOperation, OperationModule manifests, group/sdkMethod/access/rateLimitTier, pnpm openapi:emit / pnpm mcp:emit, schema-description rules that fan out to the TS + Python SDKs, MCP tools, and the latitude CLI, the required declarative access field, and defineToolset (with its access ceiling) for internal agents — see api-endpoints.

Cross-cutting implementation constraints

  • Public request/response schemas should remain boundary-specific; they may reuse shared domain schemas or narrower projections rather than forcing full domain entities onto every surface.
  • When a capability is part of the product contract, preserve a machine-facing MCP/API surface instead of making it web-only.

Domain layer (packages/domain/*)

Business logic lives here. Domain packages expose:

  • Use-cases
  • Canonical entity schemas and inferred entity types
  • Domain types and errors
  • Dependency ports (interfaces/tags)

Domain package layout

Domain entities are Zod-first: entitySchema + z.infer<typeof entitySchema> in src/entities/<entity>.ts. See dev-docs/domain-entities.md and docs/adr/0001-domain-entity-schema-style.md.

  • Treat canonical domain entity schemas as the source of truth. Schemas and types elsewhere in the same domain, plus app/platform boundary schemas, should derive from or reuse the entity shapes whenever practical instead of re-declaring the same fields.
  • When a boundary schema must differ materially from the entity shape, still reuse the relevant domain constants, field schemas, and literal unions rather than hardcoding duplicated lengths or sentinel values again.
  • Canonical entity schemas and their inferred entity types belong in packages/domain/*/src/entities/<entity>.ts.
  • Domain package constants belong in packages/domain/*/src/constants.ts.
  • Domain package errors belong in packages/domain/*/src/errors.ts. A full package-by-package inventory and import rules live in dev-docs/domain-errors.md.
  • For how to structure those errors (tagged classes, HTTP fields, unions per flow, naming), treat packages/domain/issues as the reference: see packages/domain/issues/src/errors.ts and the section Domain errors (@domain/issues reference pattern) in dev-docs/issues.md.
  • Small domain-scoped shared helpers such as predicates or lifecycle helpers belong in packages/domain/*/src/helpers.ts.
  • Types and schemas that exist only as inputs to one domain use-case belong in that use-case file rather than a generic side module, unless several use-cases truly share the exact same contract.
  • App and platform layers should build boundary-specific schemas by reusing or deriving from domain entity/use-case schemas whenever practical rather than redefining the same contract from scratch.

Infrastructure (packages/platform/*)

Infrastructure details live here only. Platform packages implement adapters for domain ports.

Platform adapters: Effect-based clients

Reference implementation: packages/platform/db-weaviate/src/client.ts — createWeaviateClientEffect (and the thin createWeaviateClient wrapper used by scripts).

Use this pattern when a platform package owns an external SDK client so composition roots can stay in Effect and errors stay typed.

  1. Primary constructor is an Effect — Export createXClientEffect(...): Effect.Effect<Client, E, never> (or with requirements R if unavoidable). Scripts and one-off CLIs may export async function createXClient() as Effect.runPromise(createXClientEffect(...)) only at the boundary that needs promises.
  2. Typed errors — Model connection, validation, and bootstrap failures with Data.TaggedError (or shared env errors from @platform/env). Union them into a single CreateXClientError (or similar) exported next to the constructor.
  3. Configuration — Resolve settings with parseEnv / parseEnvOptional from @platform/env inside the Effect pipeline, not ad hoc process.env reads scattered outside the client module.
  4. Interop — Wrap promise-based SDK calls in Effect.tryPromise and map failures to tagged errors. Compose steps with Effect.pipe, Effect.flatMap, and Effect.map.
  5. Bootstrap in the pipeline — If the client must apply schema/migrations/health checks before use, run those as Effects in the same pipeline (see Weaviate: migrateWeaviateCollectionsEffect after connect) so callers get a ready client or a single error channel.
  6. Live layers — Expose a thin XClientLive(client, scope...) layer for the external SDK client and keep repository adapters as Layer.effect or Layer.succeed values that depend on that client service as needed. The composition root acquires the client with createXClientEffect and provides it via a small helper when useful, for example withWeaviate(IssueProjectionRepositoryLive, client, organizationId).

Not every legacy adapter has been migrated; prefer this shape for new work and when touching client construction.

Show full SKILL.md (493 more words)Show less

Shared utilities (packages/utils)

General-purpose utility functions that can be shared across any package (domain, platform, or app) live in @repo/utils. This package should contain pure, stateless helper functions with no domain or infrastructure dependencies.

Examples: formatCount, formatPrice, string helpers, number formatters.

When writing a utility function that is not specific to a single domain or package, place it in @repo/utils instead of keeping it local.

Shared domain vs utils

@domain/shared and @repo/utils have different responsibilities and should not be merged.

  • Use @domain/shared for domain-level shared contracts, types, errors, and IDs used across bounded contexts.
  • Use @repo/utils for global pure, stateless helpers that are reusable anywhere.
  • If a helper has domain/business meaning, it belongs in @domain/shared; otherwise, use @repo/utils.

Ports and adapters

  • Domain depends on interfaces/tags only (ports like Repository, CacheStore, Publisher)
  • Platform packages implement adapters
  • Composition roots in apps provide live layers
  • Domain must never import concrete DB/cache/queue/object storage clients
  • Repository method names: Use the standard verbs in dev-docs/repositories.md (findById, findByXxx for unique keys, listByXxx / list for collections, save, delete vs softDelete, etc.).
  • Reliability async contracts should stay project-scoped as well as organization-scoped: include both organizationId and projectId in event/task/workflow payloads by default (except MagicLinkEmailRequested, UserDeletionRequested, domain-events, magic-link-email, and user-deletion payloads).

Web standards first (domain, utils, shared)

In packages/domain/*, packages/utils, @domain/shared, or any code that may run outside Node (browser, edge, isolates), prefer Web Standard APIs over Node-only modules so those layers stay portable.

  • Use crypto.subtle / crypto.getRandomValues instead of node:crypto
  • Use fetch instead of Node-specific HTTP clients
  • Use TextEncoder / TextDecoder instead of Buffer.from(…, 'utf-8')
  • Use Uint8Array for binary data in public interfaces
  • Use ReadableStream instead of node:stream / node:fs streams
  • Use URL, URLSearchParams, Headers, Request, Response from the global scope
  • Use structuredClone instead of JSON round-trips for deep cloning

Node-only APIs are acceptable in build tooling, scripts, CLI utilities, and test infrastructure. If you need Node outside those scopes, add a brief comment explaining why.

Data and infrastructure (overview)

  • Postgres: Control-plane and relational data (users, organizations, memberships, config)
  • ClickHouse: High-volume telemetry storage and analytical reads
  • Weaviate: Vector database for embeddings storage and semantic similarity search
  • Redis: Cache and BullMQ backend
  • Object storage: Durable raw ingest payload buffering

For access patterns, schema, and migrations, see database-postgres and database-clickhouse-weaviate.

Multi-tenancy

  • Every request is organization-scoped
  • A user may belong to many organizations
  • Organization membership checks happen at boundaries before domain execution
  • All telemetry persistence and query paths include organizationId
  • Organization-scoped Redis or cache keys must start with org:${organizationId}:...; keep the org id first in the key

Domain design (DDD)

  • Organize by bounded context (e.g. telemetry, organizations, identity, alerts)
  • Domains should be single-responsibility and focused on policy/rules
  • Use in-memory adapters for fast tests where possible

Anti-patterns to reject

  • Cross-domain logic without clear ownership
  • New provider integrations without a core capability contract
  • Introducing application env vars without the LAT_ prefix (see env-configuration)
  • Using "use client" or "use server" directives — these are Next.js-specific; the web app uses TanStack Start
  • Exporting test utilities from a package's main entry point (see testing)

© latitude-dev, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in .agents/skills/architecture-boundaries of latitude-dev/latitude-llm.

Open the folder on GitHubat commit 3aae477

Compare with similar skills

Architecture Boundaries next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Architecture Boundaries compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Architecture Boundaries this skilllatitude-dev/latitude-llm4.7k—~3.2kAutomated safety check: PassMIT
PR Review Provideryansongda/pay5.4k—~2.4kAutomated safety check: PassMIT
Dynamic Consistency BoundariesAxonIQ/AxonFramework3.6k—~1.9kAutomated safety check: PassApache-2.0
NestJS Modular Monolith Architecttech-leads-club/agent-skills7k—~3.9kAutomated safety check: PassCC-BY-4.0
Event Sourcingcitypaul/.dotfiles740—~7.8kAutomated safety check: PassCustom licence
Laravel Clean ArchitectureHoangNguyen0403/agent-skills-standard571—~913Automated safety check: PassMIT

Similar skills

  • PR Review Provider

    yansongda/pay

    A skill your agent uses when reviewing PRs that add or modify a payment Provider in yansongda/pay - covers plugin pipeline, multi-tenant safety, signature verification, docs, and naming conventions.

    5.4k GitHub stars~2.4k tokensUpdated yesterday
    Backend & APIsAuto-check passed

  • Dynamic Consistency Boundaries

    AxonIQ/AxonFramework

    Explain and reason about Dynamic Consistency Boundaries (DCB) and how Axon Framework 5 and Axon Server implement them.

    3.6k GitHub stars~1.9k tokensUpdated yesterday
    Backend & APIsAuto-check passed

  • NestJS Modular Monolith Architect

    tech-leads-club/agent-skills

    Designs scalable NestJS modular monoliths with domain-driven design, Clean Architecture layers and optional CQRS, defining bounded contexts and strict module boundaries.

    7k GitHub stars~3.9k tokensUpdated yesterday
    Backend & APIsAuto-check passed

  • Event Sourcing

    citypaul/.dotfiles

    Event sourcing patterns for functional TypeScript — persist state as an append-only log of past events and rebuild it by folding them.

    740 GitHub stars~7.8k tokensUpdated today
    Backend & APIsAuto-check passed

  • Laravel Clean Architecture

    HoangNguyen0403/agent-skills-standard

    Implement Domain-Driven Design with typed DTOs, repository interfaces, and single-responsibility Action classes in Laravel.

    571 GitHub stars~913 tokensUpdated today
    Backend & APIsAuto-check passed

  • Evolutionary Modular Architecture

    tech-leads-club/agent-skills

    Guides design of modular-monolith platforms with DDD, flat-by-aggregate modules, anti-corruption layers, outbox events and resilience, plus an architecture document with SVG diagrams.

    7k GitHub stars~3.7k tokensUpdated yesterday
    DevelopmentAuto-check passed

More from latitude-dev/latitude-llm

All 28 skills in this repo

  • Better Auth Best Practices

    latitude-dev/latitude-llm

    Configure Better Auth server and client, set up database adapters, manage sessions, add plugins, and handle environment variables.

    4.7k GitHub starsUsed in 7 repos~1.6k tokens
    Auto-check passed

  • Artifact Designer

    latitude-dev/latitude-llm

    Create, validate, preview, and publish self-contained HTML artifacts.

    4.7k GitHub stars~1.1k tokensUpdated yesterday
    Auto-check passed

  • CI Watchdog

    latitude-dev/latitude-llm

    Continuously monitor GitHub PR CI checks and automatically fix failures until all checks pass.

    4.7k GitHub stars~1.6k tokensUpdated yesterday
    Auto-check passed

  • Temporal Developer

    latitude-dev/latitude-llm

    This skill should be used when the user asks to "create a Temporal workflow", "write a Temporal activity", "debug stuck workflow", "fix non-determinism error", "Temporal Python", "Temporal…

    4.7k GitHub stars~1.5k tokensUpdated yesterday
    Auto-check passed

  • Docs

    latitude-dev/latitude-llm

    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.

    4.7k GitHub stars~2.5k tokensUpdated yesterday
    Auto-check passed

  • Managing Maintenance Windows

    latitude-dev/latitude-llm

    Enables or disables Latitude production maintenance mode by redirecting all publicly exposed production services to the Better Stack status page.

    4.7k GitHub stars~802 tokensUpdated yesterday
    Auto-check passed

Categories

Questions about Architecture Boundaries

What does Architecture Boundaries do?

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. Architecture Boundaries is an agent skill from latitude-dev/latitude-llm. 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.

When should I use Architecture Boundaries?

Architecture Boundaries fits situations like: tasks that involve Domain-driven design; tasks that involve Multi-tenancy.

How do I install Architecture Boundaries in Claude Code?

Run `npx skills add latitude-dev/latitude-llm --skill architecture-boundaries -a claude-code`. Or copy the skill folder (.agents/skills/architecture-boundaries in latitude-dev/latitude-llm) into .claude/skills/architecture-boundaries in your project. Claude Code loads it when a task matches its description.

How do I install Architecture Boundaries in Codex?

Run `npx skills add latitude-dev/latitude-llm --skill architecture-boundaries -a codex`. Or copy the skill folder (.agents/skills/architecture-boundaries in latitude-dev/latitude-llm) into .agents/skills/architecture-boundaries in your project. Codex loads it when a task matches its description.

Can I use Architecture Boundaries in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add latitude-dev/latitude-llm --skill architecture-boundaries -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/architecture-boundaries, .gemini/skills/architecture-boundaries, .github/skills/architecture-boundaries and .opencode/skills/architecture-boundaries in your project.

What does Architecture Boundaries need to run?

Going by SKILL.md and its folder, Architecture Boundaries needs the command-line tools its instructions call (pnpm). Our summary lists: Python 3.

Does Architecture Boundaries access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Architecture Boundaries safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Architecture Boundaries use?

Architecture Boundaries is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Architecture Boundaries use?

About 3.2k tokens (SKILL.md is roughly 13k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Architecture Boundaries?

Skills that share tags, products or a category with Architecture Boundaries: PR Review Provider (yansongda/pay, 5.4k stars), Dynamic Consistency Boundaries (AxonIQ/AxonFramework, 3.6k stars), NestJS Modular Monolith Architect (tech-leads-club/agent-skills, 7k stars) and Event Sourcing (citypaul/.dotfiles, 740 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Architecture Boundaries?

latitude-dev (a GitHub organization) maintains it in latitude-dev/latitude-llm, which has 4,716 GitHub stars. The repository holds 28 skills in this directory. The repository was last updated on October 8, 2026.

Source: latitude-dev/latitude-llm on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.