template-architecture

name

template-architecture

description

How this template is structured — the layer-sliced, feature-keyed architecture (db / contract / core / surfaces / agent / ui / components), the cross-layer capability-key rule, the two schema sources (no drizzle-zod), and where a new capability slice goes. Load this before adding or moving a capability, a package, a Hono route, an AI tool, or a schema, or whenever you need to know where something lives in this repo.

Template architecture

This skill is a thin trigger. The knowledge itself lives in the repo's canonical docs (single source of truth, human-visible in the docs app) — read the relevant file directly rather than restating it here. This follows the "ours points into docs/ by plain path" rule (ADR-0010 §H).

Read these

• The one map — layers, how a feature flows through them, the boundary rules: read docs/architecture.md.
• Why a choice was made (under a strict significance bar): browse docs/decisions/ (e.g. 004-schema-sources-and-boundary-types.md for the two-schema-source / no-drizzle-zod rule).
• How to do or extend something here: read the relevant guide under docs/guides/.

The one rule to remember

A capability uses the same key in every layer. A customer capability is exactly: packages/db/src/schema/customer.ts · packages/contract/src/customer/ · packages/core/src/customer/ · apps/web/src/hono/<auth-scope>/customer/ · packages/agent/src/tools/customer/ · apps/web/src/components/customer/. Find one slice and you know where the other five live. See docs/architecture.md for the worked example.