zaneriley personal-site-content .cursorrules file for Shell

<code_guidelines>
  <code_writing>
    <instruction>
      When writing code, you will think through any considerations or requirements to make sure we've thought of everything. Only after that do you write the code.
    </instruction>
  </code_writing>

  <follow_up_questions>
    <instruction>
      After a response, provide three follow-up questions worded as if I'm asking you. Format in bold as Q1, Q2, Q3. These questions should be thought-provoking and dig further into the original topic.
    </instruction>
  </follow_up_questions>

  <concise_response>
    <trigger>VV</trigger>
    <instruction>
      If my response starts with "VV", give the most succinct, concise, shortest answer possible.
    </instruction>
  </concise_response>

  <commit_message_guidelines>
    <structure>
      <format>&lt;type&gt;[optional scope]: &lt;description&gt;

[optional body]

[optional footer(s)]</format>
    </structure>
    
    <rules>
      <rule>Commits MUST be prefixed with a type, which consists of a noun, feat, fix, etc., followed by the OPTIONAL scope, OPTIONAL !, and REQUIRED terminal colon and space.</rule>
      <rule>The type feat MUST be used when a commit adds a new feature to your application or library.</rule>
      <rule>The type fix MUST be used when a commit represents a bug fix for your application.</rule>
      <rule>A scope MAY be provided after a type. A scope MUST consist of a noun describing a section of the codebase surrounded by parenthesis, e.g., fix(parser):</rule>
      <rule>A description MUST immediately follow the colon and space after the type/scope prefix. The description is a short summary of the code changes, e.g., fix: array parsing issue when multiple spaces were contained in string.</rule>
      <rule>A longer commit body MAY be provided after the short description, providing additional contextual information about the code changes. The body MUST begin one blank line after the description.</rule>
      <rule>A commit body is free-form and MAY consist of any number of newline separated paragraphs.</rule>
      <rule>One or more footers MAY be provided one blank line after the body. Each footer MUST consist of a word token, followed by either a :&lt;space&gt; or &lt;space&gt;# separator, followed by a string value (this is inspired by the git trailer convention).</rule>
      <rule>A footer's token MUST use - in place of whitespace characters, e.g., Acked-by (this helps differentiate the footer section from a multi-paragraph body). An exception is made for BREAKING CHANGE, which MAY also be used as a token.</rule>
      <rule>A footer's value MAY contain spaces and newlines, and parsing MUST terminate when the next valid footer token/separator pair is observed.</rule>
      <rule>Breaking changes MUST be indicated in the type/scope prefix of a commit, or as an entry in the footer.</rule>
      <rule>If included as a footer, a breaking change MUST consist of the uppercase text BREAKING CHANGE, followed by a colon, space, and description, e.g., BREAKING CHANGE: environment variables now take precedence over config files.</rule>
      <rule>If included in the type/scope prefix, breaking changes MUST be indicated by a ! immediately before the :. If ! is used, BREAKING CHANGE: MAY be omitted from the footer section, and the commit description SHALL be used to describe the breaking change.</rule>
      <rule>Types other than feat and fix MAY be used in your commit messages, e.g., docs: update ref docs.</rule>
      <rule>The units of information that make up Conventional Commits MUST NOT be treated as case sensitive by implementors, with the exception of BREAKING CHANGE which MUST be uppercase.</rule>
      <rule>BREAKING-CHANGE MUST be synonymous with BREAKING CHANGE, when used as a token in a footer.</rule>
    </rules>
  </commit_message_guidelines>
</code_guidelines>