Cursor rule

1---
2description:
3globs:
4alwaysApply: false
5---
6# Update Project Context File: .cursor/rules/_project.mdc
7 
8**Your primary task: Meticulously update the `./cursor/rules/_project.mdc` file. Use ONLY information found within the current project's files and documentation.**
9 
10## File Existence Check
11 
12Quickly list potential configuration files and docs:
13 
14```bash
15ls . docs
16```
17 
18Use the output to see which files are available to read.
19 
20## 1. Core Objective
21 
22Your goal is to populate the `./cursor/rules/_project.mdc` file. This file must accurately reflect the project's current configuration, technology stack, structure, standards, and tooling, serving as a central project reference.
23 
24## 2. Information Gathering (Strictly from Project Sources)
25 
26Follow these steps precisely to gather the necessary information:
27 
28### Step 1: Analyze Project Root & Configuration Files:
29- List all files and directories in the project root.
30- Identify and thoroughly read relevant configuration files. Examples include (but are not limited to):
31    - Package management: `package.json`, `pnpm-lock.yaml`, `yarn.lock`, `pyproject.toml`, `poetry.lock`, `go.mod`, `pom.xml`, `build.gradle`, `Gemfile`, `composer.json`
32    - Build tools & bundlers: `webpack.config.js`, `vite.config.js`, `rollup.config.js`, `tsconfig.json` (check for `compilerOptions`, `extends`, etc.)
33    - Framework specific: `next.config.js`, `angular.json`, `vue.config.js`, `svelte.config.js`
34    - Linters & formatters: `.eslintrc.js`, `.eslintignore`, `.prettierrc.js`, `.prettierignore`, `biome.json`, `ruff.toml`, `.editorconfig`
35    - CI/CD: Files in `.github/workflows/`, `gitlab-ci.yml`, `Jenkinsfile`, `Dockerfile`
36    - Testing: `jest.config.js`, `vitest.config.js`, `cypress.json`, `playwright.config.js`
37- From these files, extract details about dependencies (and their versions), scripts (build, dev, test), language versions, tool configurations, and project settings.
38 
39### Step 2: Review Documentation and Key Code Directories:
40- Thoroughly read all files located within the `docs/` directory (and its subdirectories). Prioritize `README.md`, `CONTRIBUTING.md`, architecture diagrams, technical specifications, or any documents describing the project's setup, conventions, and purpose.
41- Examine the structure of main source directories (e.g., `src/`, `app/`, `lib/`, `packages/`) to understand module organization and identify key architectural patterns.
42 
43## 3. Updating `./cursor/rules/_project.mdc`
44 
45### Step 3: Populate the Template:
46- Open the `./cursor/rules/_project.mdc` file for editing.
47- Using the information gathered in Steps 1 and 2, meticulously fill in each section of the template provided below.
48- **Crucial:** Adhere strictly to the template's structure and placeholders. Provide specific examples and details where requested (e.g., actual library names, version numbers, file paths).
49- **Handling Missing Information:** If, after thorough investigation, specific information required by the template cannot be definitively found within the project's files or `docs/` directory, explicitly state `[Information not found in project context]` or `[N/A]` in the corresponding field. **ABSOLUTELY DO NOT invent, infer, or use external knowledge.** It is critical to indicate missing information rather than provide incorrect data.
50 
51## 4. Output Requirements
52 
53- Your SOLE output must be the fully updated content of the `./cursor/rules/_project.mdc` file.
54- Ensure the output is valid Markdown.
55 
56---
57**REMEMBER: Your objective is to produce an accurate, detailed, and comprehensive `./cursor/rules/_project.mdc` file. This file MUST be populated using *only* information extracted directly from THIS project's codebase and its documentation. Adhere strictly to the provided template. After updating the file with all available project-specific information (or marking details as 'not found'), your task is complete.**
58---
59 
60## .cursor/rules/_project.mdc Template
61 
62Use this template as guide for creating the _project.mdc:
63 
64<template>
65---
66description:
67globs:
68alwaysApply: true
69---
70 
71# [Project Name] - Project Rules
72 
73## 1. Project Overview
74 
75goal: [Concisely describe the main purpose and goal of the project. What problem does it solve? Source from README or project vision docs.]
76type: [e.g., Web Application, CLI Tool, Library, Mobile App, Backend API, Monorepo. Determine from project structure and build files.]
77key features:
78- [core functionality or feature 1, derived from docs or main modules]
79- [core functionality or feature 2, derived from docs or main modules]
80- [core functionality or feature 3, derived from docs or main modules]
81 
82## 2. Technology Stack
83 
84language(s): [e.g., TypeScript 5.x (from tsconfig.json or package.json), Python 3.11 (from pyproject.toml or runtime checks), Go 1.23 (from go.mod), Java 17 (from pom.xml or build.gradle)]
85framework(s): [e.g., Next.js 15 (App Router - check next.config.js, package.json), React 19 (package.json), FastAPI (pyproject.toml, main app file), Spring Boot (pom.xml), SvelteKit (svelte.config.js)]
86ui library/styling: [e.g., Tailwind CSS v4 (tailwind.config.js, package.json), Shadcn UI (components.json, registry), Material UI (package.json), CSS Modules (file extensions, build config)]
87database(s): [e.g., PostgreSQL via Prisma (schema.prisma, package.json), MongoDB (connection strings, package.json), Supabase (config, client usage), SQLite via Drizzle (drizzle.config.js, package.json)]
88state management: [e.g., Zustand (package.json, store files), React Context (usage in components), Redux (package.json, store setup), Pinia (package.json, store setup), None (Local State - if no dedicated library found)]
89api layer: [e.g., REST (via Next.js API Routes/FastAPI), GraphQL (schema files, Apollo/Relay packages), tRPC (router definitions, client setup)]
90key libraries:
91- [critical dependency 1 (e.g., `axios` for HTTP, `date-fns` for dates - from package.json/pyproject.toml etc.)]
92- [critical dependency 2 (e.g., `zod` for validation, `pino` for logging)]
93 
94## 3. Project Structure
95 
96main source directory: [e.g., src/, app/, packages/ - identify primary code location]
97core directories: [Verify existence and common usage patterns]
98- components/: [e.g., Reusable UI elements - if applicable]
99- lib/ or utils/: [e.g., Shared utility functions - if applicable]
100- services/ or api/: [e.g., Business logic, API interactions - if applicable]
101- types/ or interfaces/: [e.g., Shared type definitions - if applicable]
102- db/ or prisma/ or drizzle/: [e.g., Database schema and access - if applicable]
103- tests/ or __tests__/: [e.g., Test files (if not co-located) - if applicable]
104diagram/link: [Link to an architecture diagram if found in docs/, or state "[N/A]". Do not generate one.]
105 
106## 4. Coding Standards & Conventions
107 
108language usage: [e.g., Prefer functional components (React), Use async/await (JS/TS), Strict TypeScript mode (tsconfig.json `strict: true`), Avoid `any` (TS lint rules). Source from linting configs, `CONTRIBUTING.md`.]
109naming conventions:
110- files/folders: [e.g., kebab-case, PascalCase - observe project files, check `CONTRIBUTING.md`]
111- components: [e.g., PascalCase (React/Vue/Svelte) - observe project files]
112- variables/functions: [e.g., camelCase, snake_case - observe project files, check linting rules]
113- types/interfaces: [e.g., PascalCase, TPrefix or IPrefix - observe project files, check `CONTRIBUTING.md`]
114code style/formatting: [e.g., Prettier (check .prettierrc, package.json scripts), ESLint (check .eslintrc, package.json scripts), Ruff (ruff.toml), Biome (biome.json) - mention config file if present.]
115comments: [e.g., English only, JSDoc for public APIs, Minimal comments - check `CONTRIBUTING.md` or observe codebase patterns.]
116imports: [e.g., Absolute paths (@/ or tsconfig paths), Relative paths, Grouped/Sorted (check lint rules like eslint-plugin-import) - check `CONTRIBUTING.md`, linting config.]
117 
118## 5. Key Principles & Best Practices
119 
120[Source these from `CONTRIBUTING.md`, `README.md`, or high-level design documents in `docs/`. If none explicitly stated, mark as `[No explicit principles documented]`. Examples:]
121- [e.g., DRY (Don't Repeat Yourself)]
122- [e.g., SOLID principles for OOP]
123- [e.g., Test-Driven Development (TDD)]
124 
125## 6. Testing
126 
127framework: [e.g., Jest, Vitest, Pytest, Go testing, Cypress, Playwright - from package.json, config files like jest.config.js]
128types: [e.g., Unit tests required for services (from `CONTRIBUTING.md`), Integration tests for API endpoints, E2E with Playwright/Cypress - from `CONTRIBUTING.md` or test file structure.]
129location: [e.g., Co-located with source files (e.g., `*.test.ts`, `*.spec.ts`), Top-level `tests/` directory - observe project structure.]
130coverage expectations: [e.g., Minimum 80% coverage (from CI config or `CONTRIBUTING.md`). If not found, state `[N/A]`.]
131 
132## 7. Tooling & Workflow
133 
134package manager: [e.g., pnpm (pnpm-lock.yaml), npm (package-lock.json), yarn (yarn.lock), bun (bun.lockb), poetry (poetry.lock), uv (uv.lock) - identify from lockfile or project setup docs.]
135build command(s): [e.g., `pnpm build`, `npm run build`, `make build` - from `package.json` scripts, `Makefile`, etc.]
136run command(s) (dev): [e.g., `pnpm dev`, `npm start`, `python main.py`, `go run ./cmd/...` - from `package.json` scripts, `Makefile`, `README.md`.]
137version control: [e.g., Git. Check for Conventional Commits (commitlint.config.js, `CONTRIBUTING.md`), PRs to `main`/`master` branch (from `CONTRIBUTING.md` or repo settings if accessible).]
138ci/cd: [e.g., GitHub Actions (check `.github/workflows/`), GitLab CI (`.gitlab-ci.yml`), Jenkins (`Jenkinsfile`) - specify main jobs like lint, test, build on PR.]
139ide recommendations: [e.g., VS Code with specific extensions (check `.vscode/extensions.json`). If not found, state `[N/A]`.]
140 
141## 8. (Optional) Database / API Guidelines
142 
143[Source from `docs/database.md`, `docs/api_guidelines.md`, `CONTRIBUTING.md`, or inline comments in DB/API code. If none, state `[N/A]`.]
144- [e.g., Use ORM methods only, No direct SQL unless approved]
145- [e.g., RESTful principles for API design, specific error response format]
146- [e.g., Guidelines for database migrations (e.g., use Alembic, Prisma Migrate)]
147 
148## 9. (Optional) Specific Feature Rules
149 
150[Source from dedicated docs for complex features (e.g., `docs/authentication.md`, `docs/i18n.md`). If none, state `[N/A]`.]
151- [e.g., Authentication: JWT-based, specific token handling procedures]
152- [e.g., Internationalization (i18n): Use i18next, key naming conventions]
153- [e.g., State Management: Rules for creating new stores, selector patterns]
154 
155## 10. (Optional) Rule Referencing
156 
157[If this project uses other `.mdc` rule files, list them here. Check the `.cursor/rules/` directory. If none, state `[N/A]`.]
158- [e.g.,
159  - See [typescript.mdc](mdc:.cursor/rules/typescript.mdc) for detailed TS rules.
160  - Follow guidelines in [auth.mdc](mdc:.cursor/rules/auth.mdc) for authentication.
161  ]
162</template>
163 
164Remember: the frontmatter for `_project.mdc` must have alwaysApply set to true.
165 
166After outputting the completed `_project.mdc` file, provide a concise executive summary of the major sections you filled in or updated. Keep this summary separate from the file content so the user can quickly review the changes.
167