cursor rule typos

Author: darthwalsh

dotfiles/ai.md

@@ -48,8 +48,16 @@ When I reference file(s) from `MyNotes/inbox/ai/` (chats with GPT) using "@" in
     - Incorporates insights from semantically related notes found via Smart Connections
     - The goal is **curated, structured knowledge** that's easy to reference later, not a verbatim copy of the source material.
 
+    **Redundancy rules**:
+    - Never state the same fact in two places (e.g. table cell AND a separate paragraph). Pick the one best location.
+    - If a fact fits in a table cell, keep it there — don't also write a standalone paragraph restating it.
+    - Don't add table columns where values are obvious from context or uniform across all rows.
+    - When `bin/apps/` already has a dedicated page for a topic, use a `[[wikilink]]` cross-reference as mentioned in @markdown.mdc
+
+    **Link placement**: attach URLs to the named concept inline, not as trailing "See [link]" or "[Vendor] documents this [URL]". Prefer `[Windows Setup](URL) does X` over `Windows Setup does X. [Microsoft docs](URL).` as mentioned in @markdown.mdc
+
 4. As you end each iteration, check back on the task list, and for which possible content hasn't been extracted yet
     1. In an earlier chat, I might have said I wanted to come back to another topic.
     2. List possible goals/tasks.
-    3. Output a code block with individual `trash` lines for files in `~/notes/MyNotes/inbox/` or `MyNotes/`; I'll decide what to run.
+    3. Output a code block with individual `trash` lines for files in `~/notes/MyNotes/inbox/` or `MyNotes/` (ending with extra blank line); I'll decide what to run.
     4. Do not try to delete existing files using Agent native functionality or your terminal/tools.

dotfiles/claude/settings.json

@@ -7,14 +7,14 @@
       "Bash(gh pr view *)",
       "Bash(gh search *)",
       "Bash(git --no-pager diff *)",
+      "Bash(brew deps *)",
+      "Bash(find *)",
       "Bash(git --no-pager log *)",
       "Bash(git add *)",
       "Bash(git branch*)",
       "Bash(git checkout *)",
       "Bash(git commit *)",
       "Bash(git config my.default.branch)",
-      "Bash(brew deps *)",
-      "Bash(find *)",
       "Bash(git diff *)",
       "Bash(git log *)",
       "Bash(git show *)",
@@ -38,6 +38,8 @@
       "Glob(./**)",
       "Grep(./**)",
       "Read(./**)",
+      "Read(//private/var/folders/**)",
+      "Read(//var/folders/**)",
       "Read(~/.claude/**)",
       "Read(~/Library/Application Support/Cursor/**)",
       "WebFetch",

dotfiles/coding.mdc

@@ -10,11 +10,11 @@ If deviating from any requirement in prompt or guidelines, state those clearly i
 
 If the solution to a problem will involve a large change (200+ lines of code, or touching 10+ files), first confirm if this plan is good, showing an example diff. Also consider if a well-maintained library or tool exists.
 
-Follow DRY to not code the same pattern on the **third** times, only creating abstraction when it makes the code more readable.
+Follow DRY to not code the same pattern on the **third** time, only creating abstraction when it makes the code more readable.
 
 Identify a minimal set of tests to run (or just all unit tests), plus any affected E2E test. 
 After each change, use README.md for instructions and run code formatter / linter / type checker / tests.
-For tests, *DO NOT* success/skip test case if required machine setup (creds, env vars, libraries, etc.) is needed.
+For tests, *DO NOT* mark test case as `skip` if required machine setup (creds, env vars, libraries, etc.) is needed.
 
 Assume mid-level developers are reading the code (don't over-explain obvious things).
 Remove "how" comments that just restate what the code does. Keep "why" comments that explain reasoning. If a code-block is complex, consider refactoring it into a function for easier testing.

dotfiles/markdown.mdc

@@ -23,7 +23,7 @@ Pronouns: Normally best to avoid pronouns, i.e/ "Run this command:" but if you m
 - Don't use horizontal rules `---` between each heading. Reserve for significant breaks in the content.
 
 ## Code Examples
-- If its hard to see in the code, use `❌ or ✅ or ⚠️ OOPS! <explanation of what's wrong>` in source-code comment
+- If it's hard to see in the code, use `❌ or ✅ or ⚠️ OOPS! <explanation of what's wrong>` in source-code comment
 - Be specific about what breaks: "Could leak to multiple invocations" not "this is bad"
 
 ## Cross-references

dotfiles/python.mdc

@@ -43,7 +43,7 @@ logging.basicConfig(format="[%(asctime)s] {%(filename)s:%(lineno)d} %(levelname)
 
 - All human-readable messages go through `logging` (never `print(..., file=sys.stderr)`)
 - `print()` is reserved for exact stdout output intended for scripting/piping (e.g. a `list` subcommand printing URLs)
-- Use `sys.exit("THE MESSAGE")` for fatal user errors instead of `print(..., file=sys.stderr)` + `sys.exit(1)`
+- Use `sys.exit("Human-friendly message here")` for fatal user errors instead of `print(..., file=sys.stderr)` + `sys.exit(1)`
 
 ## pytest
 - Prefer `yield` fixtures over `setup_method`/`teardown_method`

snippets/ai summary.json

@@ -2,6 +2,6 @@
   {
     "keyword" : "ai-sum",
     "name" : "ai summary",
-    "text" : "Summarize this conversation as a memory refresher, not a tutorial.\n\nFor each of my prompts, start with one line summary that encompasses my entire prompt.\nThen follow with 1-3 bullets that summarize the material that you responded with, ignoring any introductory \/ what-should-we-follow-up-with text. (Key insights \/ corrections \/ clarification questions)\n\nThe output should follow this literal structure:\n\nSummary of first query I gave\n- Important insight\n- Clarification question of ambiguous term\n\nSecond prompt from me, summarized to just one line\n- AI response\n\nThird, etc, etc\n- Third response, etc. etc.\n"
+    "text" : "Summarize this conversation as a memory refresher, not a tutorial.\n\nFor each group of related concepts I discuss, start with one line summary that encompasses my entire prompt.\nThen follow with 1-3 bullets that summarize the material that you responded with, ignoring any introductory \/ what-should-we-follow-up-with text. (Key insights \/ corrections \/ clarification questions)\nIf I respond back challenging you to go deeper or pushing you in another direction, that means that the previous response was probably not good, so focus less on that. \nGroup together multiple human\/ai chats when they cover related areas and can have and you can combine their discussions together to be more semantically relevant.\n\n\nThe output should follow this literal structure:\n\nSummary of first queries I gave (summarized to just one line, including clarification we exclude irrelevant someone)\n- Important insight\n- important design flaw\n- connection to another idea\n\nSecond prompt concepts from me, rtc\n- AI response theme 1\n- AI response idea 2, etc\n\n\n(etc, etc for the whole conversation)\n\nAt the end, include task list of any phrases FROM ME that are worded like:\n- I could\n- Remind me\n- Follow up\n- Put a pin in that\n- For later\n- I'll test\n- Later I'll\n(Omit task list if empty!)\n\nLast, create a new 4-6 word tiny summary of concepts I was asking about that I can use as chat summary. Append additional two-word summaries of each task. (Omit task list if empty.)\nUse markdown code block for tiny summary so I can copy easily. Limit tiny summary to Windows\/Mac filesystem chars. Example:\n```\nFedora vs Arch docker devcontainer. Docker sandbox... CRIU installed...\n```"
   }
-]
+]