44 lines
2.4 KiB
Markdown
44 lines
2.4 KiB
Markdown
# Tech Stack
|
|
|
|
- You are building a React application.
|
|
- Use TypeScript.
|
|
- Use React Router. KEEP the routes in src/App.tsx.
|
|
- Always put source code in the src folder.
|
|
- Put pages into src/pages/.
|
|
- Put components into src/components/.
|
|
- The main page (default page) is src/pages/Index.tsx.
|
|
- UPDATE the main page to include the new components. OTHERWISE, the user can NOT see any components!
|
|
- ALWAYS try to use the shadcn/ui library.
|
|
- Tailwind CSS: always use Tailwind CSS for styling components. Utilize Tailwind classes extensively for layout, spacing, colors, and other design aspects.
|
|
|
|
Available packages and libraries:
|
|
|
|
- The lucide-react package is installed for icons.
|
|
- You ALREADY have ALL the shadcn/ui components and their dependencies installed. So you don't need to install them again.
|
|
- You have ALL the necessary Radix UI components installed.
|
|
- Use prebuilt components from the shadcn/ui library after importing them. Note that these files shouldn't be edited, so make new components if you need to change them.
|
|
|
|
---
|
|
|
|
# Preservation & Safety Rules
|
|
|
|
- NEVER delete existing components, pages, or data structures unless explicitly instructed by the user.
|
|
- When modifying files, UPDATE existing code in place rather than rewriting the entire file unless unavoidable.
|
|
- Always preserve existing routes in `src/App.tsx`. Only ADD new routes; never remove existing ones unless explicitly requested.
|
|
- For database schemas or data models, NEVER remove or rename fields without explicit user confirmation. Only add or extend.
|
|
- Do not remove or overwrite existing styles, utility functions, or shared components. Extend or enhance them instead.
|
|
- If an update requires removing or replacing something, ASK the user for confirmation before making the change.
|
|
- Always show or describe a clear diff of proposed changes (what is added/modified vs. removed).
|
|
- Default behavior: PRESERVE existing functionality and UI. All changes should be additive unless instructed otherwise.
|
|
|
|
---
|
|
|
|
# Task List Management Rules
|
|
|
|
- Always create a task list of all steps needed to build the app.
|
|
- Provide feedback in the chat after each task is completed.
|
|
- Mark completed tasks on the task list once done.
|
|
- Add new tasks dynamically if additional steps are identified.
|
|
- Keep the task list up to date throughout the entire development process.
|
|
- Tasks should be actionable and clearly numbered or bulleted for easy tracking.
|
|
- The user should be able to see progress and completed tasks at a glance.
|