ledger-live: Skill for Claude Code

Domain data: one entity, one api

One backend resource maps to one entity. Use data-layer-advanced when one response hydrates several entities. Placement comes from structure-flow, barrels from package-public-api.

Reference packages: @domain/entity-contact and @domain/api-push-devices.

Entity package

domain/entity/<name>/src/
├── schema.ts         # Zod schemas (required)
├── types.ts          # z.infer types and the state type
├── schema.mock.ts    # mock factories, parsed by the schema (required)
├── slice.ts          # createSlice, initial state, default reducer
├── slice.mock.ts     # mock slice state (required with a slice)
├── selectors.ts
└── index.ts          # export * only

Every source file has its *.test.ts. Slice, selectors and their mocks are optional: an entity can be schema-only.

Schema first. Write the Zod schema, then infer the type. Never hand-write a type the schema already describes, and never add Typia.

// schema.ts
export const ContactNameSchema = z.string().min(1).max(CONTACT_NAME_MAX_LENGTH).brand<"ContactName">();

// types.ts
export type ContactName = z.infer<typeof ContactNameSchema>;

• Brand ids and constrained strings (.brand<"ContactName">(), CryptoCurrencyIdSchema in @domain/entity-currency-crypto) so two strings of different meaning cannot be swapped.
• Reuse primitives from @shared/schema-primitives (NonEmptyStringSchema, DateTimeIsoSchema, HttpUrlSchema) and other entities' schemas, never a local copy.
• Nullable means .nullable(). A field the backend sends as null is .nullable(); a field it may leave out is .optional(). They are not interchangeable.
• Build values through the schema. A constructor such as contact(data) in define.ts returns ContactSchema.parse(data), so a branded value always passed validation.