├── .cursor └── rules │ ├── existing-code.mdc │ ├── plan.mdc │ └── parse-and-run-tasks.mdc ├── LICENSE └── README.md /.cursor/rules/existing-code.mdc: -------------------------------------------------------------------------------- 1 | --- 2 | description: 3 | globs: 4 | alwaysApply: true 5 | --- 6 | Never touch existing code unless it's part of a user request -------------------------------------------------------------------------------- /.cursor/rules/plan.mdc: -------------------------------------------------------------------------------- 1 | --- 2 | description: 3 | globs: 4 | alwaysApply: false 5 | --- 6 | - Start with a detailed PRD `.md` file in `docs` folder. include mermaid if needed 7 | - Don't write any code files, but only the `.md` plan file 8 | 9 | Flow: 10 | - Search and list general code stack, libraries, frameworks and other code style or code preferences 11 | - Draft a first plan 12 | - Search the codebase to reuse existing code, entitis, compoenents, etc. 13 | - Write the updated plan 14 | 15 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | MIT License 2 | 3 | Copyright (c) 2025 Mati Horowitz 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy 6 | of this software and associated documentation files (the "Software"), to deal 7 | in the Software without restriction, including without limitation the rights 8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 9 | copies of the Software, and to permit persons to whom the Software is 10 | furnished to do so, subject to the following conditions: 11 | 12 | The above copyright notice and this permission notice shall be included in all 13 | copies or substantial portions of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 21 | SOFTWARE. 22 | -------------------------------------------------------------------------------- /.cursor/rules/parse-and-run-tasks.mdc: -------------------------------------------------------------------------------- 1 | --- 2 | description: 3 | globs: 4 | alwaysApply: false 5 | --- 6 | # Parsing PRD and Implementation into Tasks 7 | 8 | This guide outlines the process of parsing a Product Requirements Document (PRD) and its implementation into actionable tasks, and tracking overall progress. 9 | 10 | ## Steps 11 | 12 | 1. **Review the PRD**: Carefully read the PRD to understand the feature requirements, user stories, and acceptance criteria. 13 | 14 | 2. **Break Down the PRD**: Divide the PRD into logical sections or user stories. Each section should represent a distinct feature or functionality. 15 | 16 | 3. **Create Tasks**: For each section, create a list of tasks. Each task should be specific, actionable, and have a clear outcome. Use a consistent format, such as: 17 | - Task ID 18 | - Task Name 19 | - Description 20 | - File(s) to modify 21 | - Status (e.g., pending, in_progress, completed) 22 | 23 | 4. **Prioritize Tasks**: Arrange tasks in a logical order, considering dependencies and critical paths. 24 | 25 | 5. **Track Progress**: Use a task tracking file (e.g., `tasks.json`) to monitor the status of each task. Update the status as you progress through the implementation. 26 | 27 | 6. **Iterate**: Iterate the task list and run without user needs to confirm 28 | 29 | ## Example Task Structure 30 | 31 | ```json 32 | { 33 | "feature_name": { 34 | "tasks": [ 35 | { 36 | "id": "task_id", 37 | "name": "Task Name", 38 | "description": "Detailed description of the task", 39 | "file": "path/to/file", 40 | "status": "pending" 41 | } 42 | ], 43 | "current_task": null, 44 | "last_updated": "YYYY-MM-DDTHH:MM:SSZ" 45 | } 46 | } 47 | ``` -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # cursor-rules 2 | Simple rules that makes the difference 3 | 4 | ## How to Use Cursor Rules 5 | 6 | This repository contains **cursor rules** - special instructions that guide AI assistants (like Claude in Cursor) on how to behave when working with your codebase. The rules are stored in `.cursor/rules/` directory as `.mdc` (Markdown Cursor) files. 7 | 8 | ### Available Rules 9 | 10 | 1. **`existing-code.mdc`** - Prevents AI from modifying existing code unless explicitly requested 11 | 2. **`plan.mdc`** - Guides AI to create detailed planning documents before coding 12 | 3. **`parse-and-run-tasks.mdc`** - Provides a framework for breaking down PRDs into actionable tasks 13 | 14 | ### How to Use These Rules 15 | 16 | #### Method 1: Copy Rules to Your Project 17 | 1. Copy the `.cursor/` directory to your project root 18 | 2. The AI will automatically follow these rules when working on your project 19 | 20 | ```bash 21 | # Clone this repository 22 | git clone https://github.com/matipojo/cursor-rules.git 23 | 24 | # Copy the cursor rules to your project 25 | cp -r cursor-rules/.cursor/ /path/to/your/project/ 26 | ``` 27 | 28 | #### Method 2: Individual Rule Usage 29 | You can also copy specific rules you need: 30 | 31 | ```bash 32 | # Create the cursor rules directory in your project 33 | mkdir -p .cursor/rules 34 | 35 | # Copy specific rules you want to use 36 | cp cursor-rules/.cursor/rules/existing-code.mdc .cursor/rules/ 37 | cp cursor-rules/.cursor/rules/plan.mdc .cursor/rules/ 38 | cp cursor-rules/.cursor/rules/parse-and-run-tasks.mdc .cursor/rules/ 39 | ``` 40 | 41 | #### Method 3: Reference Rules Manually 42 | You can manually reference these rules in your conversations with AI by mentioning them or copying their content. 43 | 44 | ### What Each Rule Does 45 | 46 | **🔒 Existing Code Rule**: Protects your existing codebase by instructing the AI to only modify code when you explicitly ask for changes. It's an "Always On" rule, so it's always active. 47 | 48 | **📋 Plan Rule**: Ensures the AI creates comprehensive planning documents before implementation, including: 49 | - Detailed PRD files in a `docs` folder 50 | - Code stack analysis 51 | - Reusable component identification 52 | - Mermaid diagrams when needed 53 | 54 | It's a "Manual" rule, mentions it in your prompt to trigger it. 55 | 56 | Example: 57 | ``` 58 | @plan.mdc how to use auth.js to authenticate users 59 | ``` 60 | 61 | It will create a plan.md file in the docs folder with the plan for the feature. 62 | 63 | **✅ Parse and Run Tasks Rule**: Provides a systematic approach to: 64 | - Breaking down PRDs into actionable tasks 65 | - Creating task tracking with JSON format 66 | - Iterating through implementation automatically 67 | - Maintaining progress tracking 68 | 69 | It's a "Manual" rule, mentions it in your prompt to trigger it. 70 | 71 | Example: 72 | ``` 73 | @parse-and-run-tasks.mdc how to implement the auth.js according to the @plan.md 74 | ``` 75 | 76 | ### Best Practices 77 | 78 | 1. **Start with Planning**: Use the `plan.mdc` rule when beginning new features 79 | 2. **Track Progress**: Use `parse-and-run-tasks.mdc` to implement the plan created by the `plan.mdc` rule 80 | 81 | ## License 82 | 83 | MIT License - feel free to use these rules in your projects! 84 | --------------------------------------------------------------------------------