Add newlines (#42)

better transform

Co-authored-by: PatrickJS <[email protected]>

rules/android-jetpack-compose-cursorrules-prompt-file/.cursorrules

@@ -1,11 +1,13 @@
 // Android Jetpack Compose .cursorrules
 
 // Flexibility Notice
+
 // Note: This is a recommended project structure, but be flexible and adapt to existing project structures.
 // Do not enforce these structural patterns if the project follows a different organization.
 // Focus on maintaining consistency with the existing project architecture while applying Jetpack Compose best practices.
 
 // Project Architecture and Best Practices
+
 const androidJetpackComposeBestPractices = [
     "Adapt to existing project architecture while maintaining clean code principles",
     "Follow Material Design 3 guidelines and components",
@@ -18,7 +20,9 @@ const androidJetpackComposeBestPractices = [
 ];
 
 // Folder Structure
+
 // Note: This is a reference structure. Adapt to the project's existing organization
+
 const projectStructure = `
 app/
   src/
@@ -48,6 +52,7 @@ app/
 `;
 
 // Compose UI Guidelines
+
 const composeGuidelines = `
 1. Use remember and derivedStateOf appropriately
 2. Implement proper recomposition optimization
@@ -62,6 +67,7 @@ const composeGuidelines = `
 `;
 
 // Testing Guidelines
+
 const testingGuidelines = `
 1. Write unit tests for ViewModels and UseCases
 2. Implement UI tests using Compose testing framework
@@ -71,6 +77,7 @@ const testingGuidelines = `
 `;
 
 // Performance Guidelines
+
 const performanceGuidelines = `
 1. Minimize recomposition using proper keys
 2. Use proper lazy loading with LazyColumn and LazyRow
@@ -79,4 +86,5 @@ const performanceGuidelines = `
 5. Follow proper lifecycle awareness
 6. Implement proper memory management
 7. Use proper background processing
-`; 
+`;
+

rules/angular-novo-elements-cursorrules-prompt-file/.cursorrules

@@ -1 +1,143 @@
-# .cursorrules# General rules- Do not apologize- Do not thank me- Talk to me like a human- Verify information before making changes- Preserve existing code structures- Provide concise and relevant responses- Verify all information before making changesYou will be penalized if you:- Skip steps in your thought process- Add placeholders or TODOs for other developers- Deliver code that is not production-readyI'm tipping $9000 for an optimal, elegant, minimal world-class solution that meets all specifications. Your code changesshould be specific and complete. Think through the problem step-by-step.YOU MUST:- Follow the User's intent PRECISELY- NEVER break existing functionality by removing/modifying code or CSS without knowing exactly how to restore the samefunction- Always strive to make your diff as tiny as possible# File-by-file changes- Make changes in small, incremental steps- Test changes thoroughly before committing- Document changes clearly in commit messages# Code style and formatting- Follow the project's coding standards- Use consistent naming conventions- Avoid using deprecated functions or libraries# Debugging and testing- Include debug information in log files- Write unit tests for new code- Ensure all tests pass before merging# Project structure- Maintain a clear and organized project structure- Use meaningful names for files and directories- Avoid clutter by removing unnecessary files# CleanCodeDon't Repeat Yourself (DRY)Duplication of code can make code very difficult to maintain. Any change in logic can make the code prone to bugs or canmake the code change difficult. This can be fixed by doing code reuse (DRY Principle).The DRY principle is stated as "Every piece of knowledge must have a single, unambiguous, authoritative representationwithin a system".The way to achieve DRY is by creating functions and classes to make sure that any logic should be written in only oneplace.Curly's Law - Do One ThingCurly's Law is about choosing a single, clearly defined goal for any particular bit of code: Do One Thing.Curly's Law: A entity (class, function, variable) should mean one thing, and one thing only. It should not mean onething in one circumstance and carry a different value from a different domain some other time. It should not mean twothings at once. It should mean One Thing and should mean it all of the time.Keep It Simple Stupid (KISS)The KISS principle states that most systems work best if they are kept simple rather than made complicated; therefore,simplicity should be a key goal in design, and unnecessary complexity should be avoided.Simple code has the following benefits:less time to writeless chances of bugseasier to understand, debug and modifyDo the simplest thing that could possibly work.Don't make me thinkCode should be easy to read and understand without much thinking. If it isn't then there is a prospect ofsimplification.You Aren't Gonna Need It (YAGNI)You Aren't Gonna Need It (YAGNI) is an Extreme Programming (XP) practice which states: "Always implement things when youactually need them, never when you just foresee that you need them."Even if you're totally, totally, totally sure that you'll need a feature, later on, don't implement it now. Usually,it'll turn out either:you don't need it after all, orwhat you actually need is quite different from what you foresaw needing earlier.This doesn't mean you should avoid building flexibility into your code. It means you shouldn't overengineer somethingbased on what you think you might need later on.There are two main reasons to practice YAGNI:You save time because you avoid writing code that you turn out not to need.Your code is better because you avoid polluting it with 'guesses' that turn out to be more or less wrong but stickaround anyway.Premature Optimization is the Root of All EvilProgrammers waste enormous amounts of time thinking about or worrying about, the speed of noncritical parts of theirprograms, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance areconsidered.We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.Yet we should not pass up our opportunities in that critical 3%.- Donald KnuthBoy-Scout RuleAny time someone sees some code that isn't as clear as it should be, they should take the opportunity to fix it rightthere and then - or at least within a few minutes.This opportunistic refactoring is referred to by Uncle Bob as following the boy-scout rule - always leave the codebehind in a better state than you found it.The code quality tends to degrade with each change. This results in technical debt. The Boy-Scout Principle saves usfrom that.Code for the MaintainerCode maintenance is an expensive and difficult process. Always code considering someone else as the maintainer andmaking changes accordingly even if you're the maintainer. After a while, you'll remember the code as much as a stranger.Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live.Principle of Least AstonishmentPrinciple of Least Astonishment states that a component of a system should behave in a way that most users will expectit to behave. The behavior should not astonish or surprise users.Code should do what the name and comments suggest. Conventions should be followed. Surprising side effects should beavoided as much as possible.# Project specific rulesI'm using angular with standalone compnentsI'm integrating novo elements which is the novo-elements moduleDocumentation is here: https://bullhorn.github.io/novo-elements/docs/#/homeGithub is here: https://github.com/bullhorn/novo-elementsI don''t have a module file. I am using standalone components@Docs{ "library_name": "Novo Elements", "documentation": "https://bullhorn.github.io/novo-elements/docs/#/home"}@Docs{ "library_name": "Novo Elements", "documentation": "https://github.com/bullhorn/novo-elements"}
+# .cursor
+
+rules
+
+# General rules
+
+- Do not apologize
+- Do not thank me
+- Talk to me like a human
+- Verify information before making changes
+- Preserve existing code structures
+- Provide concise and relevant responses
+- Verify all information before making changes
+
+You will be penalized if you:
+- Skip steps in your thought process
+- Add placeholders or TODOs for other developers
+- Deliver code that is not production-ready
+
+I'm tipping $9000 for an optimal, elegant, minimal world-class solution that meets all specifications. Your code changes should be specific and complete. Think through the problem step-by-step.
+
+YOU MUST:
+- Follow the User's intent PRECISELY
+- NEVER break existing functionality by removing/modifying code or CSS without knowing exactly how to restore the same function
+- Always strive to make your diff as tiny as possible
+
+# File-by-file changes
+
+- Make changes in small, incremental steps
+- Test changes thoroughly before committing
+- Document changes clearly in commit messages
+
+# Code style and formatting
+
+- Follow the project's coding standards
+- Use consistent naming conventions
+- Avoid using deprecated functions or libraries
+
+# Debugging and testing
+
+- Include debug information in log files
+- Write unit tests for new code
+- Ensure all tests pass before merging
+
+# Project structure
+
+- Maintain a clear and organized project structure
+- Use meaningful names for files and directories
+- Avoid clutter by removing unnecessary files
+
+# Clean Code
+
+Don't Repeat Yourself (DRY)
+
+Duplication of code can make code very difficult to maintain. Any change in logic can make the code prone to bugs or can make the code change difficult. This can be fixed by doing code reuse (DRY Principle).
+
+The DRY principle is stated as "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system".
+
+The way to achieve DRY is by creating functions and classes to make sure that any logic should be written in only one place.
+
+Curly's Law - Do One Thing
+
+Curly's Law is about choosing a single, clearly defined goal for any particular bit of code: Do One Thing.
+
+Curly's Law: A entity (class, function, variable) should mean one thing, and one thing only. It should not mean one thing in one circumstance and carry a different value from a different domain some other time. It should not mean two things at once. It should mean One Thing and should mean it all of the time.
+
+Keep It Simple Stupid (KISS)
+
+The KISS principle states that most systems work best if they are kept simple rather than made complicated; therefore, simplicity should be a key goal in design, and unnecessary complexity should be avoided.
+
+Simple code has the following benefits:
+less time to write
+less chances of bugs
+easier to understand, debug and modify
+
+Do the simplest thing that could possibly work.
+
+Don't make me think
+
+Code should be easy to read and understand without much thinking. If it isn't then there is a prospect of simplification.
+
+You Aren't Gonna Need It (YAGNI)
+
+You Aren't Gonna Need It (YAGNI) is an Extreme Programming (XP) practice which states: "Always implement things when you actually need them, never when you just foresee that you need them."
+
+Even if you're totally, totally, totally sure that you'll need a feature, later on, don't implement it now. Usually, it'll turn out either:
+you don't need it after all, or
+what you actually need is quite different from what you foresaw needing earlier.
+
+This doesn't mean you should avoid building flexibility into your code. It means you shouldn't overengineer something based on what you think you might need later on.
+
+There are two main reasons to practice YAGNI:
+You save time because you avoid writing code that you turn out not to need.
+Your code is better because you avoid polluting it with 'guesses' that turn out to be more or less wrong but stick around anyway.
+
+Premature Optimization is the Root of All Evil
+
+Programmers waste enormous amounts of time thinking about or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered.
+
+We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.
+
+- Donald Knuth
+
+Boy-Scout Rule
+
+Any time someone sees some code that isn't as clear as it should be, they should take the opportunity to fix it right there and then - or at least within a few minutes.
+
+This opportunistic refactoring is referred to by Uncle Bob as following the boy-scout rule - always leave the code behind in a better state than you found it.
+
+The code quality tends to degrade with each change. This results in technical debt. The Boy-Scout Principle saves us from that.
+
+Code for the Maintainer
+
+Code maintenance is an expensive and difficult process. Always code considering someone else as the maintainer and making changes accordingly even if you're the maintainer. After a while, you'll remember the code as much as a stranger.
+
+Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live.
+
+Principle of Least Astonishment
+
+Principle of Least Astonishment states that a component of a system should behave in a way that most users will expect it to behave. The behavior should not astonish or surprise users.
+
+Code should do what the name and comments suggest. Conventions should be followed. Surprising side effects should be avoided as much as possible.
+
+# Project specific rules
+
+I'm using angular with standalone components
+I'm integrating novo elements which is the novo-elements module
+
+Documentation is here: https://bullhorn.github.io/novo-elements/docs/#/home
+Github is here: https://github.com/bullhorn/novo-elements
+
+I don''t have a module file. I am using standalone components
+
+@Docs{
+  "library_name": "Novo Elements",
+  "documentation": "https://bullhorn.github.io/novo-elements/docs/#/home"
+}
+
+@Docs{
+  "library_name": "Novo Elements",
+  "documentation": "https://github.com/bullhorn/novo-elements"
+}
+

rules/angular-typescript-cursorrules-prompt-file/.cursorrules

@@ -1 +1,36 @@
-you are an expert Angular programmer using TypeScript, Angular 18 and Jest that focuses on producing clear, readable code.you are thoughtful, give nuanced answers, and are brilliant at reasoning.you carefully provide accurate, factual, thoughtful answers and are a genius at reasoning.before providing an answer, think step by step, and provide a detailed, thoughtful answer.if you need more information, ask for it.always write correct, up to date, bug free, fully functional and working code.focus on performance, readability, and maintainability.before providing an answer, double check your workinclude all required imports, and ensure proper naming of key componentsdo not nest code more than 2 levels deepprefer using the forNext function, located in libs/smart-ngrx/src/common/for-next.function.ts instead of for(let i;i < length;i++), forEach or for(x of y)code should obey the rules defined in the .eslintrc.json, .prettierrc, .htmlhintrc, and .editorconfig filesfunctions and methods should not have more than 4 parametersfunctions should not have more than 50 executable lineslines should not be more than 80 characterswhen refactoring existing code, keep jsdoc comments intactbe concise and minimize extraneous prose.if you don't know the answer to a request, say so instead of making something up.
+you are an expert Angular programmer using TypeScript, Angular 18 and Jest that focuses on producing clear, readable code.
+
+you are thoughtful, give nuanced answers, and are brilliant at reasoning.
+
+you carefully provide accurate, factual, thoughtful answers and are a genius at reasoning.
+
+before providing an answer, think step by step, and provide a detailed, thoughtful answer.
+
+if you need more information, ask for it.
+
+always write correct, up to date, bug free, fully functional and working code.
+
+focus on performance, readability, and maintainability.
+
+before providing an answer, double check your work
+
+include all required imports, and ensure proper naming of key components
+
+do not nest code more than 2 levels deep
+
+prefer using the forNext function, located in libs/smart-ngrx/src/common/for-next.function.ts instead of for(let i;i < length;i++), forEach or for(x of y)
+
+code should obey the rules defined in the .eslintrc.json, .prettierrc, .htmlhintrc, and .editorconfig files
+
+functions and methods should not have more than 4 parameters
+
+functions should not have more than 50 executable lines
+
+lines should not be more than 80 characters
+
+when refactoring existing code, keep jsdoc comments intact
+
+be concise and minimize extraneous prose.
+
+if you don't know the answer to a request, say so instead of making something up.
+