diff --git a/.github/CODEOWNERS b/.github/CODEOWNERS new file mode 100644 index 00000000..f1ff08b9 --- /dev/null +++ b/.github/CODEOWNERS @@ -0,0 +1,4 @@ +# Require maintainer review for repository automation and policy controls. +.github/workflows/** @PatrickJS +scripts/** @PatrickJS +.github/CODEOWNERS @PatrickJS diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml index 1ffa9d60..c9664cc4 100644 --- a/.github/workflows/main.yml +++ b/.github/workflows/main.yml @@ -6,6 +6,9 @@ on: push: branches: [main] +permissions: + contents: read + jobs: repo-hygiene: runs-on: ubuntu-latest @@ -72,5 +75,18 @@ jobs: git diff --name-only "$base"...HEAD > .changed-files git diff --unified=0 "$base"...HEAD -- README.md > .readme.diff || true + - name: Checkout trusted base checks + if: github.event_name == 'pull_request' + uses: actions/checkout@v4 + with: + ref: ${{ github.event.pull_request.base.sha }} + path: .trusted-base + fetch-depth: 1 + + - name: Run trusted repo hygiene checks + if: github.event_name == 'pull_request' + run: node .trusted-base/scripts/check-repo-hygiene.mjs --root "$GITHUB_WORKSPACE" --changed-files .changed-files --diff-file .readme.diff + - name: Run repo hygiene checks + if: github.event_name != 'pull_request' run: node scripts/check-repo-hygiene.mjs --changed-files .changed-files --diff-file .readme.diff diff --git a/README.md b/README.md index a64691b4..48ed12c6 100644 --- a/README.md +++ b/README.md @@ -72,6 +72,8 @@ By creating a `.cursorrules` file in your project's root directory, you can leve - [How to Use](#how-to-use) - [Method One](#method-one) - [Method Two](#method-two) + - [Method Three: Cursor .mdc Rule Files](#method-three-cursor-mdc-rule-files) + - [Monorepos and Multiple Rule Files](#monorepos-and-multiple-rule-files) - [Contributing](#contributing) - [Sponsorships](#sponsorships-1) - [License](#license) @@ -107,6 +109,7 @@ By creating a `.cursorrules` file in your project's root directory, you can leve - [React Components Creation](./rules/react-components-creation-cursorrules-prompt-file/.cursorrules) - Cursor rules for React component creation and development. - [React (FormEngine AI Form Builder)](./rules/react-formengine-ai-form-builder-cursorrules-prompt-file/.cursorrules) - Cursor rules for generating React forms from screenshots, PDFs, HTML, or text descriptions with validated FormEngine JSON schema. Renders through RSuite, Material UI, or Mantine. - [React (Next.js UI Development)](./rules/react-nextjs-ui-development-cursorrules-prompt-fil/.cursorrules) - Cursor rules for React development with Next.js UI integration. +- [React Router v7](./rules-new/react-router-v7.mdc) - Cursor rules for React Router v7 framework mode, data routers, loaders, actions, route modules, and progressive enhancement. - [React (TypeScript, Next.js, Node.js)](./rules/react-typescript-nextjs-nodejs-cursorrules-prompt-/.cursorrules) - Cursor rules for React development with TypeScript, Next.js, and Node.js integration. - [React (TypeScript, Symfony)](./rules/react-typescript-symfony-cursorrules-prompt-file/.cursorrules) - Cursor rules for React development with TypeScript and Symfony integration. - [Semiotic (React, D3, Data Visualization)](./rules/semiotic-react-dataviz-cursorrules-prompt-file/.cursorrules) - Cursor rules for Semiotic data visualization library with 30+ chart types, MCP server, and AI-assisted chart generation. @@ -138,6 +141,7 @@ By creating a `.cursorrules` file in your project's root directory, you can leve - [Go (Basic Setup)](./rules/htmx-go-basic-cursorrules-prompt-file/.cursorrules) - Cursor rules for Go development with basic setup. - [Go with Fiber](./rules/htmx-go-fiber-cursorrules-prompt-file/.cursorrules) - Cursor rules for Go development with Fiber integration. - [Go Temporal DSL](./rules/go-temporal-dsl-prompt-file/.cursorrules) - Cursor rules for Go development with Temporal DSL integration. +- [Google ADK](./rules-new/google-adk.mdc) - Cursor rules for Google Agent Development Kit agents, tools, sessions, memory, artifacts, evaluation, and deployment. - [HOL (Hedera TypeScript SDK)](./rules/hol-hedera-typescript-cursorrules-prompt-file/.cursorrules) - Cursor rules for Hashgraph Online development with TypeScript, building AI agents on Hedera with RegistryBrokerClient. - [HTMX (Basic Setup)](./rules/htmx-basic-cursorrules-prompt-file/.cursorrules) - Cursor rules for HTMX development with basic setup. - [HTMX (Flask)](./rules/htmx-flask-cursorrules-prompt-file/.cursorrules) - Cursor rules for HTMX development with Flask integration. @@ -153,7 +157,6 @@ By creating a `.cursorrules` file in your project's root directory, you can leve - [Node.js (MongoDB, JWT, Express, React)](./rules/nodejs-mongodb-jwt-express-react-cursorrules-promp/.cursorrules) - Cursor rules for Node.js development with MongoDB, JWT, Express, and React integration. - [Rails 8 (Basic Setup)](./rules/rails-cursorrules-prompt-file/rails-basics.mdx) - Cursor rules for Rails development with basic setup. - [Python (FastAPI)](./rules/py-fast-api/.cursorrules) - Cursor rules for Python FastAPI backend development and best practices. -- [Python (FastAPI)](./rules/cursorrules-file-cursor-ai-python-fastapi-api/.cursorrules) - Cursor rules for Python FastAPI development with API integration. - [Python 3.12 (FastAPI Best Practices)](./rules/python-312-fastapi-best-practices-cursorrules-prom/.cursorrules) - Cursor rules for Python FastAPI development with best practices. - [Python (Django Best Practices)](./rules/python-django-best-practices-cursorrules-prompt-fi/.cursorrules) - Cursor rules for Python Django development with best practices. - [Python (FastAPI Best Practices)](./rules/python-fastapi-best-practices-cursorrules-prompt-f/.cursorrules) - Cursor rules for Python FastAPI development with best practices. @@ -175,6 +178,7 @@ By creating a `.cursorrules` file in your project's root directory, you can leve - [Android Native (Jetpack Compose)](./rules/android-jetpack-compose-cursorrules-prompt-file/.cursorrules) - Cursor rules for Android development with Jetpack Compose integration. - [Cursor Rules Pack v2](./rules/cursor-rules-pack-v2-cursorrules-prompt-file/.cursorrules) - 7 sample production-tested rules (dependency discipline, error handling, state management, webhook security, and more). See the pack README for full-pack details. - [Flutter Expert](./rules/flutter-app-expert-cursorrules-prompt-file/.cursorrules) - Cursor rules for Flutter development with expert integration. +- [HarmonyOS ArkTS](./rules-new/harmony-arkts.mdc) - Cursor rules for HarmonyOS ArkTS components, state, resources, lifecycle, layout, and accessibility. - [NativeScript](./rules/nativescript-cursorrules-prompt-file/.cursorrules) - Cursor rules for NativeScript development. - [React Native Expo](./rules/react-native-expo-cursorrules-prompt-file/.cursorrules) - Cursor rules for React Native Expo development. - [SwiftUI Guidelines](./rules/swiftui-guidelines-cursorrules-prompt-file/.cursorrules) - Cursor rules for SwiftUI development guidelines. @@ -184,7 +188,9 @@ By creating a `.cursorrules` file in your project's root directory, you can leve ### Games and Graphics - [ASCII Simulation Game](./rules/ascii-simulation-game-cursorrules-prompt-file/.cursorrules) - Cursor rules for ASCII simulation game development. +- [Blender Python Add-ons](./rules-new/blender-python-addon.mdc) - Cursor rules for Blender Python add-ons, operators, panels, properties, registration, and API-safe scripting. - [DragonRuby Best Practices](./rules/dragonruby-best-practices-cursorrules-prompt-file/.cursorrules) - Cursor rules for DragonRuby development with best practices integration. +- [GameMaker GML](./rules-new/gamemaker-gml.mdc) - Cursor rules for GameMaker Language projects, objects, events, rooms, data structures, and performance-minded gameplay code. - [Graphical Apps Development](./rules/graphical-apps-development-cursorrules-prompt-file/.cursorrules) - Cursor rules for graphical apps development with integration. - [Unity (C#)](./rules/unity-cursor-ai-c-cursorrules-prompt-file/.cursorrules) - Cursor rules for Unity development with C# integration. @@ -199,6 +205,7 @@ By creating a `.cursorrules` file in your project's root directory, you can leve - [React (Styled Components)](./rules/react-styled-components-cursorrules-prompt-file/.cursorrules) - Cursor rules for React development with Styled Components integration. - [React (Chakra UI)](./rules/react-chakra-ui-cursorrules-prompt-file/.cursorrules) - Cursor rules for React development with Chakra UI integration. - [RTL / Right-to-Left (i18n, Tailwind, React Native)](./rules/rtl-right-to-left-i18n-cursorrules-prompt-file/.cursorrules) - Cursor rules for RTL development with logical CSS properties, Tailwind logical classes, bidirectional text, and automated auditing via rtlify-ai. +- [Toss-Style Design System](./rules-new/toss-style-design-system.mdc) - Cursor rules for disciplined product UI with restrained color, grayscale hierarchy, typography, cards, metrics, dark mode, and accessibility. ### State Management @@ -252,6 +259,7 @@ By creating a `.cursorrules` file in your project's root directory, you can leve - [Code Guidelines](./rules/code-guidelines-cursorrules-prompt-file/.cursorrules) - Cursor rules for code development with guidelines integration. - [Code Pair Interviews](./rules/code-pair-interviews/.cursorrules) - Cursor rules for code pair interviews development with integration. - [Code Style Consistency](./rules/code-style-consistency-cursorrules-prompt-file/.cursorrules) - Cursor rules for code development with style consistency integration. +- [Embedded MCU / STM32 / HAL](./rules-new/embedded-stm32-hal.mdc) - Cursor rules for embedded C/C++ development with STM32 HAL, interrupts, DMA, memory constraints, and hardware-focused testing. - [Engineering Ticket Template](./rules/engineering-ticket-template-cursorrules-prompt-file/.cursorrules) - Cursor rules for engineering development with ticket template integration. - [GitHub Code Quality](./rules/github-code-quality-cursorrules-prompt-file/.cursorrules) - Cursor rules for GitHub development with code quality integration. - [GitHub Instructions](./rules/github-cursorrules-prompt-file-instructions/.cursorrules) - Cursor rules for GitHub development with instructions integration. @@ -262,6 +270,7 @@ By creating a `.cursorrules` file in your project's root directory, you can leve - [Project Epic Template](./rules/project-epic-template-cursorrules-prompt-file/.cursorrules) - Cursor rules for project development with epic template integration. - [Python Containerization](./rules/python-containerization-cursorrules-prompt-file/.cursorrules) - Cursor rules for Python development with containerization integration. - [Python (GitHub Setup)](./rules/python-github-setup-cursorrules-prompt-file/.cursorrules) - Cursor rules for Python development with GitHub setup integration. +- [ROS / ROS2](./rules-new/ros-ros2.mdc) - Cursor rules for ROS and ROS2 packages, nodes, launch files, messages, services, actions, simulation, and testing. - [Tauri (Svelte, TypeScript Guide)](./rules/tauri-svelte-typescript-guide-cursorrules-prompt-f/.cursorrules) - Cursor rules for Tauri development with Svelte and TypeScript guide integration. - [TypeScript Code Convention](./rules/typescript-code-convention-cursorrules-prompt-file/.cursorrules) - Cursor rules for TypeScript development with code convention integration. - [VSCode Extension (Electron/TypeScript)](./rules/chrome-extension-dev-js-typescript-cursorrules-pro/.cursorrules) - Cursor rules for VSCode extension development with Electron and TypeScript integration. @@ -270,6 +279,8 @@ By creating a `.cursorrules` file in your project's root directory, you can leve ### Language-Specific +- [AutoML and Hyperparameter Optimization](./rules-new/automl-hyperparameter-optimization.mdc) - Cursor rules for Python ML model search, validation design, search spaces, experiment tracking, and time-series AutoML. +- [Fortran](./rules-new/fortran.mdc) - Cursor rules for modern Fortran scientific computing, modules, explicit interfaces, kind parameters, memory safety, and testing. - [JavaScript/TypeScript Code Quality](./rules/javascript-typescript-code-quality-cursorrules-pro/.cursorrules) - Cursor rules for JavaScript and TypeScript development with code quality integration. - [JavaScript (Chrome APIs)](./rules/javascript-chrome-apis-cursorrules-prompt-file/.cursorrules) - Cursor rules for JavaScript development with Chrome APIs integration. - [Optimize (Rell Blockchain Code)](./rules/optimize-rell-blockchain-code-cursorrules-prompt-f/.cursorrules) - Cursor rules for optimization development with Rell Blockchain code integration. @@ -283,6 +294,7 @@ By creating a `.cursorrules` file in your project's root directory, you can leve - [PySpark ETL Best Practices](./rules/pyspark-etl-best-practices-cursorrules-prompt-file/.cursorrules) - Cursor rules for PySpark ETL development with code style, joins, window functions, map operations, and Iceberg patterns. - [PyTorch (scikit-learn)](./rules/pytorch-scikit-learn-cursorrules-prompt-file/.cursorrules) - Cursor rules for PyTorch development with scikit-learn integration. - [R Best Practices](./rules/r-cursorrules-prompt-file-best-practices/.cursorrules) - Cursor rules for R development with best practices integration. +- [Rust](./rules-new/rust-general.mdc) - Cursor rules for safe, idiomatic Rust application and library development. - [Solidity (Foundry)](./rules/solidity-foundry-cursorrules-prompt-file/.cursorrules) - Cursor rules for Solidity development with Foundry integration. - [Solidity (Hardhat)](./rules/solidity-hardhat-cursorrules-prompt-file/.cursorrules) - Cursor rules for Solidity development with Hardhat integration. - [Solidity (React Blockchain Apps)](./rules/solidity-react-blockchain-apps-cursorrules-prompt-/.cursorrules) - Cursor rules for Solidity development with React Blockchain apps integration. @@ -306,6 +318,7 @@ By creating a `.cursorrules` file in your project's root directory, you can leve - [TypeScript (React)](./rules/typescript-react-cursorrules-prompt-file/.cursorrules) - Cursor rules for TypeScript development with React integration. - [TypeScript (Clasp App Script)](./rules/typescript-clasp-cursorrules-prompt-file/.cursorrules) - Cursor rules for TypeScript development with Clasp app script integration. - [C++ Programming Guidelines](./rules/cpp-programming-guidelines-cursorrules-prompt-file/.cursorrules) - Cursor rules for C++ development with programming guidelines integration. +- [TensorFlow and Deep Learning](./rules-new/tensorflow-deep-learning.mdc) - Cursor rules for TensorFlow model development, training, evaluation, export, and deployment. ### Security @@ -334,10 +347,23 @@ By creating a `.cursorrules` file in your project's root directory, you can leve ### Method Two 1. Install [Cursor AI](https://cursor.sh/) if you haven't already. -2. Install [vscode-cursor-rules](https://marketplace.visualstudio.com/items?itemName=BeilunYang.cursor-rules) extension. -3. Open the command palette (Cmd+Shift+P or Ctrl+Shift+P) and type `Cursor Rules: Add .cursorrules`. -4. Select and download the `.cursorrules` file that suits your needs. -5. Customize the rules as needed for your specific project requirements. +2. Open the command palette (Cmd+Shift+P or Ctrl+Shift+P) and run `New Cursor Rule`. +3. Copy the relevant guidance from this repository into the generated project rule. +4. Customize the rule as needed for your specific project requirements. + +### Method Three: Cursor .mdc Rule Files + +1. Follow the [Cursor project rules documentation](https://docs.cursor.com/context/rules) or create a `.cursor/rules/` directory in your project. +2. Copy only the relevant `.mdc` files into `.cursor/rules/`. +3. Keep each `.mdc` file's frontmatter so Cursor can apply it by `globs` and `alwaysApply`. +4. Prefer focused `.mdc` files for framework-specific or directory-specific guidance. +5. Use one broad `.cursorrules` file only when you need legacy compatibility or a single global rule file. + +### Monorepos and Multiple Rule Files + +For monorepos, prefer `.cursor/rules/*.mdc` files with scoped `globs` so rules apply only to the packages that need them. Put shared engineering rules in one workspace-level `.mdc` file, then add package-specific files such as `apps/web` frontend rules, `apps/api` backend rules, or `packages/ui` design-system rules. + +You usually do not need both a copied `.cursorrules` file and every `.mdc` file from the same ruleset. Choose the format your Cursor version and project layout use best, then copy the smallest set of rules that matches your stack. ## Contributing diff --git a/rules-new/automl-hyperparameter-optimization.mdc b/rules-new/automl-hyperparameter-optimization.mdc new file mode 100644 index 00000000..a663a30d --- /dev/null +++ b/rules-new/automl-hyperparameter-optimization.mdc @@ -0,0 +1,55 @@ +--- +description: AutoML and hyperparameter optimization rules for Python ML projects using Ray Tune, Optuna, PyCaret, and time-series AutoML libraries +globs: ["**/*.py", "**/*.ipynb", "pyproject.toml", "requirements*.txt", "environment*.yml"] +alwaysApply: false +--- + +# AutoML and Hyperparameter Optimization Rules + +## Scope + +- Use AutoML to accelerate model exploration, not to bypass problem framing, validation design, or explainability. +- Start with a simple baseline model and fixed metric before launching a search. +- Keep training, evaluation, feature generation, and search configuration separate. +- Record datasets, splits, metric definitions, random seeds, library versions, and search spaces for every run. + +## Experiment Design + +- Define the target metric before selecting tooling. +- Use nested validation or a final untouched test split for model selection claims. +- Use time-aware splits for time-series problems; never shuffle across time boundaries. +- Prevent leakage by fitting preprocessing only on training folds. +- Include simple baselines such as linear models, random forests, or naive time-series forecasts. +- Use early stopping and resource limits for expensive searches. +- Prefer structured search spaces with domain-informed ranges over arbitrary broad grids. + +## Tooling + +- Use Ray Tune or Optuna for custom training loops, distributed trials, pruning, and scheduler control. +- Use PyCaret for quick low-code comparisons when the dataset and metric are straightforward. +- Use AutoTS, Merlion, PyAF, or project-approved time-series tooling when forecast-specific validation, seasonality, and horizon handling matter. +- Store run metadata in MLflow, Weights & Biases, TensorBoard, or a project-approved tracker. +- Use `uv` or the existing project package manager for reproducible environments. + +## Search Spaces + +- Keep search spaces explicit and reviewed. +- Use log-scale sampling for learning rates, regularization, tree counts, and other scale-sensitive values. +- Constrain model complexity to avoid unrealistic training time or memory use. +- Include preprocessing choices only when they can be applied without leakage. +- Do not tune on the test set. + +## Reporting + +- Report the selected model, metric, confidence interval or variance, validation scheme, and final test result. +- Include the best parameters and the search budget. +- Compare the chosen model against the baseline and at least one non-AutoML alternative. +- Document operational constraints such as inference latency, memory use, retraining cost, and explainability. + +## Common Mistakes + +- Do not treat leaderboard rank as proof of production readiness. +- Do not mix train/test data during feature engineering. +- Do not run massive searches before validating labels and data quality. +- Do not ignore class imbalance, calibration, or business cost asymmetry. +- Do not deploy an AutoML model without reproducible training code and pinned dependencies. diff --git a/rules-new/beefreeSDK.mdc b/rules-new/beefreeSDK.mdc index 1891f591..ae6e8b29 100644 --- a/rules-new/beefreeSDK.mdc +++ b/rules-new/beefreeSDK.mdc @@ -1,6 +1,7 @@ --- description: Guidelines and best practices for building applications with [Beefree SDK](https://docs.beefree.io/beefree-sdk), including installation, authentication, configuration, customization, and template management globs: **/*.{ts,tsx,js,jsx,html,css} +alwaysApply: false --- # Beefree SDK Guidelines @@ -515,7 +516,7 @@ Reference the complete project at Beefree SDK [multiple-versions-concept](https:
- + -``` \ No newline at end of file +``` diff --git a/rules-new/blender-python-addon.mdc b/rules-new/blender-python-addon.mdc new file mode 100644 index 00000000..6ad76fcd --- /dev/null +++ b/rules-new/blender-python-addon.mdc @@ -0,0 +1,52 @@ +--- +description: Blender Python add-on rules for operators, panels, properties, registration, testing, and API-safe scripting +globs: ["**/*.py", "blender_manifest.toml", "__init__.py"] +alwaysApply: false +--- + +# Blender Python Add-on Rules + +## Add-on Structure + +- Keep add-on entry points in `__init__.py` with clear `register()` and `unregister()` functions. +- Group operators, panels, properties, preferences, and utilities into separate modules for non-trivial add-ons. +- Use `bl_info` or `blender_manifest.toml` according to the Blender version and packaging target. +- Keep UI labels concise and user-facing text translatable where appropriate. + +## API Usage + +- Use `bpy.types.Operator` for actions, `bpy.types.Panel` for UI, and `bpy.types.PropertyGroup` for grouped settings. +- Define `bl_idname`, `bl_label`, and `bl_options` explicitly. +- Validate context in `poll()` before enabling operators. +- Use `invoke()` for interactive setup and `execute()` for the actual operation. +- Return `{'FINISHED'}` or `{'CANCELLED'}` consistently. +- Use dependency graph updates and evaluated objects when reading final scene state. + +## Data and Properties + +- Register custom properties through `PropertyGroup` classes instead of loose global state. +- Store add-on preferences in `AddonPreferences`. +- Use `PointerProperty`, `CollectionProperty`, and typed properties with names and descriptions. +- Clean up custom properties and handlers during `unregister()`. + +## Safety and Performance + +- Do not run destructive scene operations without explicit user action. +- Avoid blocking UI work in modal operators; use timers or modal state machines for long operations. +- Batch mesh changes and use `bmesh` when editing mesh data programmatically. +- Avoid repeatedly scanning large scenes in draw methods. +- Keep file paths configurable and use Blender path utilities. + +## Testing and Debugging + +- Test scripts in a clean Blender profile and a representative production scene. +- Add smoke tests that import the add-on, register it, run core operators, and unregister cleanly. +- Log actionable messages with `self.report()` for user-facing operator feedback. +- Keep version-specific API differences isolated behind helper functions. + +## Common Mistakes + +- Do not forget to unregister classes, handlers, timers, and keymaps. +- Do not mutate Blender data from panel `draw()` methods. +- Do not assume an active object, selected object, or mode without checking context. +- Do not hardcode absolute asset paths. diff --git a/rules-new/clean-code.mdc b/rules-new/clean-code.mdc index 5ee88e32..ec44ee3b 100644 --- a/rules-new/clean-code.mdc +++ b/rules-new/clean-code.mdc @@ -1,6 +1,7 @@ --- description: Guidelines for writing clean, maintainable, and human-readable code. Apply these rules when writing or reviewing code to ensure consistency and quality. -globs: +globs: ["**/*"] +alwaysApply: false --- # Clean Code Guidelines @@ -52,4 +53,4 @@ globs: ## Version Control - Write clear commit messages - Make small, focused commits -- Use meaningful branch names \ No newline at end of file +- Use meaningful branch names diff --git a/rules-new/codequality.mdc b/rules-new/codequality.mdc index 3f335f39..7d54e8cd 100644 --- a/rules-new/codequality.mdc +++ b/rules-new/codequality.mdc @@ -1,6 +1,7 @@ --- description: Code Quality Guidelines -globs: +globs: ["**/*"] +alwaysApply: false --- # Code Quality Guidelines @@ -44,4 +45,4 @@ Don't suggest updates or changes to files when there are no actual modifications Always provide links to the real files, not x.md. ## No Current Implementation -Don't show or discuss the current implementation unless specifically requested. \ No newline at end of file +Don't show or discuss the current implementation unless specifically requested. diff --git a/rules-new/cpp.mdc b/rules-new/cpp.mdc index 1c2e83a5..e42b3c4c 100644 --- a/rules-new/cpp.mdc +++ b/rules-new/cpp.mdc @@ -1,5 +1,5 @@ --- -description: +description: Guide Cursor to write modern C++ and CMake code with clear structure, RAII, const-correctness, and safe error handling. globs: **/*.c,**/*.cpp,**/*.h,**/*.hpp,**/*.cxx,CMakeLists.txt,*.cmake,conanfile.txt,Makefile,**/*.cc alwaysApply: false --- @@ -131,4 +131,3 @@ alwaysApply: false - Use std::atomic for atomic operations. - Avoid data races by proper synchronization. - Use thread-safe data structures when necessary. - diff --git a/rules-new/database.mdc b/rules-new/database.mdc index d5befc86..ab36aeca 100644 --- a/rules-new/database.mdc +++ b/rules-new/database.mdc @@ -1,6 +1,7 @@ --- description: Database best practices focusing on Prisma and Supabase integration globs: prisma/**/*, src/db/**/*, **/*.prisma, supabase/**/* +alwaysApply: false --- # Database Best Practices @@ -83,4 +84,4 @@ globs: prisma/**/*, src/db/**/*, **/*.prisma, supabase/**/* - Implement proper versioning - Handle errors properly - Document schema properly -- Monitor database health \ No newline at end of file +- Monitor database health diff --git a/rules-new/embedded-stm32-hal.mdc b/rules-new/embedded-stm32-hal.mdc new file mode 100644 index 00000000..c67127bd --- /dev/null +++ b/rules-new/embedded-stm32-hal.mdc @@ -0,0 +1,55 @@ +--- +description: Embedded C/C++ rules for MCU, STM32, HAL, interrupts, DMA, memory constraints, and hardware-focused testing +globs: ["**/*.c", "**/*.h", "**/*.cpp", "**/*.hpp", "**/*.ioc", "CMakeLists.txt", "Makefile", "platformio.ini"] +alwaysApply: false +--- + +# Embedded MCU, STM32, and HAL Rules + +## Project Structure + +- Keep board support, drivers, middleware, application logic, and tests separate. +- Isolate generated CubeMX or vendor code from hand-written application code. +- Put hardware abstraction behind narrow interfaces so logic can be tested without hardware. +- Document clock tree, pin mappings, peripheral ownership, and interrupt priorities. + +## STM32 HAL and Peripherals + +- Initialize peripherals in one place and avoid hidden reconfiguration. +- Check return values from HAL calls and handle timeout/error cases. +- Keep blocking HAL calls out of time-critical paths. +- Use DMA for high-throughput UART, SPI, I2C, ADC, or timer capture paths when appropriate. +- Document buffer ownership and lifetime for DMA operations. +- Use `volatile` only for memory shared with ISRs or hardware registers. + +## Interrupts and Concurrency + +- Keep ISRs short and deterministic. +- Defer heavy work from interrupts to the main loop, RTOS task, or event queue. +- Protect shared data with critical sections, atomics, queues, or RTOS primitives. +- Avoid dynamic allocation in interrupts. +- Make interrupt priority decisions explicit. + +## Memory and Timing + +- Avoid heap allocation in firmware unless the project explicitly allows it. +- Check stack usage for ISRs and RTOS tasks. +- Keep lookup tables `const` so they can live in flash. +- Use fixed-width integer types for hardware-facing code. +- Add timeouts for hardware waits. +- Treat watchdog configuration as part of application design, not a late add-on. + +## Testing and Debugging + +- Unit test pure logic on host builds. +- Use hardware-in-the-loop tests for peripheral behavior. +- Add assertions for impossible hardware states in debug builds. +- Use SWD/JTAG, logic analyzers, and serial logs with rate limits. +- Keep fault handlers useful: capture reset reason, fault registers, and build version when possible. + +## Common Mistakes + +- Do not modify generated files unless the workflow preserves changes. +- Do not busy-wait forever on hardware flags. +- Do not share buffers between DMA and CPU without synchronization. +- Do not assume peripheral reset state after low-power modes. diff --git a/rules-new/fastapi.mdc b/rules-new/fastapi.mdc index 24207d0a..f85697cb 100644 --- a/rules-new/fastapi.mdc +++ b/rules-new/fastapi.mdc @@ -1,6 +1,7 @@ --- description: FastAPI best practices and patterns for building modern Python web APIs globs: **/*.py, app/**/*.py, api/**/*.py +alwaysApply: false --- # FastAPI Best Practices @@ -83,4 +84,4 @@ globs: **/*.py, app/**/*.py, api/**/*.py - Use proper type hints - Keep documentation updated - Document error scenarios -- Use proper versioning \ No newline at end of file +- Use proper versioning diff --git a/rules-new/fortran.mdc b/rules-new/fortran.mdc new file mode 100644 index 00000000..62a18e32 --- /dev/null +++ b/rules-new/fortran.mdc @@ -0,0 +1,66 @@ +--- +description: Modern Fortran rules for scientific computing, modules, explicit interfaces, kind parameters, memory safety, and testing +globs: ["**/*.f", "**/*.f90", "**/*.f95", "**/*.f03", "**/*.f08", "**/*.for", "**/*.ftn", "CMakeLists.txt", "*.cmake", "Makefile"] +alwaysApply: false +--- + +# Fortran Programming Guidelines + +## Basic Principles + +- Use modern Fortran standards such as Fortran 2003, 2008, or newer. +- Use `implicit none` in every program unit. +- Put procedures in modules to provide explicit interfaces. +- Keep modules focused and place each major module in its own file. +- Prefer clear, structured code over clever language tricks. +- Avoid obsolete features such as COMMON blocks, GOTO-heavy control flow, and numeric labels. + +## Kinds and Types + +- Define numeric kind parameters in one shared module, such as `kind_mod`. +- Use `real(kind=dp)` or the project-approved real kind for floating point values. +- Use `integer(kind=i4)` or the project-approved integer kind for integer values. +- Define constants such as pi explicitly. +- Include units in comments for physical quantities. +- Use derived types to group related data instead of passing many primitive arguments. + +## Naming and Style + +- Use lowercase for language keywords and most identifiers. +- Use underscores for multi-word names. +- Avoid names that differ only by case. +- Use descriptive names for procedures and state. +- Repeat the procedure or module name after `end` statements. +- Keep indentation consistent in `do`, `if`, `select case`, and module blocks. + +## Procedures + +- Keep subroutines and functions short and single-purpose. +- Use `intent(in)`, `intent(out)`, or `intent(inout)` for every dummy argument. +- Keep functions free of side effects whenever possible. +- Prefer early validation and clear returns over deep nesting. +- Use `use, only:` when importing from modules. + +## Memory and Arrays + +- Prefer allocatable arrays over pointers unless pointer semantics are required. +- Check allocation state and array sizes before use. +- Deallocate allocatable arrays when their lifetime is not naturally scoped. +- Specify array bounds clearly when they matter. +- Avoid unnecessary dynamic allocation in hot loops. + +## Testing and Build + +- Use CMake, fpm, Make, or the project-standard build system consistently. +- Compile with warnings enabled and treat important warnings as failures in CI. +- Add unit tests for public procedures and integration tests for numerical workflows. +- Test boundary conditions, invalid inputs, and representative scientific cases. +- Verify numerical tolerances explicitly rather than relying on exact floating point equality. + +## Common Mistakes + +- Do not declare variables after executable code unless using a block construct. +- Do not assume `random_number` is a function; it is a subroutine. +- Do not write to stdout from pure procedures. +- Do not declare the same variable twice in the same scope. +- Do not assume pi, dp, or project kinds already exist without importing or defining them. diff --git a/rules-new/gamemaker-gml.mdc b/rules-new/gamemaker-gml.mdc new file mode 100644 index 00000000..d8abbb22 --- /dev/null +++ b/rules-new/gamemaker-gml.mdc @@ -0,0 +1,53 @@ +--- +description: GameMaker Language (GML) rules for scripts, objects, events, rooms, data structures, and performance-minded game code +globs: ["**/*.gml", "**/*.yy", "**/*.yyp"] +alwaysApply: false +--- + +# GameMaker GML Rules + +## Code Organization + +- Keep object event code short and move reusable behavior into scripts or functions. +- Use clear prefixes or naming conventions for scripts, objects, sprites, rooms, and globals. +- Prefer functions over copy-pasted event blocks. +- Keep create-step-draw responsibilities separate. +- Put initialization in Create, simulation in Step, and rendering-only work in Draw. + +## GML Style + +- Use descriptive variable names and avoid one-letter names outside small loops. +- Prefer local variables with `var` or function-scoped declarations over unnecessary instance variables. +- Use constants, enums, and macros for repeated identifiers, layer names, states, and collision groups. +- Guard optional instance references with `instance_exists`. +- Keep global state minimal and document it. + +## Gameplay Architecture + +- Use finite state machines for player, enemy, UI, and game-flow states. +- Keep collision logic explicit and deterministic. +- Separate input collection from action execution. +- Use alarms, timelines, or explicit timers consistently; do not mix patterns without reason. +- Store save data through structured maps/structs and version the save format. + +## Performance + +- Avoid expensive searches such as broad `instance_find` or repeated collision scans in every Step event. +- Cache frequently used asset IDs, layer IDs, and object references when safe. +- Destroy data structures when no longer needed. +- Use object pooling for frequent projectiles, particles, or short-lived effects when allocation becomes costly. +- Profile before optimizing and keep hot-path code simple. + +## Debugging and Testing + +- Add debug overlays for collision boxes, state, velocity, and AI decisions when useful. +- Use assertions or explicit guard clauses for impossible states. +- Test room transitions, pause/resume, save/load, and controller/keyboard input separately. +- Keep reproducible test rooms for complex mechanics. + +## Common Mistakes + +- Do not put game logic in Draw events. +- Do not create data structures without destroying them. +- Do not rely on room editor instance order for critical behavior. +- Do not hardcode magic numeric state IDs. diff --git a/rules-new/gitflow.mdc b/rules-new/gitflow.mdc index d52c71b2..2f2025eb 100644 --- a/rules-new/gitflow.mdc +++ b/rules-new/gitflow.mdc @@ -1,5 +1,7 @@ --- description: Gitflow Workflow Rules. These rules should be applied when performing git operations. +globs: ["**/*"] +alwaysApply: false --- # Gitflow Workflow Rules @@ -108,4 +110,4 @@ description: Gitflow Workflow Rules. These rules should be applied when performi 5. After merge to main: - Tag release - Merge back to develop - - Delete hotfix branch \ No newline at end of file + - Delete hotfix branch diff --git a/rules-new/google-adk.mdc b/rules-new/google-adk.mdc new file mode 100644 index 00000000..1f81969c --- /dev/null +++ b/rules-new/google-adk.mdc @@ -0,0 +1,52 @@ +--- +description: Google Agent Development Kit rules for agents, tools, sessions, memory, artifacts, evaluation, and deployment +globs: ["**/*.py", "**/*.ts", "**/*.tsx", "**/*.go", "**/*.java", "pyproject.toml", "package.json"] +alwaysApply: false +--- + +# Google ADK Rules + +## Agent Design + +- Keep each agent focused on a clear goal, persona, and tool set. +- Use LLM agents for flexible reasoning and workflow agents for deterministic orchestration. +- Write instructions that define task boundaries, tool-use rules, and escalation behavior. +- Split multi-agent systems by responsibility rather than by implementation convenience. +- Keep model choices configurable. + +## Tools + +- Give tools narrow, typed inputs and outputs. +- Validate tool arguments before performing side effects. +- Keep secrets, credentials, and privileged APIs out of agent prompts. +- Handle tool errors explicitly and return actionable failure messages. +- Be aware of ADK tool limitations; some built-in tools cannot be combined with other tools on the same agent. + +## Sessions, State, and Memory + +- Use session state for current-conversation data. +- Use memory for cross-session recall and retrieval. +- Keep state small and serializable. +- Do not store large files or binary payloads in session state. +- Make state keys stable and documented. + +## Artifacts + +- Use artifacts for generated files, uploaded files, reports, images, audio, and other binary data. +- Configure an artifact service in the runner before relying on artifact operations. +- Version artifact filenames intentionally and avoid overwriting semantically different outputs. +- Store only references or summaries in state when full content belongs in artifacts. + +## Evaluation and Deployment + +- Add tests for tool behavior, agent routing, prompt regressions, and unsafe tool calls. +- Use trace or event logs to debug agent decisions. +- Keep local development, staging, and production configuration separate. +- Add observability for latency, tool failures, token use, and handoff failures. + +## Common Mistakes + +- Do not make one agent responsible for every workflow. +- Do not let tools accept arbitrary shell, SQL, or HTTP input without validation. +- Do not rely on prompt text for access control. +- Do not hide important side effects behind generic tool names. diff --git a/rules-new/harmony-arkts.mdc b/rules-new/harmony-arkts.mdc new file mode 100644 index 00000000..4d8134dc --- /dev/null +++ b/rules-new/harmony-arkts.mdc @@ -0,0 +1,54 @@ +--- +description: HarmonyOS ArkTS rules for components, state, resources, layout, lifecycle, and accessibility +globs: ["**/*.ets", "**/*.ts", "**/*.json5", "AppScope/**/*", "entry/src/main/**/*"] +alwaysApply: false +--- + +# HarmonyOS ArkTS Rules + +## Component Structure + +- Use `@Component` for component definitions and PascalCase for component structs. +- Keep state declarations near the top of the component. +- Group lifecycle hooks before `build()`. +- Place `build()` last and keep it focused on UI composition. +- Extract complex UI into smaller components. + +## State and Data Flow + +- Use `@State` for component-owned state. +- Use `@Prop` for parent-to-child data. +- Use `@Link` only for intentional two-way binding. +- Keep derived values in methods or computed helpers rather than duplicating state. +- Avoid broad global state unless the project has an established app-state pattern. + +## Layout and Styling + +- Use `Column`, `Row`, `Stack`, `List`, and other ArkUI primitives intentionally. +- Keep layout properties such as width, height, alignment, and layout weight grouped before visual properties. +- Use object notation for margin and padding when sides differ. +- Use logical pixels consistently. +- Use percentage strings for relative sizes. +- Keep reusable spacing, colors, and typography in resources when the project supports it. + +## Events and Lifecycle + +- Use arrow functions for event handlers. +- Keep event handlers short and delegate complex logic to methods. +- Handle async failures explicitly and surface user-facing errors where appropriate. +- Use lifecycle hooks for setup and teardown that genuinely depends on component lifecycle. + +## Resources and Accessibility + +- Use `$r()` for app resources. +- Group resource references consistently. +- Add descriptive labels and focus handling for interactive elements. +- Maintain color contrast and touch target size. +- Test on representative device sizes and orientations. + +## Common Mistakes + +- Do not bury business logic in `build()`. +- Do not use two-way binding when one-way props are enough. +- Do not hardcode repeated strings, colors, and dimensions that belong in resources. +- Do not leave debug `console.log` calls in production code. diff --git a/rules-new/kubestellar-console.mdc b/rules-new/kubestellar-console.mdc index baeb6b3d..b21cfbe9 100644 --- a/rules-new/kubestellar-console.mdc +++ b/rules-new/kubestellar-console.mdc @@ -1,6 +1,7 @@ --- description: KubeStellar Console — Multi-cluster Kubernetes dashboard development rules globs: **/*.tsx, **/*.ts, **/*.go, web/src/**/*.ts, web/src/**/*.tsx, pkg/**/*.go, cmd/**/*.go +alwaysApply: false --- # KubeStellar Console Development Rules diff --git a/rules-new/medusa.mdc b/rules-new/medusa.mdc index 54167489..28b4e375 100644 --- a/rules-new/medusa.mdc +++ b/rules-new/medusa.mdc @@ -1,6 +1,7 @@ --- description: Medusa rules and best practices. These rules should be used when building applications with Medusa. globs: **/*.tsx, **/*.ts, src/**/*.ts, src/**/*.tsx, src/**/*.js, src/**/*.jsx +alwaysApply: false --- You are an expert senior software engineer specializing in modern web development, with deep expertise in TypeScript, Medusa, React.js, and TailwindCSS. @@ -45,4 +46,4 @@ You are an expert senior software engineer specializing in modern web developmen # Additional Resources -- [Medusa Documentation](https://docs.medusajs.com/llms-full.txt) \ No newline at end of file +- [Medusa Documentation](https://docs.medusajs.com/llms-full.txt) diff --git a/rules-new/nativescript.mdc b/rules-new/nativescript.mdc index 1799cf85..20897380 100644 --- a/rules-new/nativescript.mdc +++ b/rules-new/nativescript.mdc @@ -1,6 +1,7 @@ --- description: NativeScript best practices and patterns for mobile applications globs: **/*.tsx, **/*.ts, **/*.vue, **/*.svelte, src/**/*.ts, app/**/*.ts, src/**/*.tsx, app/**/*.tsx, src/**/*.vue, app/**/*.vue, src/**/*.svelte +alwaysApply: false --- # NativeScript Best Practices diff --git a/rules-new/nextjs.mdc b/rules-new/nextjs.mdc index ae7f4e04..ef216078 100644 --- a/rules-new/nextjs.mdc +++ b/rules-new/nextjs.mdc @@ -1,6 +1,7 @@ --- description: Next.js with TypeScript and Tailwind UI best practices globs: **/*.tsx, **/*.ts, src/**/*.ts, src/**/*.tsx +alwaysApply: false --- # Next.js Best Practices @@ -49,4 +50,4 @@ globs: **/*.tsx, **/*.ts, src/**/*.ts, src/**/*.tsx - Minimize client-side state - Use React Context sparingly - Prefer server state when possible -- Implement proper loading states \ No newline at end of file +- Implement proper loading states diff --git a/rules-new/node-express.mdc b/rules-new/node-express.mdc index bba551b7..d6f52fa4 100644 --- a/rules-new/node-express.mdc +++ b/rules-new/node-express.mdc @@ -1,6 +1,7 @@ --- description: Node.js and Express.js best practices for backend development globs: **/*.js, **/*.ts, src/**/*.ts +alwaysApply: false --- # Node.js and Express.js Best Practices @@ -83,4 +84,4 @@ globs: **/*.js, **/*.ts, src/**/*.ts - Implement proper error handling - Use proper logging - Handle process signals properly -- Document code properly \ No newline at end of file +- Document code properly diff --git a/rules-new/python.mdc b/rules-new/python.mdc index dc4c6e45..f29c75a9 100644 --- a/rules-new/python.mdc +++ b/rules-new/python.mdc @@ -1,6 +1,7 @@ --- description: Python best practices and patterns for modern software development with Flask and SQLite globs: **/*.py, src/**/*.py, tests/**/*.py +alwaysApply: false --- # Python Best Practices @@ -117,4 +118,4 @@ globs: **/*.py, src/**/*.py, tests/**/*.py - Separate dev dependencies - Use proper package versions - Regularly update dependencies -- Check for security vulnerabilities \ No newline at end of file +- Check for security vulnerabilities diff --git a/rules-new/react-router-v7.mdc b/rules-new/react-router-v7.mdc new file mode 100644 index 00000000..d6cbce44 --- /dev/null +++ b/rules-new/react-router-v7.mdc @@ -0,0 +1,52 @@ +--- +description: React Router v7 rules for framework mode, data routers, loaders, actions, route modules, and progressive enhancement +globs: ["app/routes/**/*", "src/routes/**/*", "routes/**/*", "react-router.config.*", "vite.config.*", "**/*.tsx", "**/*.ts"] +alwaysApply: false +--- + +# React Router v7 Rules + +## Route Modules + +- Use route modules as the boundary for route UI, loader data, actions, metadata, and error boundaries. +- Keep route modules small; move shared UI to components and reusable data access to services. +- Prefer file-based routing in framework mode when the project is configured for it. +- Use nested routes for shared layouts and progressive disclosure. +- Export route-specific `ErrorBoundary` components for recoverable route failures. + +## Data Loading + +- Use loaders for route data that should be available before render. +- Keep loaders deterministic and side-effect free. +- Validate params and search params at the loader boundary. +- Return typed data and consume it through route hooks rather than duplicating fetch logic in components. +- Use deferred or streaming patterns only when they improve perceived performance. + +## Mutations + +- Use actions for route mutations and form submissions. +- Prefer `Form`, `useFetcher`, and `useSubmit` for progressive enhancement. +- Revalidate affected loader data after mutations. +- Handle validation errors as typed action data instead of generic exceptions. +- Keep server-only secrets and privileged operations out of client actions. + +## Navigation and State + +- Store shareable state in URL params or search params. +- Keep ephemeral UI state local to components. +- Use pending navigation state to show optimistic or loading UI. +- Avoid global state for data that belongs to route loaders. + +## TypeScript and Testing + +- Type loader and action return values. +- Add tests for route loaders, actions, validation failures, and error boundaries. +- Use integration tests for critical form and navigation flows. +- Mock network and persistence at the route-service boundary. + +## Common Mistakes + +- Do not duplicate loader fetches in `useEffect`. +- Do not mutate data in loaders. +- Do not hide route errors behind a single generic app-level catch-all. +- Do not put auth checks only in components when loader data is protected. diff --git a/rules-new/react.mdc b/rules-new/react.mdc index aabc9b7e..6cba00db 100644 --- a/rules-new/react.mdc +++ b/rules-new/react.mdc @@ -1,6 +1,7 @@ --- description: React best practices and patterns for modern web applications globs: **/*.tsx, **/*.jsx, components/**/* +alwaysApply: false --- # React Best Practices @@ -75,4 +76,4 @@ globs: **/*.tsx, **/*.jsx, components/**/* - Implement proper directory structure - Keep styles close to components - Use proper imports/exports -- Document complex component logic \ No newline at end of file +- Document complex component logic diff --git a/rules-new/ros-ros2.mdc b/rules-new/ros-ros2.mdc new file mode 100644 index 00000000..846508c6 --- /dev/null +++ b/rules-new/ros-ros2.mdc @@ -0,0 +1,44 @@ +--- +description: ROS and ROS2 rules for packages, nodes, launch files, messages, services, actions, simulation, and testing +globs: ["**/*.py", "**/*.cpp", "**/*.hpp", "**/*.h", "package.xml", "CMakeLists.txt", "**/*.launch.py", "**/*.msg", "**/*.srv", "**/*.action", "**/*.urdf", "**/*.xacro"] +alwaysApply: false +--- + +# ROS and ROS2 Rules + +## Package Structure + +- Keep packages focused on one robot capability or integration boundary. +- Use `package.xml` and `CMakeLists.txt` or `setup.py` consistently with the package type. +- Keep launch files under `launch/`, configs under `config/`, messages under `msg/`, services under `srv/`, and actions under `action/`. +- Use namespaces and remapping instead of hardcoded topic names when nodes may be reused. + +## Nodes and Interfaces + +- Keep nodes small and composable. +- Use parameters for tunable behavior; declare ROS2 parameters explicitly. +- Prefer messages for state streams, services for quick request/response operations, and actions for long-running goals with feedback. +- Use standard message types before creating custom interfaces. +- Document topic, service, action, frame, and parameter contracts. + +## Timing and Frames + +- Use ROS time when simulation or bag replay matters. +- Use `tf2` for frame transforms and document frame names. +- Avoid blocking callbacks; move long work to timers, worker threads, or actions. +- Set QoS profiles intentionally for sensor data, latched-like config, and reliable command paths. + +## Build and Test + +- Use `colcon build` and keep package dependencies explicit. +- Run linters and formatters used by the workspace. +- Add launch tests or integration tests for multi-node behavior. +- Use simulation, bags, or recorded fixtures for repeatable sensor scenarios. +- Test failure cases such as missing transforms, stale sensor data, and unavailable services. + +## Common Mistakes + +- Do not hardcode absolute paths; use package share directories. +- Do not publish commands without validating frame, units, and timestamp assumptions. +- Do not create custom messages when a standard message fits. +- Do not ignore QoS mismatches between publishers and subscribers. diff --git a/rules-new/rust-general.mdc b/rules-new/rust-general.mdc new file mode 100644 index 00000000..618230db --- /dev/null +++ b/rules-new/rust-general.mdc @@ -0,0 +1,52 @@ +--- +description: General Rust rules for safe, idiomatic application and library development +globs: ["**/*.rs", "Cargo.toml", "Cargo.lock"] +alwaysApply: false +--- + +# Rust General Rules + +## Project Structure + +- Keep crates focused and name modules by domain responsibility. +- Put reusable library code in `src/lib.rs` and binary entry points in `src/main.rs` or `src/bin/`. +- Keep public APIs small and documented. +- Use feature flags deliberately and document non-default features. +- Commit `Cargo.lock` for applications; follow the project convention for libraries. + +## Ownership and Types + +- Prefer borrowing over cloning when ownership is not needed. +- Use owned values at API boundaries when the callee must store data. +- Model domain states with enums and structs instead of strings or booleans. +- Use `Option` for absence and `Result` for fallible operations. +- Avoid `unwrap()` and `expect()` outside tests, examples, and process-startup invariants. + +## Error Handling + +- Use `thiserror` or project-standard custom errors for libraries. +- Use `anyhow` or project-standard context-rich errors for applications. +- Add context when crossing IO, network, database, or parsing boundaries. +- Do not discard errors with `_` unless explicitly documented. + +## Concurrency and Async + +- Use `Send` and `Sync` boundaries intentionally. +- Prefer message passing or owned task inputs for async work. +- Do not hold blocking locks across `.await`. +- Use `tokio::task::spawn_blocking` or equivalent for blocking CPU or IO in async applications. +- Propagate cancellation through futures rather than hiding it in detached tasks. + +## Testing and Quality + +- Run `cargo fmt` and `cargo clippy` before delivery. +- Add unit tests for pure logic and integration tests for public behavior. +- Use property tests for parsers, serializers, and state machines when useful. +- Use benchmarks only after identifying a real performance question. + +## Common Mistakes + +- Do not fight the borrow checker by adding unnecessary `Arc>`. +- Do not expose internal module structure through public APIs by accident. +- Do not allocate in hot loops without measuring. +- Do not use unsafe code unless the invariant is documented and tested. diff --git a/rules-new/rust.mdc b/rules-new/rust.mdc index c1dfa673..4038e6ab 100644 --- a/rules-new/rust.mdc +++ b/rules-new/rust.mdc @@ -1,6 +1,7 @@ --- description: Rust best practices for Solana smart contract development using Anchor framework and Solana SDK globs: programs/**/*.rs, src/**/*.rs, tests/**/*.ts +alwaysApply: false --- # Rust + Solana (Anchor) Best Practices diff --git a/rules-new/svelte.mdc b/rules-new/svelte.mdc index 2d55e9d1..f300507a 100644 --- a/rules-new/svelte.mdc +++ b/rules-new/svelte.mdc @@ -1,6 +1,7 @@ --- description: Svelte best practices and patterns for modern web applications globs: **/*.svelte, src/**/*.ts, src/**/*.js +alwaysApply: false --- # Svelte Best Practices @@ -83,4 +84,4 @@ globs: **/*.svelte, src/**/*.ts, src/**/*.js - Use proper environment variables - Implement proper code splitting - Use proper asset handling -- Configure proper optimization \ No newline at end of file +- Configure proper optimization diff --git a/rules-new/tailwind.mdc b/rules-new/tailwind.mdc index b9db61d6..148eca40 100644 --- a/rules-new/tailwind.mdc +++ b/rules-new/tailwind.mdc @@ -1,6 +1,7 @@ --- description: Tailwind CSS and UI component best practices for modern web applications globs: **/*.css, **/*.tsx, **/*.jsx, tailwind.config.js, tailwind.config.ts +alwaysApply: false --- # Tailwind CSS Best Practices @@ -75,4 +76,4 @@ globs: **/*.css, **/*.tsx, **/*.jsx, tailwind.config.js, tailwind.config.ts - Use proper documentation - Implement proper testing - Follow accessibility guidelines -- Use proper version control \ No newline at end of file +- Use proper version control diff --git a/rules-new/tensorflow-deep-learning.mdc b/rules-new/tensorflow-deep-learning.mdc new file mode 100644 index 00000000..3939a840 --- /dev/null +++ b/rules-new/tensorflow-deep-learning.mdc @@ -0,0 +1,54 @@ +--- +description: TensorFlow and deep learning rules for building, training, evaluating, and deploying neural network models +globs: ["**/*.py", "**/*.ipynb", "pyproject.toml", "requirements*.txt", "environment*.yml"] +alwaysApply: false +--- + +# TensorFlow and Deep Learning Rules + +## Project Structure + +- Separate data loading, model definition, training, evaluation, and serving code. +- Use `tf.data` pipelines for scalable input processing. +- Keep model hyperparameters in typed config files or dataclasses. +- Store checkpoints, logs, and exported models outside source directories. +- Keep notebooks exploratory; move repeatable training code into modules. + +## Model Development + +- Start with a small baseline model and a tiny overfit test before scaling. +- Use Keras layers and models unless lower-level TensorFlow APIs are required. +- Prefer explicit input shapes and named inputs/outputs. +- Use callbacks for checkpointing, early stopping, learning-rate scheduling, and TensorBoard logging. +- Use mixed precision only after validating numerical stability. +- Pin random seeds where reproducibility matters, while documenting nondeterministic GPU behavior. + +## Training + +- Validate data shapes, dtypes, label ranges, and class balance before training. +- Split data before augmentation or normalization fitting. +- Use validation data for tuning and a separate test set for final reporting. +- Track loss curves, metrics, learning rate, and resource use. +- Save the best checkpoint by validation metric, not by final epoch. + +## Evaluation + +- Report task-appropriate metrics such as AUROC, F1, calibration, perplexity, BLEU/ROUGE, or MAE/RMSE. +- Include confusion matrices or error slices for classification tasks. +- Evaluate on edge cases and distribution shifts when data allows. +- Compare against non-neural baselines when the dataset is small or tabular. + +## Deployment + +- Export models with clear input signatures. +- Keep preprocessing consistent between training and serving. +- Add smoke tests that load the exported model and run inference on sample inputs. +- Monitor latency, memory, prediction drift, and input schema changes. + +## Common Mistakes + +- Do not tune architecture before verifying labels and data quality. +- Do not leak validation data through preprocessing or augmentation. +- Do not rely on accuracy alone for imbalanced data. +- Do not deploy a notebook-only model. +- Do not ignore batch size, dtype, and device differences between training and inference. diff --git a/rules-new/toss-style-design-system.mdc b/rules-new/toss-style-design-system.mdc new file mode 100644 index 00000000..ef8b0151 --- /dev/null +++ b/rules-new/toss-style-design-system.mdc @@ -0,0 +1,67 @@ +--- +description: Toss-style UI design rules for disciplined spacing, typography, grayscale hierarchy, restrained color, cards, metrics, dark mode, and accessibility +globs: ["**/*.tsx", "**/*.jsx", "**/*.vue", "**/*.svelte", "**/*.css", "**/*.scss", "tailwind.config.*"] +alwaysApply: false +--- + +# Toss-Style Design System Rules + +## Design Direction + +- Build quiet, high-trust product UI with clear hierarchy, generous spacing, and minimal ornament. +- Use one primary accent color and rely on grayscale for most structure. +- Avoid decorative gradients, unnecessary shadows, and competing accent colors. +- Prioritize readability, confidence, and fast scanning over visual novelty. + +## Typography + +- Use a strict type scale with clear roles for page title, section title, body, supporting text, and metadata. +- Use font weight and color before using large size changes. +- Never use pure black text; use a dark grayscale foreground. +- Keep line height comfortable for body copy and tighter for short labels or metrics. +- For metrics, make the number visually dominant and the unit smaller but still legible. + +## Layout and Rhythm + +- Use consistent spacing tokens. +- Keep related content close and unrelated content separated by whitespace. +- Use section rhythm: summary, details, action, and supporting context. +- Align form fields, values, and controls predictably. +- Avoid nested cards and excessive borders. + +## Cards and Surfaces + +- Use cards only for grouped content that needs a surface. +- Keep card radius restrained and consistent. +- Use subtle shadows or borders, not both heavily. +- Keep shadow opacity low and avoid dramatic elevation. +- Do not place important controls in low-contrast decorative surfaces. + +## Color + +- Use the accent color for primary actions, selected state, links, or critical brand moments. +- Use semantic colors for status only: success, warning, error, and information. +- Keep disabled and secondary states in grayscale. +- Ensure status is never communicated by color alone. + +## Dark Mode + +- Rebuild the grayscale scale for dark mode rather than inverting colors. +- Reduce bright accent intensity on dark backgrounds. +- Preserve contrast between surface, border, and foreground layers. +- Test charts, cards, and form controls in both modes. + +## Accessibility + +- Meet WCAG AA contrast for text and controls. +- Provide visible focus states. +- Keep tap targets large enough for touch. +- Use semantic HTML and labels before adding ARIA. +- Respect reduced motion preferences. + +## Common Mistakes + +- Do not create one-off spacing values. +- Do not mix multiple unrelated accent colors. +- Do not overuse cards to separate every piece of content. +- Do not rely on large hero typography inside dense product screens. diff --git a/rules-new/typescript.mdc b/rules-new/typescript.mdc index b3919bd9..1b48765c 100644 --- a/rules-new/typescript.mdc +++ b/rules-new/typescript.mdc @@ -1,6 +1,7 @@ --- description: TypeScript coding standards and best practices for modern web development globs: **/*.ts, **/*.tsx, **/*.d.ts +alwaysApply: false --- # TypeScript Best Practices @@ -54,4 +55,4 @@ globs: **/*.ts, **/*.tsx, **/*.d.ts - Implement the Repository pattern for data access - Use the Factory pattern for object creation - Leverage dependency injection -- Use the Module pattern for encapsulation \ No newline at end of file +- Use the Module pattern for encapsulation diff --git a/rules-new/vue.mdc b/rules-new/vue.mdc index 54d45384..09915dd8 100644 --- a/rules-new/vue.mdc +++ b/rules-new/vue.mdc @@ -1,6 +1,7 @@ --- description: Vue.js best practices and patterns for modern web applications globs: **/*.vue, **/*.ts, components/**/* +alwaysApply: false --- # Vue.js Best Practices @@ -83,4 +84,4 @@ globs: **/*.vue, **/*.ts, components/**/* - Use proper environment variables - Implement proper code splitting - Use proper asset handling -- Configure proper optimization \ No newline at end of file +- Configure proper optimization diff --git a/rules/beefreeSDK-nocode-content-editor-cursorrules-prompt-file/.cursorrules b/rules/beefreeSDK-nocode-content-editor-cursorrules-prompt-file/.cursorrules index 1891f591..68609541 100644 --- a/rules/beefreeSDK-nocode-content-editor-cursorrules-prompt-file/.cursorrules +++ b/rules/beefreeSDK-nocode-content-editor-cursorrules-prompt-file/.cursorrules @@ -346,11 +346,7 @@ Guidelines and best practices for building applications with [Beefree SDK](https fetch('/api/beefree/auth', { method: 'POST', headers: { 'Content-Type': 'application/json' }, - body: JSON.stringify({ - client_id: 'your_client_id', - client_secret: 'your_client_secret', - uid: beeConfig.uid - }) + body: JSON.stringify({ uid: beeConfig.uid }) }) .then(response => { if (!response.ok) throw new Error('Auth failed: ' + response.status); @@ -515,7 +511,7 @@ Reference the complete project at Beefree SDK [multiple-versions-concept](https:
- + -``` \ No newline at end of file +``` diff --git a/rules/beefreeSDK-nocode-content-editor-cursorrules-prompt-file/README.md b/rules/beefreeSDK-nocode-content-editor-cursorrules-prompt-file/README.md index a90d3a57..733c406f 100644 --- a/rules/beefreeSDK-nocode-content-editor-cursorrules-prompt-file/README.md +++ b/rules/beefreeSDK-nocode-content-editor-cursorrules-prompt-file/README.md @@ -63,7 +63,7 @@ BEE_CLIENT_SECRET=your_client_secret_here
- +