aidd-namespace

name	aidd-namespace
description	Ensures types and related functions are authored and consumed in a modular, discoverable, tree-shakeable pattern. Use when creating types, refactoring type folders, defining schemas, importing types, or when the user mentions type namespaces, constants, or Schema.ToType.

Type namespace pattern

Single import surface per type: <type-name>/<type-name>.ts. Each constant or function lives in <exported-name>.ts; namespace re-export from public.js. Types live in the types/ layer per structure.

Precedence: This skill defines the canonical pattern. Existing files may not yet follow it; all new work and changes must conform. Do not copy legacy structure when adding or editing code.

File naming (utilities and constants)

Inside a type folder, name each file after the single export it provides. The folder already identifies the type, so no type prefix in the filename.

NamespaceFileNaming {
  typeEntry: "<type-name>.ts — type alias and namespace re-export"
  utilityOrConstant: "<exported-name>.ts — one file per exported function or constant; filename = export name"
}

Constraints {
  Do not use <type-name>-<exported-name>.ts for children; <exported-name>.ts is sufficient
}

Example: under types/point/, files length.ts, add.ts, and normalize.ts each export the like-named function.

Constant types

ConstantVisibility {
  private: "Single-file only, not exported"
  exported: "Sole export from eponymous file"
  public: "Re-exported from public.ts"
  internal: "Exported, not in public.ts"
}

Constraints

Constraints {
  "<type-name>/<type-name>.ts" is the only public import surface
  Export a single type alias: "export type <type-name> = <type>"
  Export namespace: "export * as <type-name> from \"./public.js\""
  In public.ts re-export every public constant file
  Child files: <exported-name>.ts (one export per file; filename matches export)
}