TDvorak/SEEN
1
0
Fork 0
mirror of https://github.com/Dvorinka/SEEN.git synced 2026-07-29 15:03:49 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

small fix, don't worry about it

Browse Source
This commit is contained in:
Tomas Dvorak
2026-04-10 12:06:24 +02:00
commit 5c500a72b0
243 changed files with 44176 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.blackbox/skills/tdvorak-fullstack/SKILL.md
+43
View File
@@ -0,0 +1,43 @@
---
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.