update build scripts and prompt,s
This commit is contained in:
44
002_source/cms/_AI_WORKSPACE/code/001_INIT.md
Normal file
44
002_source/cms/_AI_WORKSPACE/code/001_INIT.md
Normal file
@@ -0,0 +1,44 @@
|
||||
# AI GUIDELINE
|
||||
|
||||
## getting started
|
||||
|
||||
Imagine there is a:
|
||||
|
||||
1. developer (provide the modification)
|
||||
2. QA engineer (provide the feedback, and testing)
|
||||
3. software engineer
|
||||
4. technical writer
|
||||
|
||||
they will:
|
||||
|
||||
- conclude and integrate the ideas from developer and QA engineer
|
||||
- make decision to modify the code accordingly.
|
||||
|
||||
## project background and initial setup
|
||||
|
||||
- No need to reply me what you are going on and your digest in this phase.
|
||||
Just reply me "OK" when done
|
||||
|
||||
- base_dir=`/home/logic/_wsl_workspace/001_github_ws/lettersoup-online-ws/lettersoup-online/project`
|
||||
|
||||
- `schema.dbml`
|
||||
|
||||
- read `<base_dir>/001_documentation/Requirements/REQ0006/schema.dbml`
|
||||
this is file in `dbml` format stating the main database structure
|
||||
|
||||
- `schema.json`
|
||||
|
||||
- read `<base_dir>/002_source/cms/src/db/schema.json`
|
||||
this is the file of current pocketbase schema
|
||||
|
||||
- read `<base_dir>/002_source/cms/src/constants.ts`
|
||||
this is the content of `@/constants`
|
||||
|
||||
- look into the md files in folder `<base_dir>/002_source/cms/_AI_WORKSPACE/001_guideline`
|
||||
|
||||
- directory may contain `repomix-output.xml` file, that is a simple summary of all files inside the directory
|
||||
|
||||
- if the directory user provided contins `_GUIDELINES.md`, please read the file
|
||||
|
||||
- read the files, remember and link up the ideas in file stated above,
|
||||
i will tell them the task afterwards
|
52
002_source/cms/_AI_WORKSPACE/code/002_nextjs.mdc
Normal file
52
002_source/cms/_AI_WORKSPACE/code/002_nextjs.mdc
Normal file
@@ -0,0 +1,52 @@
|
||||
---
|
||||
description: Next.js with TypeScript and Tailwind UI best practices
|
||||
globs: **/*.tsx, **/*.ts, src/**/*.ts, src/**/*.tsx
|
||||
---
|
||||
|
||||
# Next.js Best Practices
|
||||
|
||||
## Project Structure
|
||||
- Use the App Router directory structure
|
||||
- Place components in `app` directory for route-specific components
|
||||
- Place shared components in `components` directory
|
||||
- Place utilities and helpers in `lib` directory
|
||||
- Use lowercase with dashes for directories (e.g., `components/auth-wizard`)
|
||||
|
||||
## Components
|
||||
- Use Server Components by default
|
||||
- Mark client components explicitly with 'use client'
|
||||
- Wrap client components in Suspense with fallback
|
||||
- Use dynamic loading for non-critical components
|
||||
- Implement proper error boundaries
|
||||
- Place static content and interfaces at file end
|
||||
|
||||
## Performance
|
||||
- Optimize images: Use WebP format, size data, lazy loading
|
||||
- Minimize use of 'useEffect' and 'setState'
|
||||
- Favor Server Components (RSC) where possible
|
||||
- Use dynamic loading for non-critical components
|
||||
- Implement proper caching strategies
|
||||
|
||||
## Data Fetching
|
||||
- Use Server Components for data fetching when possible
|
||||
- Implement proper error handling for data fetching
|
||||
- Use appropriate caching strategies
|
||||
- Handle loading and error states appropriately
|
||||
|
||||
## Routing
|
||||
- Use the App Router conventions
|
||||
- Implement proper loading and error states for routes
|
||||
- Use dynamic routes appropriately
|
||||
- Handle parallel routes when needed
|
||||
|
||||
## Forms and Validation
|
||||
- Use Zod for form validation
|
||||
- Implement proper server-side validation
|
||||
- Handle form errors appropriately
|
||||
- Show loading states during form submission
|
||||
|
||||
## State Management
|
||||
- Minimize client-side state
|
||||
- Use React Context sparingly
|
||||
- Prefer server state when possible
|
||||
- Implement proper loading states
|
57
002_source/cms/_AI_WORKSPACE/code/003_typescript.mdc
Normal file
57
002_source/cms/_AI_WORKSPACE/code/003_typescript.mdc
Normal file
@@ -0,0 +1,57 @@
|
||||
---
|
||||
description: TypeScript coding standards and best practices for modern web development
|
||||
globs: **/*.ts, **/*.tsx, **/*.d.ts
|
||||
---
|
||||
|
||||
# TypeScript Best Practices
|
||||
|
||||
## Type System
|
||||
- Prefer interfaces over types for object definitions
|
||||
- Use type for unions, intersections, and mapped types
|
||||
- Avoid using `any`, prefer `unknown` for unknown types
|
||||
- Use strict TypeScript configuration
|
||||
- Leverage TypeScript's built-in utility types
|
||||
- Use generics for reusable type patterns
|
||||
|
||||
## Naming Conventions
|
||||
- Use PascalCase for type names and interfaces
|
||||
- Use camelCase for variables and functions
|
||||
- Use UPPER_CASE for constants
|
||||
- Use descriptive names with auxiliary verbs (e.g., isLoading, hasError)
|
||||
- Prefix interfaces for React props with 'Props' (e.g., ButtonProps)
|
||||
|
||||
## Code Organization
|
||||
- Keep type definitions close to where they're used
|
||||
- Export types and interfaces from dedicated type files when shared
|
||||
- Use barrel exports (index.ts) for organizing exports
|
||||
- Place shared types in a `types` directory
|
||||
- Co-locate component props with their components
|
||||
|
||||
## Functions
|
||||
- Use explicit return types for public functions
|
||||
- Use arrow functions for callbacks and methods
|
||||
- Implement proper error handling with custom error types
|
||||
- Use function overloads for complex type scenarios
|
||||
- Prefer async/await over Promises
|
||||
|
||||
## Best Practices
|
||||
- Enable strict mode in tsconfig.json
|
||||
- Use readonly for immutable properties
|
||||
- Leverage discriminated unions for type safety
|
||||
- Use type guards for runtime type checking
|
||||
- Implement proper null checking
|
||||
- Avoid type assertions unless necessary
|
||||
|
||||
## Error Handling
|
||||
- Create custom error types for domain-specific errors
|
||||
- Use Result types for operations that can fail
|
||||
- Implement proper error boundaries
|
||||
- Use try-catch blocks with typed catch clauses
|
||||
- Handle Promise rejections properly
|
||||
|
||||
## Patterns
|
||||
- Use the Builder pattern for complex object creation
|
||||
- Implement the Repository pattern for data access
|
||||
- Use the Factory pattern for object creation
|
||||
- Leverage dependency injection
|
||||
- Use the Module pattern for encapsulation
|
Reference in New Issue
Block a user