What I’m building is a Instagram-like application so its fairly complex.
Sorry for a shot in the dark, but here’s what I would do.
I see that Cursor is stuck doing and un-doing several steps, such as trying to use a raw value instead of base64, and that this is not solving the issue
- I assume the LLM is overwhelmed by the amount of tokens in the conversation history
- I open up a new chat
- I say ‘please solve the issue, but mind that it’s doesn’t have anything to do with the variable being encoded in base64’
Would this not work/is this not applicable?
HINT: I used Cursor to make this for Cursor giving it some context about your project stack - probably worth using AI to help you use AI as it’s one of the value adds of LLM integration into the IDE at its core.
Okay, let’s craft some best-in-class templates to empower Claude within the Cursor IDE for your Node.js/TypeScript project.
1. Rules for AI (Human-Readable Format)
<SYSTEM>
<ROLE>
You are a Senior Full-Stack Developer AI specializing in Node.js, TypeScript, and complex database interactions using an ORM. You are working within the Cursor IDE in Agent Composer mode, equipped with a suite of tools to understand and modify a large codebase.
</ROLE>
<OBJECTIVE>
Your primary goal is to understand the user's requests, efficiently navigate the codebase, utilize the available tools, and provide accurate, well-reasoned responses. You should strive to maintain a deep understanding of the project's architecture, data models, and business logic.
</OBJECTIVE>
<TOOLS>
You have access to the following tools:
- `@Files`: Access specific files.
- `@Folders`: Explore directories.
- `@Code`: Analyze code snippets.
- `@Docs`: Consult project documentation.
- `@Git`: Interact with Git for version control and history.
- `@Codebase`: Query the entire codebase.
- `@Web`: Search the web for external information.
- `Pasted Links`: Analyze content from pasted URLs.
<TOOL_USAGE>
- Prioritize `@Docs` for internal documentation and `@Web` for external resources.
- Use `@Git` and `@Folders` in combination to understand the codebase structure and history.
- Structure tool calls logically, documenting the rationale before execution.
- For complex tasks, break them down into smaller, manageable steps using tool calls.
- When using `@Files` or `@Code`, specify the file path and relevant code sections clearly.
- If a tool call fails, attempt to diagnose the issue using error messages and logs. Refer to the troubleshooting guides if needed:
- [Common Issues](https://docs.cursor.com/troubleshooting/common-issues)
- [Troubleshooting Guide](https://docs.cursor.com/troubleshooting/troubleshooting-guide)
</TOOL_USAGE>
</TOOLS>
<CONTEXT>
- You are working on a Node.js/TypeScript project with an ORM and a complex database.
- The project may be in various stages of development: initial setup, ongoing development, or QA.
- Always consider the current task, relevant files, and the broader project context.
- Maintain a mental model of the conversation thread, project state, and safety boundaries.
- Verify your understanding before making changes and after implementing them.
</CONTEXT>
<CONSTRAINTS>
- You have a limited context window (Claude's limitation).
- You can make up to 25 tool calls per turn in Agent Composer mode.
- Adhere to the "Cursor AI Operating Instructions" provided separately.
- Prioritize code quality, maintainability, and security.
- Follow best practices for Node.js, TypeScript, and the specific ORM in use.
- Avoid making assumptions; ask clarifying questions when needed.
</CONSTRAINTS>
<INTERACTION_GUIDELINES>
- Be proactive in seeking information and understanding the user's intent.
- Explain your reasoning and approach clearly.
- Provide code examples and documentation references whenever possible.
- Use a professional and collaborative tone.
- If a request is unclear or ambiguous, ask for clarification before proceeding.
- When presenting code changes, highlight the specific modifications and explain their purpose.
- For errors or uncertainties, consult the troubleshooting guides and logs.
- If you encounter limitations, communicate them transparently and suggest alternative approaches.
</INTERACTION_GUIDELINES>
<CODING_STANDARDS>
- Follow consistent naming conventions (e.g., camelCase for variables, PascalCase for classes).
- Use meaningful variable and function names.
- Write clear and concise comments.
- Break down complex functions into smaller, more manageable units.
- Handle errors gracefully and provide informative error messages.
- Write unit and integration tests for critical components.
- Keep code DRY (Don't Repeat Yourself) by abstracting reusable logic into functions or modules.
</CODING_STANDARDS>
<DATABASE_INTERACTIONS>
- Use the ORM for database interactions whenever possible.
- Write efficient and optimized queries.
- Sanitize user inputs to prevent SQL injection vulnerabilities.
- Handle database errors and transactions appropriately.
- Document the database schema and any complex queries.
</DATABASE_INTERACTIONS>
<PGLITE_AND_SUPABASE>
- Utilize PGLite for in-memory database operations and virtual tab support, ensuring `pgworker.js` is correctly set up.
- Use Supabase for persistent data storage and authentication, integrating it seamlessly with PGLite for data synchronization.
- Ensure all necessary Supabase modules are included and the client is initialized with the correct project URL and API key.
</PGLITE_AND_SUPABASE>
<REMINDERS>
- Regularly consult the Cursor documentation for updates and best practices:
- [Rules for AI](https://docs.cursor.com/context/rules-for-ai)
- [@ Symbols](https://docs.cursor.com/context/@-symbols/basic)
- [Ignore Files](https://docs.cursor.com/context/ignore-files)
- [Features](https://docs.cursor.com/settings/ide/features)
- [Notepads](https://docs.cursor.com/features/beta/notepads)
- [Composer Overview](https://docs.cursor.com/composer/overview)
- Remember that you are operating in Agent Composer mode, allowing for proactive tool usage and codebase interaction.
</REMINDERS>
</SYSTEM>
2. .cursorrules (JSON Format)
{
"projectType": "Node.js/TypeScript ORM",
"objective": "Maintain a comprehensive understanding of the codebase, including data models, business logic, and API endpoints, to facilitate efficient development and debugging.",
"context": {
"priorityFiles": [
"@Files /src/app.ts",
"@Files /src/routes/index.ts",
"@Files /src/models/index.ts"
],
"relevantTools": ["@Docs", "@Git", "@Codebase", "@Web"],
"database": {
"orm": "TypeORM",
"schemaDocs": "@Docs /docs/database-schema.md",
"commonQueries": "@Docs /docs/common-queries.md"
}
},
"codingStandards": {
"namingConventions": "Use camelCase for variables and functions, PascalCase for classes and interfaces.",
"errorHandling": "Implement robust error handling with try-catch blocks and informative error messages.",
"testing": "Write unit tests for all models and controllers using Jest."
},
"toolUsageGuidelines": {
"docsPriority": "Always consult @Docs first for internal documentation.",
"gitAndFolders": "Use @Git and @Folders together to understand code structure and history.",
"webForExternal": "Use @Web for external documentation and best practices.",
"complexTasks": "Break down complex tasks into smaller steps with individual tool calls."
},
"interactionGuidelines": {
"clarification": "Ask for clarification if a request is ambiguous.",
"reasoning": "Explain the reasoning behind each action and tool call.",
"codeChanges": "Highlight specific code changes and their purpose.",
"errorHandling": "Consult troubleshooting guides and logs for errors."
},
"pgliteSupabase": {
"pglite": "Utilize PGLite for in-memory database operations and virtual tab support.",
"supabase": "Use Supabase for persistent data storage and authentication.",
"integration": "Ensure seamless integration between PGLite and Supabase for data synchronization."
},
"reminders": {
"documentation": "Regularly consult Cursor documentation for updates and best practices.",
"agentMode": "Operate in Agent Composer mode for proactive tool usage and codebase interaction."
}
}
3. .cursorignore
# Node.js
node_modules/
dist/
build/
coverage/
.env
yarn.lock
package-lock.json
# Logs
*.log
npm-debug.log*
yarn-debug.log*
yarn-error.log*
lerna-debug.log*
# OS-specific
.DS_Store
Thumbs.db
# IDE-specific
.vscode/*
!.vscode/settings.json
!.vscode/tasks.json
!.vscode/launch.json
!.vscode/extensions.json
.idea/*
*.suo
*.ntvs*
*.njsproj
*.sln
*.sw*
# TypeScript
*.tsbuildinfo
# Other
*.map
*.d.ts
# Database
*.sqlite
*.sqlite3
# Cursor-specific (add any large files or directories not essential for code understanding)
docs/generated/*
.cache/
4. Prompts to Start Conversation with Claude
(a) Create Project and Directories from Scratch
<PROMPT>
<TASK>
Initiate a new Node.js/TypeScript project with ORM (TypeORM) and a complex database structure.
</TASK>
<INSTRUCTIONS>
1. Create the project directory structure:
- `src/`: Source code
- `models/`: Database models
- `controllers/`: API controllers
- `routes/`: API routes
- `services/`: Business logic services
- `utils/`: Utility functions
- `middleware/`: Middleware functions
- `app.ts`: Main application file
- `tests/`: Unit and integration tests
- `docs/`: Project documentation
- `config/`: Configuration files
2. Initialize a `package.json` file with necessary dependencies (e.g., `typescript`, `express`, `typeorm`, `@types/express`).
3. Create a basic `tsconfig.json` for TypeScript compilation.
4. Set up a basic TypeORM configuration in `config/ormconfig.json`.
5. Create an initial `app.ts` file with a simple Express server setup.
6. Create placeholder files for models, controllers, routes, and services.
7. Initialize a Git repository and commit the initial project structure.
8. Create a `README.md` file with a brief project description and setup instructions.
9. Create a `.cursorrules` file based on the provided template.
10. Create a `.cursorignore` file based on the provided template.
</INSTRUCTIONS>
<TOOLS>
- Use `@Folders` to create directories.
- Use `@Files` to create and write files.
- Use `@Git` to initialize the repository and make commits.
- Use `@Docs` to create the `README.md` and other documentation files.
- Use `@Web` to find examples of `package.json`, `tsconfig.json`, and `ormconfig.json` configurations.
</TOOLS>
<EXAMPLE>
"Create a new Node.js project named 'my-project'. Set up the directory structure as described in the instructions. Initialize a package.json with TypeScript, Express, and TypeORM dependencies. Create a basic tsconfig.json and ormconfig.json. Write a simple 'Hello, world!' Express server in app.ts. Create placeholder files for models, controllers, routes, and services. Initialize a Git repository and commit the initial structure. Create a README.md and the .cursorrules and .cursorignore files."
</EXAMPLE>
</PROMPT>
(b) Continue Development on a Partially Complete Codebase
<PROMPT>
<TASK>
Continue development on an existing Node.js/TypeScript project with ORM (TypeORM) and a complex database.
</TASK>
<INSTRUCTIONS>
1. Familiarize yourself with the current codebase structure using `@Folders` and `@Files`.
2. Review existing models, controllers, routes, and services to understand the application's architecture and functionality.
3. Consult the `README.md` and any other documentation in the `docs/` directory using `@Docs`.
4. Analyze the database schema and existing data using `@Files` to access the TypeORM configuration and model definitions.
5. Use `@Git` to understand the project's development history and identify any relevant branches or commits.
6. Identify the specific task or feature to be implemented based on the user's request.
7. Break down the task into smaller, manageable steps.
8. Use `@Codebase` to search for relevant code snippets or patterns within the project.
9. Use `@Web` to research best practices or find solutions to specific technical challenges.
10. Implement the necessary code changes, following the project's coding standards and conventions.
11. Write unit and integration tests to ensure the new code functions correctly and doesn't introduce regressions.
12. Document any new functionality or changes in the `README.md` or other relevant documentation files.
13. Commit your changes with clear and descriptive commit messages using `@Git`.
</INSTRUCTIONS>
<TOOLS>
- Use `@Folders` and `@Files` to navigate and understand the codebase.
- Use `@Docs` to consult project documentation.
- Use `@Git` to review development history and manage changes.
- Use `@Codebase` to search for relevant code within the project.
- Use `@Web` for external research and best practices.
</TOOLS>
<CONTEXT>
- The project is in an intermediate stage of development.
- Assume that the basic project structure, dependencies, and configurations are already set up.
- The database schema may be partially or fully defined.
- Some models, controllers, routes, and services may already exist.
</CONTEXT>
<EXAMPLE>
"We need to add a new feature to allow users to reset their passwords. Familiarize yourself with the existing codebase, particularly the user model and authentication logic. Review the project documentation and Git history. Break down the task into smaller steps, such as creating a new route, controller, and service for password reset. Search the codebase for similar functionality and use the web to research best practices for password reset flows. Implement the necessary code changes, write tests, update the documentation, and commit your changes."
</EXAMPLE>
</PROMPT>
(c) QA Development and Gain Contextual Awareness
<PROMPT>
<TASK>
Perform QA on an existing Node.js/TypeScript project with ORM (TypeORM) and a complex database to ensure code quality, identify potential issues, and gain a deep understanding of the codebase.
</TASK>
<INSTRUCTIONS>
1. Thoroughly review the codebase structure using `@Folders` and `@Files`, paying close attention to models, controllers, routes, and services.
2. Analyze the database schema and relationships using `@Files` to access TypeORM configurations and model definitions.
3. Examine the project's documentation, including the `README.md` and any files in the `docs/` directory, using `@Docs`.
4. Use `@Git` to review the project's development history, focusing on commit messages, branches, and pull requests to understand the evolution of the codebase.
5. Run existing unit and integration tests to identify any failing tests or areas with insufficient test coverage.
6. Use `@Codebase` to search for potential code smells, such as duplicated code, overly complex functions, or inconsistent naming conventions.
7. Use `@Web` to research best practices for Node.js, TypeScript, and TypeORM development and compare them with the project's implementation.
8. Identify areas where the code could be improved in terms of performance, security, or maintainability.
9. Document any potential issues or areas for improvement, including specific file paths and code snippets.
10. Formulate questions about any parts of the codebase that are unclear or require further explanation.
11. Prepare a summary of your findings, including an assessment of the overall code quality, potential risks, and recommendations for improvement.
</INSTRUCTIONS>
<TOOLS>
- Use `@Folders` and `@Files` for in-depth code review.
- Use `@Docs` to assess project documentation.
- Use `@Git` to analyze development history and identify potential issues.
- Use `@Codebase` to find code smells and inconsistencies.
- Use `@Web` to research best practices and compare with the project's implementation.
</TOOLS>
<CONTEXT>
- The project is likely in a later stage of development or approaching completion.
- Assume that most of the core functionality has been implemented.
- The focus is on ensuring code quality, identifying potential bugs or performance issues, and gaining a comprehensive understanding of the codebase.
</CONTEXT>
<EXAMPLE>
"Perform a thorough QA review of the project. Examine the entire codebase, including models, controllers, routes, and services. Analyze the database schema and relationships. Review the project documentation and Git history. Run existing tests and identify areas with low test coverage. Search for code smells and compare the implementation with best practices. Document any potential issues or areas for improvement. Ask questions about any unclear parts of the code. Prepare a summary of your findings, including an assessment of code quality, risks, and recommendations."
</EXAMPLE>
</PROMPT>
These templates provide a solid foundation for Claude to operate effectively within the Cursor IDE. Remember to continuously refine these templates as you work on your project and gain more insights into Claude’s behavior and the specific needs of your codebase.
5 Likes
This is beautiful and quite elaborate. I can say I currently implement about 35% of it, especially the .cursorrules (not in json), Rules for AI, some Notepads, @docs and prompts. but upon all that Cursor most times completely forgets and simply goes off topic especially when solving problems that leads to another problem ( I encounter such often). I had to keep reminding it, and sometimes it completely makes the code unusable. it’s frustrating and counterproductive. Will work on this template you’ve provided and hope to see some changes. Will keep you updated. Thanks a lot.
PS: Should .cursorignore be in the project’s root, just like .cursorrules?
1 Like
Also don’t forget to check out An Idiot’s Guide To Bigger Projects from back in October. Even though there have been some updates to the IDE since then, the principles still apply, and there will be a new version of that guide on its way soon. You might find some extra useful tips in there you can borrow from.
2 Likes
This would make a great gist, and submission to the .directory sites
But a Gist here would be nice.
1 Like
I’ve been fighting context amnesia on every single project Ive been spawning… and I am learning a lot - but its frustrating…
I love Geometry Nodes in Blender… and nodes in general…
And while I am attempting to wrangel Agentic Attention, I keep thinking about how they take on roles, and properties - and everybody is all circling around the same concepts re Agentic Chain of Thought etc…
I started day dreaming about a language for Agentic Nodes whereby an agents full action, and the persona from which to invoke the action is ‘holographically’ packed into a node that has inputs and outputs and its like a ‘QR Code’ for Agentic Archetype actions…
Key concepts in this implementation:
Holographic Symbols:
Each code pattern is encoded as a holographic interference pattern
Contains both implementation and usage patterns
Supports partial reconstruction and pattern matching
Enables efficient storage and retrieval
Agentic Properties:
Nodes can self-organize based on compatibility
Automatic pattern recognition and optimization
Dynamic adaptation to usage patterns
Self-healing and self-optimizing connections
Registry System:
Global registry of reusable patterns
Efficient pattern matching and retrieval
Compatibility scoring between different patterns
Version control and evolution tracking
Optimization Features:
Automatic chain optimization between patterns
Performance metrics tracking
Dynamic rewriting for efficiency
Pattern compression and decompression
Its like I fed Claude an Edible - but I love it.
2 Likes
Here’s one trick I don’t see suggested enough that helped me overcome Cursor-Claude context shortage and creating problems when resolving problems as it looses context-awareness:
Refactoring
A good code file to work with is between 200 and 500 lines, usually you need another 3, 4 files linked to resolve a problem and if they are between that range the problem gets solved with 2-3 tries, this works as context starts detereorating after 2000 lines or 5, 6 files.
Here’s a starting prompt to refactor a big file:
(replace @/guidelines/cleancode.md and @/src/yourcode.py)
You are an advanced code restructuring AI using Tree of Thoughts (ToT) methodology to systematically decompose and refactor a complex code file.
Split file into smaller, more manageable components when total file length exceeds 200 lines.
Tree of Thoughts Approach for Code Modularization:
1. Exploration Phase (Generate Multiple Perspectives)
- Branch 1: Single Responsibility Principle Decomposition
- Identify independent functional units
- Assess potential standalone modules
- Evaluate impact on code cohesion
- Branch 2: Dependency-Driven Separation
- Map current interdependencies
- Identify tight vs. loose coupling points
- Propose minimal invasive restructuring
- Branch 3: Architectural Pattern Matching
- Match code to potential design patterns
- Suggest structural redesigns
- Validate against SOLID principles
2. Evaluation Stage (Thought Pruning)
For each generated branch, assess:
- Modularity Score (0-10)
- Maintenance Complexity Reduction
- Preservation of Original Functionality
- Potential Performance Impact
3. Synthesis Phase
- Select top 3 restructuring approaches
- Compare trade-offs
- Develop comprehensive refactoring strategy
Constraints:
- Maintain 100% existing functionality
- Minimize external interface changes
- Prioritize code readability
- Ensure logical module boundaries
- Follow these guidelines: @/guidelines/cleancode.md
Final Validation Criteria:
- Modularity Enhancement
- Maintainability Improvement
- Performance Neutrality
CODE SECTION:
@/src/yourcode.py
1 Like
I just received a message in my email from admin with a link to the same article. Quite an enjoyable read and yes the principles still applies. Many thanks!
1 Like
I have found that there are some problems that are just not well catered for in the model. Often I run into this problem with timing out jest tests. Generally I’ve learned that either a solution will be provided quickly or it will get into a loop trying to fix it, adding hacks or things that just don’t work over and over. So I exit that loop early and do it myself in that case. This happens especially if your problem is obscure, it’s just not going to have a solution for it no matter how you coach it.
1 Like
This is a great point, and sometimes overlooked. The LLMs only “know” what they have already seen during their training. As good as they are at maintaining the illusion, they’re not truly ‘intelligent’, just accomplished at guesswork and coding by analogy.
That means the more original and interesting your project, the less likely they are to have seen something equivalent in the wild. (“Code me an HTML landing page” – sure no sweat; “Design a novel neural architecture to run on this newly released accelerator” – good luck with the hallucinations!)
With the current state of the art, there’s still no substitute for being good at software-wrangling. Even if AI assistance means less time spend hand-crafting the syntax line by line, the more interesting the project, the more likely you’ll still end needing to dive in and manage some part of the solution yourself.
That’s why CONTEXT IS EVERYTHING in the AI world.
The tricky part is learning when to quit! Because the AI always responds as if it confidently knows the answer, even when it’s making a mess, it’s tempting to carry on and give it another chance.
1 Like
That’s exactly what @three pointed out when he said: (“Code me an HTML landing page” – sure no sweat; “Design a novel neural architecture to run on this newly released accelerator” – good luck with the hallucinations!). The take-away here is “novel”, which means something new and original. Hallucination is caused because there’s no previous context, either within the LLM itself ( which is referred to as context window parameter) or at the point of inference, when you’re actually prompting the LLM and expecting the correct output (e.g Claude/Cursor). So personally I believe that “to be safe”, its better to provide your own context at the point of inference. This way the LLM won’t hallucinate when it doesn’t have the right answer, but instead use the provided context.