mirror of
https://github.com/Dvorinka/SEEN.git
synced 2026-06-05 13:03:01 +00:00
small fix, don't worry about it
This commit is contained in:
Tomas Dvorak
@@ -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.
|
||||
@@ -0,0 +1,4 @@
|
||||
interface:
|
||||
display_name: "TDvorak Fullstack"
|
||||
short_description: "Personal SaaS full-stack build standards"
|
||||
default_prompt: "Use $tdvorak-fullstack to build or extend this project with the preferred SolidJS, Go, PostgreSQL, and SaaS-grade product standards."
|
||||
@@ -0,0 +1,83 @@
|
||||
# Architecture Defaults
|
||||
|
||||
Read this file when choosing stack, scaffolding a new codebase, or making backend, auth, database, or infrastructure decisions.
|
||||
|
||||
## Stack Defaults
|
||||
|
||||
- Default to SolidJS for new frontend work.
|
||||
- Fall back to React when Solid would materially slow delivery, block needed libraries, or fight the existing project.
|
||||
- Use Vite, TypeScript, and Tailwind CSS on the frontend.
|
||||
- Prefer Ark UI for Solid and shadcn or shadcn-solid when they fit the project.
|
||||
- Support responsive layouts, dark and light mode, and accessibility by default.
|
||||
|
||||
## Authentication
|
||||
|
||||
- Use Better Auth when authentication is required.
|
||||
- Prefer secure cookie sessions.
|
||||
- Model user accounts first, then add organizations, teams, roles, or API tokens when the product requires them.
|
||||
|
||||
## Backend
|
||||
|
||||
- Default to Go for backend services.
|
||||
- Use Gin for HTTP APIs.
|
||||
- Use zap for structured logging.
|
||||
- Keep packages small and focused.
|
||||
- Avoid framework magic and hidden behavior.
|
||||
- Keep routing, business logic, and data access explicit.
|
||||
- Introduce Rust or Python only when the task has a clear technical reason for it.
|
||||
|
||||
## API Contract
|
||||
|
||||
- Treat OpenAPI as the single source of truth.
|
||||
- Generate the TypeScript client, shared API types, and request helpers from the OpenAPI spec.
|
||||
- Do not duplicate API types manually in frontend code.
|
||||
- Keep request and response shapes aligned with generated artifacts.
|
||||
|
||||
## Database
|
||||
|
||||
- Use PostgreSQL as the default database.
|
||||
- Use sqlc for type-safe query generation.
|
||||
- Use goose for migrations.
|
||||
- Apply schema changes through versioned migrations only.
|
||||
- Do not edit production schemas manually.
|
||||
|
||||
## Infrastructure
|
||||
|
||||
- Make the project runnable with `docker compose up`.
|
||||
- Use Docker and Docker Compose as the default local orchestration layer.
|
||||
- Include the application, database, and reverse proxy when the product needs them.
|
||||
- Use Nginx or Traefik for TLS termination, routing, static file serving, and load balancing.
|
||||
|
||||
## Desktop and Mobile
|
||||
|
||||
- Use Wails for Go-centric desktop apps. Use Tauri when it is a better technical fit.
|
||||
- Keep the desktop frontend aligned with the web frontend when possible.
|
||||
- Use React Native for mobile apps.
|
||||
- Reuse the same backend APIs and design language across web, desktop, and mobile surfaces.
|
||||
|
||||
## Project Layout
|
||||
|
||||
Use this structure for greenfield full-stack projects unless the repository already has a better-established layout:
|
||||
|
||||
```text
|
||||
/apps
|
||||
/frontend
|
||||
/backend
|
||||
|
||||
/packages
|
||||
/api-client
|
||||
/shared-types
|
||||
|
||||
/infra
|
||||
docker-compose.yml
|
||||
nginx
|
||||
```
|
||||
|
||||
Keep frontend and backend concerns clearly separated.
|
||||
|
||||
## Code Quality
|
||||
|
||||
- Use strict TypeScript.
|
||||
- Use clear naming and small focused functions.
|
||||
- Preserve clean module boundaries.
|
||||
- Favor maintainability and predictability over clever abstractions.
|
||||
@@ -0,0 +1,59 @@
|
||||
# UI Product Standards
|
||||
|
||||
Read this file when designing screens, choosing components, or judging whether a UI is ready to ship.
|
||||
|
||||
## Product Bar
|
||||
|
||||
- Build interfaces that feel like real production software, not prototypes.
|
||||
- Optimize for consistent layout, clear hierarchy, predictable UX, strong performance, and scalable composition.
|
||||
- Keep the interface calm, premium, structured, and intentional.
|
||||
|
||||
## Design Direction
|
||||
|
||||
- Use generous whitespace and a steady layout rhythm.
|
||||
- Keep typography clean, readable, and deliberate.
|
||||
- Use refined color with restraint.
|
||||
- Prefer modern minimalism over visual noise.
|
||||
- Avoid cluttered layouts, inconsistent spacing, and generic AI-looking compositions.
|
||||
|
||||
## Component Strategy
|
||||
|
||||
- Use a design-system-first mindset.
|
||||
- Check Magic UI MCP first when it is available.
|
||||
- Check shadcn or shadcn-solid before building custom components.
|
||||
- Read `/home/tdvorak/.codex/skills/frontend-design/SKILL.md` for design-heavy or blank-canvas frontend work.
|
||||
- Inspect existing project components before creating something new.
|
||||
- Use Tailwind utilities where practical and prefer composition over custom overrides.
|
||||
|
||||
## Interaction and Motion
|
||||
|
||||
- Use subtle transitions, clear hover states, and responsive feedback.
|
||||
- Keep animation in service of clarity rather than decoration.
|
||||
- Avoid heavy or distracting motion.
|
||||
- Prioritize performance.
|
||||
- Use `https://haptics.lochie.me/` as a motion reference when useful.
|
||||
|
||||
## Quality Targets
|
||||
|
||||
Aim for the polish level associated with products such as Linear, Vercel, Stripe Dashboard, Supabase, and Notion without copying them directly.
|
||||
|
||||
## UI Rules
|
||||
|
||||
- Make layouts mobile responsive by default.
|
||||
- Support dark and light mode unless the task clearly does not need both.
|
||||
- Keep components accessible.
|
||||
- Use a predictable spacing scale and consistent border radii.
|
||||
- Avoid emojis in the UI unless the user explicitly asks for them.
|
||||
|
||||
## Final Review
|
||||
|
||||
Before finishing, confirm that the interface has:
|
||||
|
||||
1. Clean whitespace
|
||||
2. Consistent spacing
|
||||
3. Readable typography
|
||||
4. Strong visual hierarchy
|
||||
5. Balanced layout
|
||||
6. Responsive behavior
|
||||
|
||||
If the result still looks generic or autogenerated, redesign it.
|
||||
Reference in New Issue
Block a user