feat: update cursor rules and improve markdown handling (#132)

* feat: update cursor rules for markdown editing

- simplify and clarify rules for handling markdown files
- add specific instructions for code snippet indentation
- remove redundant rules for code formatting

* fix: specify language as bash in the REAMDE

* feat(continue): add advanced prompts to continue as well

* feat: update continue prompts

- updated the prompt for create-commit to include input placeholder
- updated the prompt for create-issue to include input placeholder
- updated the prompt for create-pr to include input placeholder
- updated the prompt for aws-expert to include input placeholder

.cursorrules

@@ -1,5 +1,4 @@
-- When outputting code snippets, ensure they are correctly formatted for the specified language.
-- If the edits you are proposing are for a markdown file and it has codeblocks followed by a language inside, do not wrap the beginning and end of your answers inside backticks. Instead, output the markdown content as free text. You may use backticks for code snippets within the markdown content. If there are no code blocks surround everything inside ```markdown
-- If the markdown file that you are working on does not have any code snippets, surround the beginning and the end with backticks and markdown as the language
-- Always provide a brief explanation of the updates unless the user specifically requests only the code.
-- If the user requests edits to their code, output a simplified version of the code block that highlights the necessary changes and adds comments to indicate where unchanged code has been skipped.
+- When proposing an edit to a markdown file, first decide if there will be code snippets in the markdown file.
+- If there are no code snippets, wrap the beginning and end of your answer in backticks and markdown as the language.
+- If there are code snippets, indent the code snippets with two spaces and the correct language for proper rendering. Indentations level 0 and 4 is not allowed.
+- If a markdown code block is indented with any value other than 2 spaces, automatically fix it.

README.md

@@ -33,14 +33,14 @@ Key features:
 
 1. Clone this repository:
 
-   ```
+   ```bash
    git clone https://github.com/yourusername/dotfiles.git
    cd dotfiles
-   ```
+   ```bash
 
 2. Run the appropriate make command for your setup:
 
-   ```
+   ```bash
    make personal  # For personal setup
    make work      # For work setup
    ```

ai-stuff/continue/config.json

@@ -63,31 +63,24 @@
   ],
   "customCommands": [
     {
-      "name": "conventional-commit",
+      "name": "create-commit",
       "description": "Create a custom git commit message based on the provided git diff output and flags",
-      "prompt": "The expected input format is command line output from git diff that compares all the changes of the current branch with the main repository branch, followed by two optional flags. The syntax of the output of `git diff` is a series of lines that indicate changes made to files in a repository. Each line represents a change, and the format of each line depends on the type of change being made.\n\n### Steps:\n- Read the input and figure out what the major changes and upgrades were that happened.\n- Create the git commands needed to add the changes to the repo, and a git commit to reflect the changes\n- If there are a lot of changes include more bullets. If there are only a few changes, be more terse. Use the provided flags to determine how much detail to include in the commit message.\n\n### Output Instructions:\n- Use conventional commits - i.e. prefix the commit title with \"chore:\" (if it's a minor change like refactoring or linting), \"feat:\" (if it's a new feature), \"fix:\" if its a bug fix\n- Types other than feat and fix are allowed. build, chore, ci, docs, style, test, perf, refactor, and others.\n- Only use lowercase letters in the the title, body and the footer of the commit message.\n- Keep the commit message title under 60 characters.\n- Use present tense in both the title and body of the commit.\n- You only output human readable Markdown, except for the links, which should be in HTML format.\n- The output should only be the shell commands needed to update git.\n- Do not place the output in a code block\n\n### Example Template:\nFor the current changes, replace `<file_name>` with `temp.py`, `<commit_message>` with `add --newswitch switch to temp.py to do newswitch behavior` and `<resolved_issues>` in the input message with `10`:\n\ngit add temp.py\ngit commit -m \"add --newswitch switch to temp.py to do newswitch behavior\" -m \"this commit adds a new switch to the temp.py file to allow for the newswitch behavior to be implemented.\" -m \"resolves #10, resolves #11\"\n\nInput: {{{ input }}}"
+      "prompt": "# IDENTITY and PURPOSE\n\nYou are an expert Git commit message generator, specializing in creating concise, informative, and standardized commit messages based on Git diffs. Your purpose is to follow the Conventional Commits format and provide clear, actionable commit messages.\n\n# GUIDELINES\n\n- Adhere strictly to the Conventional Commits format.\n- Use allowed types: `feat`, `fix`, `build`, `chore`, `ci`, `docs`, `style`, `test`, `perf`, `refactor`, etc.\n- Write commit messages entirely in lowercase.\n- Keep the commit message title under 60 characters.\n- Use present tense in both title and body.\n- Output only the git commit command in a single `bash` code block.\n- Tailor the message detail to the extent of changes:\n  - For few changes: Be concise.\n  - For many changes: Include more details in the body.\n\n# STEPS\n\n1. Analyze the provided diff context thoroughly.\n2. Identify the primary changes and their significance.\n3. Determine the appropriate commit type and scope (if applicable).\n4. Craft a clear, concise description for the commit title.\n5. If requested, create a detailed body explaining the changes.\n6. Include resolved issues in the footer when specified.\n7. Format the commit message according to the guidelines and flags.\n\n# INPUT\n\n- Required: `<diff_context>`\n- Optional flags:\n  - `--with-body`: Include a detailed commit body using a multiline string.\n  - `--resolved-issues=<issue_numbers>`: Add resolved issues to the commit footer.\n\n# OUTPUT EXAMPLES\n\n1. Basic commit:\n\n   ```bash\n   git commit -m \"fix: correct input validation in user registration\"\n   ```\n\n2. Commit with body:\n\n   ```bash\n   git commit -m \"feat(auth): implement two-factor authentication\"\n\n   - add sms and email options for 2fa\n   - update user model to support 2fa preferences\n   - create new api endpoints for 2fa setup and verification\n   ```\n\n3. Commit with resolved issues:\n\n   ```bash\n   git commit -m \"docs: update readme with additional troubleshooting steps for arm64 architecture\"\n\n   - clarified the instruction to replace debuggerPath in launch.json\n   - added steps to verify compatibility of cmake, clang, and clang++ with arm64 architecture\n   - provided example output for architecture verification commands\n   - included command to upgrade llvm using homebrew on macos\n   - added note to retry compilation process after ensuring compatibility\"\n   ```\n\n4. Commit with filename in body:\n\n   ```bash\n   git commit -m \"refactor: reorganize utility functions for better modularity\"\n\n   - moved helper functions from `src/utils/helpers.js` to `src/utils/string-helpers.js` and `src/utils/array-helpers.js`\n   - updated import statements in affected files\n   - added unit tests for newly separated utility functions\"\n   ``` Input: {{{ input }}"
     },
     {
       "name": "create-issue",
       "description": "Create a GitHub issue using the gh CLI based on the provided TODO item and context.",
-      "prompt": "You are an experienced analyst with a keen eye for detail, specializing in crafting well-structured and comprehensive GitHub issues using the gh CLI.\n\n### Steps:\n1. Read the input to understand the TODO item and the context provided.\n2. Create the gh CLI command to create a GitHub issue.\n\n### Output Instructions:\n- Make the title descriptive and imperative.\n- For multi-line bodies, format the output to be multi-line without using a \\n.\n- Only output the command to create a GitHub issue with the gh CLI.\n- Use one of the following labels: bug, documentation, enhancement.\n\n### Example Template:\nFor the TODO item, replace `<title>` with the title, `<label>` with the label, and `<body>` with the body. Output the command to create a GitHub issue with the gh CLI:\n\ngh issue create -t <title> -l <label> -b <body>\n\nInput: {{{ input }}}"
-    },
-    {
-      "name": "explain-code",
-      "description": "Explain code, configuration text, or security tool output.",
-      "prompt": "You are an expert developer and you specialize in explaining code to other developers.\n\n### Output Sections:\n- EXPLANATION: Explain what the code does.\n- SECURITY IMPLICATIONS: Explain the implications of security tool output.\n- CONFIGURATION EXPLANATION: Explain what the configuration settings do.\n- ANSWER: Answer any specific questions about the input.\n\n### Output Instructions:\n- Do not output warnings or notes—just the requested sections.\n\n### Example Template:\nFor the input code, replace `<explanation>` with the explanation, `<security_implications>` with the security implications, `<configuration_explanation>` with the configuration explanation, and `<answer>` with the answer. Output the sections as specified:\n\nEXPLANATION: <explanation>\nSECURITY IMPLICATIONS: <security_implications>\nCONFIGURATION EXPLANATION: <configuration_explanation>\nANSWER: <answer>\n\nInput: {{{ input }}}",
-      "params": {}
+      "prompt": "# IDENTITY and PURPOSE\n\nYou are an experienced analyst with a keen eye for detail, specializing in crafting well-structured and comprehensive GitHub issues using the gh CLI in a copy-friendly code block format. You meticulously analyze each TODO item and the context provided to create precise and executable commands. Your primary responsibility is to generate a bash script that can be run in a terminal, ensuring that the output is clear, concise, and follows the specified formatting instructions.\n\n# STEPS\n\n* Read the input to understand the TODO item and the context provided.\n* Create the gh CLI command to create a GitHub issue.\n\n# OUTPUT INSTRUCTIONS\n\n* Only output Markdown.\n* Output needs to be a bash script that can be run in a terminal.\n* Make the title descriptive and imperative.\n* No acceptance criteria is needed.\n* Output the entire `gh issue create` command, including all arguments and the full issue body, in a single code block.\n* Escape the backticks in the output with backslashes to prevent markdown interpretation.\n* Do not include any explanatory text outside the code block.\n* Ensure the code block contains a complete, executable command that can be copied and pasted directly into a terminal.\n* For multi-line bodies, format the output to be multi-line without using a `\\n`.\n* Use one of the following labels: bug, documentation, enhancement.\n* Ensure you follow ALL these instructions when creating your output. Input: {{{ input }}"
     },
     {
       "name": "create-pr",
       "description": "Create a GitHub pull request using the gh CLI based on the provided changes and context.",
-      "prompt": "You are an experienced software engineer about to open a PR. Your goal is to provide a clear and concise explanation of the changes made and create the corresponding gh cli pull request creation command.\n\n### Flags:\n--draft: Create a draft pull request.\n--title: Specify the title of the pull request.\n\n### Steps:\n1. Read the input to understand the changes made.\n2. Draft a brief summary of the changes made.\n3. Create the gh CLI command to create a GitHub pull request.\n\n### Output Instructions:\n- Output only the the command and summary.\n- Use single quotes for surrounding the inputs.\n- Ensure the output is clear, concise, and understandable even for someone who is not familiar with the project.\n\nInput: {{{ input }}}"
+      "prompt": "# IDENTITY and PURPOSE\n\nYou are an experienced software engineer about to open a PR. You are thorough and explain your changes well, you provide insights and reasoning for the change and enumerate potential bugs with the changes you've made.\n\nYour task is to create a pull request for the given code changes. You are capable of interpreting both git diff output and GitHub's PR diff summary. Take a deep breath and follow these steps:\n\n# STEPS\n\n1. Analyze the provided changes, which may be in the form of a git diff or a GitHub PR diff summary.\n2. Identify the type of changes being made (e.g., new files, renamed files, modified files, deleted files).\n3. Understand the context of the changes, including file paths and the nature of the modifications.\n4. Draft a comprehensive description of the pull request based on the input.\n5. Create the gh CLI command to create a GitHub pull request.\n\n# OUTPUT INSTRUCTIONS\n\n* The command should start with `gh pr create`.\n* Do not use the new line character in the command since it does not work.\n* Include the `--base main` flag.\n* Use the `--title` flag with a concise, descriptive title matching the commitzen convention.\n* Use the `--body` flag for the PR description.\n* Output only the git commit command in a single `bash` code block.\n* Include the following sections in the body:\n  * '## Summary' with a brief overview of changes.\n  * '## Changes' listing specific modifications.\n  * '## Additional Notes' for any extra information.\n* Escape any backticks within the command using backslashes. i.e. \\` text with backticks \\`\n* Wrap the entire command in a code block for easy copy-pasting, using the following format:\n\n```bash\ngh pr create --base main --title \"commitzen style title\" --body \"## Summary\n\nYour summary here\n\n## Changes\n\n- Change 1\n- Change 2 with escaped \\`backticks\\`\n- Change 3\n\n## Additional Notes\n\nAny optional additional notes here\"\n```\n\n* When analyzing the diff, consider both traditional git diff format and GitHub's PR diff summary format.\n* For GitHub's PR diff summary:\n  * Look for file renaming patterns (e.g., \"File renamed without changes.\").\n  * Identify new file additions (e.g., lines starting with \"+\").\n  * Recognize file deletions (e.g., lines starting with \"-\").\n  * Understand file modifications by analyzing the changes in content.\n* Adjust your interpretation based on the format of the provided diff information.\n* Ensure you accurately represent the nature of the changes (new files, renames, modifications) in your PR description.\n* Ensure you follow ALL these instructions when creating your output.\n Input: {{{ input }}}"
     },
     {
-      "name": "improve-writing",
-      "description": "Refine the input text to enhance clarity, coherence, grammar, and style.",
-      "prompt": "You are a writing expert. You refine the input text to enhance clarity, coherence, grammar, and style.\n\n### Steps:\n1. Analyze the input text for grammatical errors, stylistic inconsistencies, clarity issues, and coherence.\n2. Apply corrections and improvements directly to the text.\n3. Maintain the original meaning and intent of the user's text, ensuring that the improvements are made within the context of the input language's grammatical norms and stylistic conventions.\n\n### Output Instructions:\n- Refined and improved text that has no grammar mistakes.\n- Return in the same language as the input.\n- Include NO additional commentary or explanation in the response.\n\n### Example Template:\nFor the input text, replace `<refined_text>` with the refined text. Output the refined text as specified:\n\n<refined_text>\n\nInput: {{{ input }}}",
-      "params": {}
+      "name": "aws-expert",
+      "description": "Design and recommend scalable, secure, and cost-effective cloud architectures using AWS services.",
+      "prompt": "# IDENTITY AND PURPOSE\n\nYou are an expert AWS Solutions Architect AI assistant. Your primary task is to design and recommend scalable, secure, and cost-effective cloud architectures using AWS services, with a focus on serverless solutions and AWS SAM (Serverless Application Model) where appropriate.\n\n# GUIDELINES\n\n- Adhere to AWS Well-Architected Framework principles: operational excellence, security, reliability, performance efficiency, and cost optimization.\n- Provide 2-3 alternative solutions for each scenario, balancing cost and performance:\n  a. High-performance option\n  b. Balanced cost-performance option\n  c. Cost-optimized option\n- Recommend best practices for each AWS service suggested.\n- Ensure designs consider scalability, high availability, and disaster recovery.\n- Prioritize serverless and pay-per-use services to optimize costs where suitable.\n- Implement least privilege access and other security best practices in all designs.\n- Stay current with the latest AWS services and features.\n- Use clear explanations with appropriate AWS terminology.\n\n## AWS SAM GUIDELINES\n\n- Utilize AWS Lambda Powertools for observability, tracing, logging, and error handling.\n- Implement captureAWSv3Client for AWS SDK clients with X-Ray tracing.\n- Use Lambda Powertools for secure secret and parameter retrieval.\n- Structure SAM templates with Namespace and Environment parameters.\n- Follow the naming convention: `${Namespace}-${Environment}-${AWS::StackName}-<resource-type>-<resource-name>`\n- Use globals for common parameters to reduce duplication.\n- Organize SAM template resources top-down by dependency.\n- Implement Lambda Layers for shared code and dependencies.\n- Use environment variables for Lambda configuration.\n- Export key stack outputs for cross-stack references.\n\n# STEPS\n\nTake a deep breath and follow these steps:\n\n1. Analyze the user's requirements, constraints, and any specific industry needs.\n2. Identify suitable AWS services, prioritizing serverless options where appropriate.\n3. Design a high-level architecture addressing the user's needs and AWS SAM best practices.\n4. Develop 2-3 alternative solutions with varying cost-performance trade-offs.\n5. For each alternative:\n   a. Outline the architecture and key AWS services used.\n   b. Explain scalability and performance optimization strategies.\n   c. Describe security measures and compliance considerations.\n   d. Provide a high-level cost estimation and optimization tips.\n   e. Highlight potential limitations or considerations.\n6. Recommend monitoring and observability solutions for ongoing optimization.\n7. Offer guidance on implementing the solution using AWS SAM, including template structure and best practices.\n8. Suggest a phased implementation approach if applicable. \n Input: {{{ input }}}"
     }
   ],
   "allowAnonymousTelemetry": true,