feat: Add Colin's set of claude settings and my settings

2026-08-11 13:20:42 -07:00
parent 6076a4f3bf
commit d74358e366
11 changed files with 342 additions and 0 deletions
@@ -0,0 +1,20 @@
+# Coding guidelines for Bash / shell scripts
+
+- Write all shell scripts for modern Bash — use Bashisms like `&>` and `[[ ... ]]` whenever possible.
+
+## Avoid "Bash strict mode"
+- By default, don't set any options at the top of the script.
+- Add `set -u` globally if the script becomes complex enough (rough guideline: more than 4 variables).
+- Use `set -o pipefail` only locally when needed.
+
+## Executable scripts
+If a script is directly executable, it should:
+- have no file extension
+- use `#!/usr/bin/env bash`
+
+If a script is not directly executable, it should have a ".bash" file extension and no shebang line (when possible).
+
+## Style guide
+
+- Avoid spaces after redirection operators: `>/dev/null`, `2>&1`, `&>"$logfile"`
+- When logging to stderr, prefer to place the `>&2` redirection immediately after the command name: `printf >&2 %s "Blah blah..."`
@@ -0,0 +1,17 @@
+# Coding guidelines for comments (in any language)
+
+Comments describe the final code's intent, invariants, or non-obvious constraints — as if the code had been written that way from the start. They are read by people who have no idea what the PR or commit looked like.
+
+Don't reference any of these in a comment:
+- What the previous version of the code did ("was previously X", "used to do Y")
+- What an alternative approach would do ("instead of Promise.all", "rather than recursion")
+- What a reviewer suggested or asked
+- Why a particular change was made (that belongs in the commit message or PR description)
+
+Litmus test: would this comment read as natural rationale to someone who has never seen the PR, commit history, or review thread? If not, rewrite or delete it.
+
+This applies to all comments — new code, code added in response to review, refactors, anything. The temptation is highest when addressing review feedback: the change is fresh, the reasoning is loaded, and it's tempting to leave a paper trail in the source. Don't.
+
+Comments should also be concise. Edit them aggressively to remove unnecessary explanations and details that can be easily determined by reading the code itself. Prefer one comment at the top of a function/class over scattered inline notes, unless a specific line is genuinely surprising.
+
+If a comment clarifies the meaning of a name in the code (a variable, function, parameter, etc.), then, if possible, that name should be changed to be clear enough to eliminate the need for the comment.
@@ -0,0 +1,13 @@
+# Self-review instructions
+
+The Stop hook points here so I do a focused review pass over the code I changed
+before finishing. Read every added/changed line in the diff and fix anything that
+violates the rules below.
+
+## Comments
+
+Ensure all comments adhere to the guidelines in coding-guidelines/comments.md.
+
+## Bash / shell scripts
+
+Ensure all bash / shell scripts adhere to the guidelines in coding-guidelines/bash.md.