Cursor rule

1---
2description:
3globs:
4alwaysApply: false
5---
6# Update User Project Context File: .cursor/rules/_user-<username>.mdc
7 
8**Your primary task: Meticulously update the `./cursor/rules/_user-<username>.mdc` file. Use ONLY information found within the current project's files and documentation.**
9## Determine GitHub Username
10 
11Run the following to capture your authenticated GitHub username:
12```bash
13GH_USER=$( (gh api user --jq .login 2&gt;/dev/null || git config user.username || git config user.name) \
14  | tr '[:upper:]' '[:lower:]' \
15  | xargs \
16  | tr ' ' '-' \
17  | tr -d '\n' )
18```
19Then replace `<username>` in the file path with `$GH_USER`.
20 
21## File Existence Check
22 
23Quickly list potential configuration files and docs:
24 
25```bash
26ls . docs
27```
28 
29Use the output to see which files are available to read.
30 
31## 1. Core Objective
32 
33Your goal is to populate the `./cursor/rules/_user-<username>.mdc` file. This file must accurately reflect the project's current configuration, technology stack, structure, standards, and tooling, serving as a central project reference.
34 
35## 2. Information Gathering (Strictly from Project Sources)
36 
37Follow these steps precisely to gather the necessary information:
38 
39### Step 1: Analyze Project Root & Configuration Files:
40- List all files and directories in the project root.
41- Identify and thoroughly read relevant configuration files. Examples include (but are not limited to):
42    - Package management: `package.json`, `pnpm-lock.yaml`, `yarn.lock`, `pyproject.toml`, `poetry.lock`, `go.mod`, `pom.xml`, `build.gradle`, `Gemfile`, `composer.json`
43    - Build tools & bundlers: `webpack.config.js`, `vite.config.js`, `rollup.config.js`, `tsconfig.json` (check for `compilerOptions`, `extends`, etc.)
44    - Framework specific: `next.config.js`, `angular.json`, `vue.config.js`, `svelte.config.js`
45    - Linters & formatters: `.eslintrc.js`, `.eslintignore`, `.prettierrc.js`, `.prettierignore`, `biome.json`, `ruff.toml`, `.editorconfig`
46    - CI/CD: Files in `.github/workflows/`, `gitlab-ci.yml`, `Jenkinsfile`, `Dockerfile`
47    - Testing: `jest.config.js`, `vitest.config.js`, `cypress.json`, `playwright.config.js`
48- From these files, extract details about dependencies (and their versions), scripts (build, dev, test), language versions, tool configurations, and project settings.
49 
50### Step 2: Review Documentation and Key Code Directories:
51- 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.
52- Examine the structure of main source directories (e.g., `src/`, `app/`, `lib/`, `packages/`) to understand module organization and identify key architectural patterns.
53 
54## 3. Updating `./cursor/rules/_user-<username>.mdc`
55 
56### Step 3: Populate the Template:
57- Open the `./cursor/rules/_user-<username>.mdc` file for editing.
58- Using the information gathered in Steps 1 and 2, meticulously fill in each section of the template provided below.
59- **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).
60- **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.
61 
62## 4. Output Requirements
63 
64- Your SOLE output must be the fully updated content of the `./cursor/rules/_user-<username>.mdc` file.
65- Ensure the output is valid Markdown.
66 
67---
68**REMEMBER: Your objective is to produce an accurate, detailed, and comprehensive `./cursor/rules/_user-<username>.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.**
69---
70 
71## .cursor/rules/_user-<username>.mdc Template
72 
73Use this template as guide for creating the _user-<username>.mdc:
74 
75<template>
76---
77description:
78globs:
79alwaysApply: true
80---
81 
82# [Project Name] - Project Rules
83 
84## 1. Project Overview
85 
86goal: [Concisely describe the main purpose and goal of the project. What problem does it solve? Source from README or project vision docs.]
87type: [e.g., Web Application, CLI Tool, Library, Mobile App, Backend API, Monorepo. Determine from project structure and build files.]
88key features:
89- [core functionality or feature 1, derived from docs or main modules]
90- [core functionality or feature 2, derived from docs or main modules]
91- [core functionality or feature 3, derived from docs or main modules]
92 
93## 2. Technology Stack
94 
95language(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)]
96framework(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)]
97ui 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)]
98database(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)]
99state 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)]
100api layer: [e.g., REST (via Next.js API Routes/FastAPI), GraphQL (schema files, Apollo/Relay packages), tRPC (router definitions, client setup)]
101key libraries:
102- [critical dependency 1 (e.g., `axios` for HTTP, `date-fns` for dates - from package.json/pyproject.toml etc.)]
103- [critical dependency 2 (e.g., `zod` for validation, `pino` for logging)]
104 
105## 3. Project Structure
106 
107main source directory: [e.g., src/, app/, packages/ - identify primary code location]
108core directories: [Verify existence and common usage patterns]
109- components/: [e.g., Reusable UI elements - if applicable]
110- lib/ or utils/: [e.g., Shared utility functions - if applicable]
111- services/ or api/: [e.g., Business logic, API interactions - if applicable]
112- types/ or interfaces/: [e.g., Shared type definitions - if applicable]
113- db/ or prisma/ or drizzle/: [e.g., Database schema and access - if applicable]
114- tests/ or __tests__/: [e.g., Test files (if not co-located) - if applicable]
115diagram/link: [Link to an architecture diagram if found in docs/, or state "[N/A]". Do not generate one.]
116 
117## 4. Coding Standards & Conventions
118 
119language 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`.]
120naming conventions:
121- files/folders: [e.g., kebab-case, PascalCase - observe project files, check `CONTRIBUTING.md`]
122- components: [e.g., PascalCase (React/Vue/Svelte) - observe project files]
123- variables/functions: [e.g., camelCase, snake_case - observe project files, check linting rules]
124- types/interfaces: [e.g., PascalCase, TPrefix or IPrefix - observe project files, check `CONTRIBUTING.md`]
125code 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.]
126comments: [e.g., English only, JSDoc for public APIs, Minimal comments - check `CONTRIBUTING.md` or observe codebase patterns.]
127imports: [e.g., Absolute paths (@/ or tsconfig paths), Relative paths, Grouped/Sorted (check lint rules like eslint-plugin-import) - check `CONTRIBUTING.md`, linting config.]
128 
129## 5. Key Principles & Best Practices
130 
131[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:]
132- [e.g., DRY (Don't Repeat Yourself)]
133- [e.g., SOLID principles for OOP]
134- [e.g., Test-Driven Development (TDD)]
135 
136## 6. Testing
137 
138framework: [e.g., Jest, Vitest, Pytest, Go testing, Cypress, Playwright - from package.json, config files like jest.config.js]
139types: [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.]
140location: [e.g., Co-located with source files (e.g., `*.test.ts`, `*.spec.ts`), Top-level `tests/` directory - observe project structure.]
141coverage expectations: [e.g., Minimum 80% coverage (from CI config or `CONTRIBUTING.md`). If not found, state `[N/A]`.]
142 
143## 7. Tooling & Workflow
144 
145package 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.]
146build command(s): [e.g., `pnpm build`, `npm run build`, `make build` - from `package.json` scripts, `Makefile`, etc.]
147run command(s) (dev): [e.g., `pnpm dev`, `npm start`, `python main.py`, `go run ./cmd/...` - from `package.json` scripts, `Makefile`, `README.md`.]
148version 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).]
149ci/cd: [e.g., GitHub Actions (check `.github/workflows/`), GitLab CI (`.gitlab-ci.yml`), Jenkins (`Jenkinsfile`) - specify main jobs like lint, test, build on PR.]
150ide recommendations: [e.g., VS Code with specific extensions (check `.vscode/extensions.json`). If not found, state `[N/A]`.]
151 
152## 8. (Optional) Database / API Guidelines
153 
154[Source from `docs/database.md`, `docs/api_guidelines.md`, `CONTRIBUTING.md`, or inline comments in DB/API code. If none, state `[N/A]`.]
155- [e.g., Use ORM methods only, No direct SQL unless approved]
156- [e.g., RESTful principles for API design, specific error response format]
157- [e.g., Guidelines for database migrations (e.g., use Alembic, Prisma Migrate)]
158 
159## 9. (Optional) Specific Feature Rules
160 
161[Source from dedicated docs for complex features (e.g., `docs/authentication.md`, `docs/i18n.md`). If none, state `[N/A]`.]
162- [e.g., Authentication: JWT-based, specific token handling procedures]
163- [e.g., Internationalization (i18n): Use i18next, key naming conventions]
164- [e.g., State Management: Rules for creating new stores, selector patterns]
165 
166## 10. (Optional) Rule Referencing
167 
168[If this project uses other `.mdc` rule files, list them here. Check the `.cursor/rules/` directory. If none, state `[N/A]`.]
169- [e.g.,
170  - See [typescript.mdc](mdc:.cursor/rules/typescript.mdc) for detailed TS rules.
171  - Follow guidelines in [auth.mdc](mdc:.cursor/rules/auth.mdc) for authentication.
172  ]
173</template>
174 
175Remember: the frontmatter for `_user-<username>.mdc` must have alwaysApply set to true.
176 
177After outputting the completed `_user-<username>.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.
178