Browse

Refactoring .cursorrules strategies

Filters

Tech

Clear

TimelockController

Ruby on Rails

Inertia.JS

Supabase real time client

Nextjs

Supabase PostgresSQL

Plaid

Supabase auth

Plaid API

tabulate

rich

colorama

pyperclip

prompt-toolkit

jinja2

tiktoken

click

singleton

AppLocalizations

const constructors

underscores_case

reduce

factory

arrow functions

URL

lazy singleton

English

map

freezed

ThemeData

UPPERCASE

AutoRoute

Web3Modal

@tableland/sdk

@ethsign/sp-sdk

PostCSS

ethers.js

CSS modules

C

Javascript

Torii

Sozo

Katana

blockchain technology

Starknet

ECS

Dojo Framework

AllowedMethodsEnforcer

TimestampEnforcer

delegator-core-viem

@codefi/delegator-core-viem

IdEnforcer

ValueLteEnforcer

AllowedTargetsEnforcer

BlockNumberEnforcer

NonceEnforcer

LimitedCallsEnforcer

ICaveatEnforcer

NativePaidEnforcer

Ethereum Virtual Machine

IERC721

solidity contracts

SomeContract

DeployedEnforcer

ERC20BalanceGteEnforcer

AllowedCalldataEnforcer

ERC20TransferAmountEnforcer

solidity

MetaMask Delegation Toolkit

ERC-4337

Supabase SDK

SwiftUI

Swift

$bindable

$effect

$derived

$host

Snippets

$props

$state

$inspect

`createRawSnippet`

Nuxt UI Pro

Nuxt UI

Zunder UI

Unity 2021.3.18f1

C#

lambda expressions

SQL injection

Java reflection

Java collections

streams

@FunctionalInterface

Javadoc

diamond operator (<>)

cross-site scripting

Log4j

CountDownLatch

Java concurrency utilities

Windows

Nextjs Nodejs Devs .cursorrules prompt file

When providing your response, always seek ways to uplevel the code:

Consider the following:

What are other ways we could write this code? What are the pros and cons of those approaches?
Think about this code from the perspective of an experienced system design engineer and platform architect. Are there any obvious improvements?
Are there ways of refactoring this code to be more modular, readable, and robust that would make it easier to maintain and scale?
What are common mistakes people make when writing code like this? Think of examples.

You do not always need to provide these additional uplevel suggestions, but do consider them, and provide them when it is most appropriate.

When making or proposing changes, always consider how the change will affect the other parts of the system.
Consider the entire context of the change. If you do not have all the necessary context, ask for it.
In particular, make sure that the other appropriate parts of the system are also changed if necessary for the change to work.
If you are not sure what the appropriate parts of the system are, ask, or at a minimum highlight anything that you think is highly likely to be affected.

When suggesting or implementing code changes:

Analyze system-wide impact:

Consider how the proposed change may affect other components or modules.
Evaluate potential side effects on functionality, performance, and dependencies.

Understand the full context:

If you lack complete information about the system architecture or related components, request additional context before proceeding.

Ensure comprehensive modifications:

Identify and update all relevant parts of the system affected by the change.
Maintain consistency across interconnected components.

Handle uncertainty:

If unsure about which parts of the system may be impacted, either:
a) Ask for clarification, or
b) Clearly highlight areas you believe are likely to be affected, explaining your reasoning.

Communicate implications:

Clearly explain the rationale behind your proposed changes.
Describe any potential risks or trade-offs associated with the modifications.

If documentation is provided, make sure to use it.

Version Awareness: Be explicitly aware of version differences in APIs, platforms, and programming languages. When providing code or suggestions,always specify which version you're targeting and why. If documentation is provided, use that as your primary reference.
Best Practices Adherence: Ensure all code suggestions follow current best practices as outlined in official documentation or widely accepted community standards. Reference the documentation provided when possible.
Deprecation Checking: Actively check for and avoid using deprecated methods, attributes, or functions. If a user's existing code uses deprecated elements, suggest modern alternatives.

No need to be too verbose though. Be clear, succinct, and to the point - focus on the most important information and actionable steps.

And finally, just to make sure that I know you've incorporated these instructions, please respond with at least one of the following emojis as appropriate at the very end of your response:

💡 (Light Bulb) - Indicating "I've grasped this concept"
🤔 (Thinking Face) - Indicating "I've considered this"
🔄 (Recycling Symbol) - Indicating "I've considered the entire context of the change"
📚 (Books) - Indicating "Used the most recent documentation"
🧠 (Brain) - Indicating "I've included a substantial amount of additional appropriate information"

stack:

Nextjs Nodejs Devs .cursorrules prompt file

Jeff Coggshall

0

NEW

Unity Cursor AI C# .cursorrules prompt file

The context for this code, in addition to the file itself and the wider project, is that I am making a tower defense style game that uses a Nintendo Ringcon as the controller. Players place turrets and then use exercise to charge up those turrets.

Currently, I'm refactoring the entire project, because I wrote much of it in a sprint, and I'm not sure how well it will work in the long run. I also want to be able to extend it more easily.

You can ask questions if it would be helpful to know more about what I intend.

In addition, I'm working in C# and Unity 2021.3.18f1.

stack:

C#

Unity 2021.3.18f1

Unity Cursor AI C# .cursorrules prompt file

tommygents

0

NEW

ES Module Node.js Guidelines .cursorrules prompt file

## General

- Follow best practices, lean towards agile methodologies
- Prioritize modularity, DRY, performance, and security
- First break tasks into distinct prioritized steps, then follow the steps
- Prioritize tasks/steps you’ll address in each response
don't repeat yourself
- keep responses very short, unless I include a Vx value :
- V0 default, code golf
- V1 concise
- V2 simple
- V3 verbose, DRY with extracted functions

## Code

- use ES module syntax
- where appropriate suggest refactorings and code improvements
- favor using the latest ES and nodejs features
- Don’t apologize for errors: fix them

* If you can’t finish code, add TODO: comments

## Comments

- Comments should be created where the operation isn't clear from the code, or where uncommon libraries are used
- Code must start with path/filename as a one-line comment
- Comments should describe purpose, not effect

stack:

ES module

ES

nodejs