House conventions for TypeScript/React/Next.js focused on readable, traceable code: a two-file traceability budget and NASA's Power of Ten adapted to TypeScript, as skills, commands, and a reviewer agent
Skills 7 in the Claude listing
Pxkit component Design and build a React component the pxkit way — place it in the tree, list its states, design the props API before the markup, compose existing primitives, and keep everything it uses in one file. Pxkit conventions The pxkit house style for TypeScript, React, and Next.js — readability red lines, NASA's Power of Ten rules adapted to TypeScript, naming and types, components and styling with shadcn/ui and Tailwind, Pxkit debug The pxkit debugging method for TypeScript, React, and Next.js — reproduce, localize top-down (page → section → primitive), map references both ways, trace to the root cause (asking where, why, and how Pxkit feature Plan and build a feature the pxkit way — user journey and business rules first, a flat component tree, an explicit state and communication map, then a colocated feature folder with direct imports, and Pxkit form Build or extend a form the pxkit way — zod schema and error keys first, react-hook-form logic, shadcn Field/FieldGroup markup, a control chooser, and submit through a Result-returning server action. Pxkit nextjs page Build a Next.js App Router page, route group, or landing section the pxkit way — a thin server page composing section components, client code only in leaves, metadata through the root title template a Pxkit service Write a service or server boundary the pxkit way — one plain http client, zod-parsed responses and payloads, DTOs parsed to domain types once, a narrowed Result with SCREAMING_SNAKE error keys, and no