SEEN/.blackbox/skills/tdvorak-fullstack/SKILL.md

name, description

name

description

tdvorak-fullstack

Personal default skill for building or extending TDvorak projects as production-grade SaaS or PaaS software. Use when Codex needs to scaffold, architect, refactor, or polish a full-stack product with TDvorak's preferred defaults: SolidJS first with React fallback, Vite, TypeScript, Tailwind, Ark UI or shadcn, Better Auth, Go and Gin APIs, PostgreSQL with sqlc and goose, OpenAPI-generated TypeScript clients, Docker Compose, and premium product-grade UI standards.

TDvorak Fullstack

Use this skill as the default operating profile for TDvorak projects. Optimize for production quality, calm premium UI, predictable architecture, and maintainable delivery speed.

Workflow

1. Inspect the repository before choosing tools. Reuse established project conventions unless the user explicitly asks to migrate toward these defaults.
2. If the stack is open-ended, default to the architecture in references/architecture.md.
3. Before building frontend UI, follow the component selection order in references/ui-standards.md.
4. Read only the reference files relevant to the task:

• references/architecture.md for stack, backend, auth, API, database, infra, and project layout defaults.
• references/ui-standards.md for product polish, component sourcing, spacing, typography, motion - motion.dev, responsiveness, and the visual quality bar.

5. Keep the output production-oriented. Favor small focused modules, generated API types, accessible components, responsive layouts, and Docker-based local runs.

Non-Negotiables

• Prefer SolidJS for greenfield frontend work. Use React only when the project or dependency constraints make Solid materially worse.
• Prefer Go with Gin for HTTP APIs. Introduce Rust or Python only when justified by task constraints.
• Define API contracts in OpenAPI and generate TypeScript clients and types from the spec. Do not hand-maintain duplicate request or response types.
• Use PostgreSQL, sqlc, and goose for persistence and schema evolution.
• Use Better Auth for authentication when auth is required.
• Keep UI calm, premium, and intentional. Avoid generic AI-looking layouts, clutter, weak hierarchy, and gratuitous animation.
• Do not use emojis in product UI unless the user explicitly requests them.

Component Selection Order

When building or revising UI, check these sources before writing custom components:

1. Magic UI MCP if it is available in the session.
2. shadcn or shadcn-solid resources available in the session or project.
3. /home/tdvorak/.codex/skills/frontend-design/SKILL.md when the task is design-heavy or starts from a blank canvas.
4. Existing project components and patterns in the repository.

Create custom UI only after those checks or when none of them fit.

Delivery Standard

Ship work that feels like serious modern software rather than a prototype. If the result looks generic, crowded, inconsistent, or under-structured, redesign it before finishing.