organizing-fsd-architecturelisted

# Organizing FSD Architecture ## Overview This skill provides expertise for implementing Feature-Sliced Design (FSD) in the DorkOS monorepo. FSD organizes code by business domains with clear layer boundaries and unidirectional dependency rules. The full layer-import matrix, cross-module rules, segment structure, and barrel/alias conventions live in `.claude/rules/fsd-layers.md` — that rule is the authority; this skill is the placement and size-monitoring guidance on top of it. ## When to Use - Creating new features, widgets, or entities in `apps/client` - Deciding where code should live (which layer/segment) - Reviewing imports for layer violations - Refactoring components into FSD structure - Adding new services to `apps/server` (size-aware guidance) ## The Layer Spine Strict top-to-bottom dependency flow within `apps/client/src/layers/`: ``` app → widgets → features → entities → shared ``` Higher imports lower, never the reverse; same-level model/hook cross-imports are forbidden (UI composition across features is allowed). See `.claude/rules/fsd-layers.md` for the per-layer import matrix and code examples. ## Step-by-Step: Determine the Correct Layer ``` Is it a reusable utility, UI primitive (Button, Card), or type? └─ YES → shared/ Is it a core business entity (Session, Agent, Workspace)? └─ YES → entities/[entity-name]/ Is it a complete user-facing feature (chat, command palette, settings)? └─ YES → features/[feature-name]/ Is it a large composition of mult