mirror of
https://github.com/Dvorinka/SEEN.git
synced 2026-07-29 07:03:46 +00:00
44 lines
2.9 KiB
Markdown
44 lines
2.9 KiB
Markdown
---
|
|
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.
|