---
name: tdvorak-fullstack
description: "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.