Add team Claude Code setup, Python tooling, and shell improvements#1
Add team Claude Code setup, Python tooling, and shell improvements#1cloudprobe merged 4 commits intomainfrom
Conversation
Shell: - Add pyenv + shellcheck to install.sh and .zshrc - Add Python module to Starship prompt - Add h() alias search function to .aliases - Add .zshrc.local.template for machine-specific overrides Infra / config: - Add aws/config.sample with assume-role and SSO patterns - Add .editorconfig for consistent indentation across tools - Pin shellcheck CI action from @master to @2.0.0 Claude Code — global: - Add PreToolUse hook blocking writes to .env/*.key/*.pem files - Add terraform fmt and shellcheck PostToolUse hooks - Add pr-reviewer agent (/pr-reviewer <n> → CRITICAL/WARNING/INFO via gh) - Add standup command (/standup → git log + open PRs) Claude Code — project template (team-ready): - Overhaul CLAUDE.md template with Team conventions, CI/CD, Reviewers sections - Add shared hooks to settings.json (secret protection + auto-format) - Add settings.local.json.template for per-dev machine overrides (gitignored) - Add .mcp.json with GitHub MCP server for PR/issue access - Add rules/testing.md and rules/security.md as dedicated rule files - Add .gitignore ensuring settings.local.json is never committed Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
|
Warning Rate limit exceeded
⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (5)
📝 WalkthroughWalkthroughThe PR introduces comprehensive infrastructure and documentation for dotfiles management, including editor configuration standardization, Python environment tooling (pyenv), AWS credential templates, Claude AI agent workflows and commands, project-template scaffolding with security and testing guidelines, automated formatting/validation hooks, and shell environment enhancements. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (9)
claude/settings.json (1)
42-45: Note:shellcheckis a linter, not a formatter.Unlike
gofmtandterraform fmtwhich auto-fix files,shellcheckonly reports issues without modifying the file. The warnings will appear in hook output but won't auto-correct. This is fine for awareness, just wanted to clarify the behavioral difference.If you want auto-fixing, consider
shfmtfor formatting shell scripts:- "command": "file=$(jq -r '.tool_input.file_path // empty' 2>/dev/null); if [[ \"$file\" == *.sh ]] && command -v shellcheck >/dev/null 2>&1; then shellcheck \"$file\"; fi" + "command": "file=$(jq -r '.tool_input.file_path // empty' 2>/dev/null); if [[ \"$file\" == *.sh ]]; then command -v shfmt >/dev/null 2>&1 && shfmt -w \"$file\"; command -v shellcheck >/dev/null 2>&1 && shellcheck \"$file\"; fi"🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@claude/settings.json` around lines 42 - 45, The configured hook currently runs shellcheck (the "command" string that invokes shellcheck on files matching *.sh) but shellcheck is a linter only and won't auto-fix files; update the hook to either run an auto-formatter like shfmt (e.g., run shfmt -w on matched .sh files) or run both tools (shellcheck for linting and shfmt -w for formatting) so scripts get auto-fixed; modify the "command" value accordingly in the settings.json entry that contains the shellcheck invocation.claude/project-template/.mcp.json (1)
10-12: Documentation gap:GITHUB_TOKENrequirement not explicitly documented.The MCP config depends on
${GITHUB_TOKEN}being set, butsettings.local.json.template(context snippet 2) lacks this variable. Users may encounter silent auth failures.Consider adding
GITHUB_TOKENto the template:"env": { + "GITHUB_TOKEN": "", "AWS_PROFILE": "my-dev-profile", "KUBECONFIG": "/Users/me/.kube/config" }Or add an inline comment in the README's team setup section clarifying that
GITHUB_TOKENmust be exported (e.g., via~/.zshrc.local).🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@claude/project-template/.mcp.json` around lines 10 - 12, The MCP config's env mapping uses "GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_TOKEN}" but the example local config (settings.local.json.template) and README team setup don't document/export GITHUB_TOKEN; update settings.local.json.template to include a "GITHUB_TOKEN" entry with a placeholder value and/or add a short note in the README team setup instructing developers to export GITHUB_TOKEN (e.g., via ~/.zshrc.local) so the "GITHUB_PERSONAL_ACCESS_TOKEN" env interpolation works and avoids silent auth failures..github/workflows/shellcheck.yml (1)
15-15: Good improvement pinning to a version tag instead ofmaster.Note that GitHub release tags (like
2.0.0) cannot be force-pushed and are immutable by GitHub's design, making them secure. However, if you prefer stricter supply-chain security, you could pin to the commit SHA (currently2.0.0points to a stable release from January 2023). This is optional and less common in GitHub Actions usage, where version tags are the standard practice.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/shellcheck.yml at line 15, The workflow currently pins the ShellCheck action using the tag "ludeeus/action-shellcheck@2.0.0"; to further harden supply-chain security optionally replace the tag with the specific commit SHA that the 2.0.0 tag points to (e.g., "ludeeus/action-shellcheck@<commit-sha>") by looking up the tag's commit on GitHub and updating the uses line, or keep the immutable release tag "2.0.0" if you prefer the standard tagging practice.claude/project-template/settings.json (1)
34-37: Shellcheck runs but failures don't block the operation.Unlike
gofmtandterraform fmtwhich are formatters,shellcheckis a linter that reports issues but doesn't modify files. Since this is aPostToolUsehook, shellcheck output will appear after the write completes, serving as informational feedback rather than a gate.If blocking on shellcheck errors is desired, consider moving this to
PreToolUsefor existing files or accepting this as advisory-only (which seems intentional given the pattern).🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@claude/project-template/settings.json` around lines 34 - 37, The PostToolUse hook currently runs ShellCheck as an informational linter (the command string under "type": "command" that invokes shellcheck on $file) but its failures don't block the operation; to make ShellCheck block writes move this command into a PreToolUse hook (or change the hook group from PostToolUse to PreToolUse) and modify the command to return non‑zero on any ShellCheck findings (e.g., run shellcheck "$file" and if it exits non‑zero then echo the output and exit 1) so the PreToolUse will fail and prevent the write when shellcheck reports problems.claude/commands/standup.md (1)
5-8: Consider the "Monday problem" with--since="yesterday".On Mondays,
--since="yesterday"only captures Sunday's commits, missing Friday's work. Consider documenting this limitation or using a smarter date calculation.Alternative approach for cross-weekend coverage:
# Last 3 days covers weekend gaps git log --oneline --since="3 days ago" --author="$(git config user.name)" 2>/dev/null \ || git log --oneline -10This is minor since users can adjust the command, and the fallback to
-10provides a reasonable safety net.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@claude/commands/standup.md` around lines 5 - 8, The `git log --oneline --since="yesterday" --author="$(git config user.name)"` snippet can miss work across weekends (the "Monday problem"); update the standup instructions in standup.md to either document this limitation explicitly or replace the `--since="yesterday"` usage with a wider window such as `--since="3 days ago"` (or recommend that alternative) and keep the fallback `|| git log --oneline -10` unchanged so users still have the safe default.claude/project-template/settings.local.json.template (1)
10-10: Hardcoded macOS-specific path in template.
/Users/me/.kube/configuses the macOS home directory structure. Consider using a more generic placeholder that hints at cross-platform usage.Suggested fix
- "KUBECONFIG": "/Users/me/.kube/config" + "KUBECONFIG": "$HOME/.kube/config"Or add a comment noting this is macOS-specific and Linux users should use
/home/<user>/.kube/config.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@claude/project-template/settings.local.json.template` at line 10, The template currently hardcodes a macOS-specific path for the KUBECONFIG value ("KUBECONFIG"), which should be made cross-platform; update the "KUBECONFIG" template value to a generic placeholder (for example: "${HOME}/.kube/config" or "<home>/.kube/config") or add an inline comment next to the "KUBECONFIG" key stating that the shown path is macOS-specific and Linux users should use /home/<user>/.kube/config, so the setting is not tied to a single OS and clearly documents the platform differences.claude/project-template/rules/security.md (1)
5-5: Clarify environment variable guidance for secrets.Line 5 recommends "environment variables or a secrets manager" for credentials, while line 21 states "No credentials in environment variables — use instance profiles or IRSA."
Both are valid in different contexts (local dev vs cloud workloads), but the apparent contradiction may confuse readers.
Suggested clarification for line 21
-- No credentials in environment variables — use instance profiles or IRSA +- In AWS/cloud workloads: no credentials in environment variables — use instance profiles or IRSAAlso applies to: 21-21
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@claude/project-template/rules/security.md` at line 5, Clarify the apparent contradiction between the two guidance statements by specifying contexts: update the phrase "Use environment variables or a secrets manager (AWS Secrets Manager, Vault)" to indicate it's intended for local development and CI environments, and revise "No credentials in environment variables — use instance profiles or IRSA" to state it's the recommended practice for cloud workloads running on managed instances or Kubernetes; reference the exact phrases "Use environment variables or a secrets manager (AWS Secrets Manager, Vault)" and "No credentials in environment variables — use instance profiles or IRSA" so the editor knows which lines to modify and add a short rationale sentence indicating which scenarios each approach is appropriate.claude/agents/pr-reviewer.md (2)
46-62: Consider adding a language specifier to the output format block.This template block was also flagged by the linter. Since it's a markdown-formatted output template, you could use
markdownortextas the language identifier.📝 Proposed fix
4. Output format: - ``` + ```markdown ## PR #<n>: <title>🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@claude/agents/pr-reviewer.md` around lines 46 - 62, Update the output template's fenced code block to include a language specifier (e.g., change the opening "```" to "```markdown" or "```text") so the linter no longer flags it; specifically modify the PR template block that starts with the triple backticks and the header "## PR #<n>: <title>" to include the chosen language identifier.
8-15: Add language specifiers to fenced code blocks.The static analysis tool flagged these code blocks for missing language specifiers. Since these are shell command examples, adding the language identifier improves syntax highlighting and linter compliance.
📝 Proposed fix
Called with a PR number: -``` +```bash /pr-reviewer 42Or the current branch:
-+bash
/pr-reviewer🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@claude/agents/pr-reviewer.md` around lines 8 - 15, Update the two fenced code blocks that show the CLI examples "/pr-reviewer 42" and "/pr-reviewer" to include a shell language specifier (e.g., ```bash) so the blocks become ```bash ... ```; locate the literal code fences containing "/pr-reviewer 42" and "/pr-reviewer" and add "bash" immediately after the opening backticks to satisfy the linter and enable proper syntax highlighting.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@claude/project-template/CLAUDE.md`:
- Line 4: The HTML comment in the template uses nested comment delimiters ("<!--
comments -->") which will close the outer comment prematurely; replace the
nested comment text with plain placeholder text or a different non-HTML marker
(e.g., use "REPLACE_ME" or wrap the inner note in square brackets) so the outer
comment stays valid — update the comment in CLAUDE.md to remove any inner "-->"
or "<!--" sequences and leave a clear human-readable placeholder for
contributors.
In `@claude/project-template/settings.local.json.template`:
- Line 4: The existing pattern string "Bash(kubectl * --context my-local-cluster
*)" is too strict and fails to match commands with no args after the context;
update the pattern in the settings template to allow an optional trailing
argument (for example change it to "Bash(kubectl * --context my-local-cluster*)"
or otherwise include a trailing wildcard after the context) so commands like
"kubectl get pods --context my-local-cluster" match, or document that users must
adjust the pattern to their kubectl usage.
---
Nitpick comments:
In @.github/workflows/shellcheck.yml:
- Line 15: The workflow currently pins the ShellCheck action using the tag
"ludeeus/action-shellcheck@2.0.0"; to further harden supply-chain security
optionally replace the tag with the specific commit SHA that the 2.0.0 tag
points to (e.g., "ludeeus/action-shellcheck@<commit-sha>") by looking up the
tag's commit on GitHub and updating the uses line, or keep the immutable release
tag "2.0.0" if you prefer the standard tagging practice.
In `@claude/agents/pr-reviewer.md`:
- Around line 46-62: Update the output template's fenced code block to include a
language specifier (e.g., change the opening "```" to "```markdown" or
"```text") so the linter no longer flags it; specifically modify the PR template
block that starts with the triple backticks and the header "## PR #<n>: <title>"
to include the chosen language identifier.
- Around line 8-15: Update the two fenced code blocks that show the CLI examples
"/pr-reviewer 42" and "/pr-reviewer" to include a shell language specifier
(e.g., ```bash) so the blocks become ```bash ... ```; locate the literal code
fences containing "/pr-reviewer 42" and "/pr-reviewer" and add "bash"
immediately after the opening backticks to satisfy the linter and enable proper
syntax highlighting.
In `@claude/commands/standup.md`:
- Around line 5-8: The `git log --oneline --since="yesterday" --author="$(git
config user.name)"` snippet can miss work across weekends (the "Monday
problem"); update the standup instructions in standup.md to either document this
limitation explicitly or replace the `--since="yesterday"` usage with a wider
window such as `--since="3 days ago"` (or recommend that alternative) and keep
the fallback `|| git log --oneline -10` unchanged so users still have the safe
default.
In `@claude/project-template/.mcp.json`:
- Around line 10-12: The MCP config's env mapping uses
"GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_TOKEN}" but the example local config
(settings.local.json.template) and README team setup don't document/export
GITHUB_TOKEN; update settings.local.json.template to include a "GITHUB_TOKEN"
entry with a placeholder value and/or add a short note in the README team setup
instructing developers to export GITHUB_TOKEN (e.g., via ~/.zshrc.local) so the
"GITHUB_PERSONAL_ACCESS_TOKEN" env interpolation works and avoids silent auth
failures.
In `@claude/project-template/rules/security.md`:
- Line 5: Clarify the apparent contradiction between the two guidance statements
by specifying contexts: update the phrase "Use environment variables or a
secrets manager (AWS Secrets Manager, Vault)" to indicate it's intended for
local development and CI environments, and revise "No credentials in environment
variables — use instance profiles or IRSA" to state it's the recommended
practice for cloud workloads running on managed instances or Kubernetes;
reference the exact phrases "Use environment variables or a secrets manager (AWS
Secrets Manager, Vault)" and "No credentials in environment variables — use
instance profiles or IRSA" so the editor knows which lines to modify and add a
short rationale sentence indicating which scenarios each approach is
appropriate.
In `@claude/project-template/settings.json`:
- Around line 34-37: The PostToolUse hook currently runs ShellCheck as an
informational linter (the command string under "type": "command" that invokes
shellcheck on $file) but its failures don't block the operation; to make
ShellCheck block writes move this command into a PreToolUse hook (or change the
hook group from PostToolUse to PreToolUse) and modify the command to return
non‑zero on any ShellCheck findings (e.g., run shellcheck "$file" and if it
exits non‑zero then echo the output and exit 1) so the PreToolUse will fail and
prevent the write when shellcheck reports problems.
In `@claude/project-template/settings.local.json.template`:
- Line 10: The template currently hardcodes a macOS-specific path for the
KUBECONFIG value ("KUBECONFIG"), which should be made cross-platform; update the
"KUBECONFIG" template value to a generic placeholder (for example:
"${HOME}/.kube/config" or "<home>/.kube/config") or add an inline comment next
to the "KUBECONFIG" key stating that the shown path is macOS-specific and Linux
users should use /home/<user>/.kube/config, so the setting is not tied to a
single OS and clearly documents the platform differences.
In `@claude/settings.json`:
- Around line 42-45: The configured hook currently runs shellcheck (the
"command" string that invokes shellcheck on files matching *.sh) but shellcheck
is a linter only and won't auto-fix files; update the hook to either run an
auto-formatter like shfmt (e.g., run shfmt -w on matched .sh files) or run both
tools (shellcheck for linting and shfmt -w for formatting) so scripts get
auto-fixed; modify the "command" value accordingly in the settings.json entry
that contains the shellcheck invocation.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 09e9bb8c-8925-46b2-9221-11e629be9e7e
📒 Files selected for processing (19)
.editorconfig.github/workflows/shellcheck.ymlREADME.mdaws/config.sampleclaude/agents/pr-reviewer.mdclaude/commands/standup.mdclaude/project-template/.gitignoreclaude/project-template/.mcp.jsonclaude/project-template/CLAUDE.mdclaude/project-template/rules/security.mdclaude/project-template/rules/testing.mdclaude/project-template/settings.jsonclaude/project-template/settings.local.json.templateclaude/settings.jsoninstall.shzsh/.aliaseszsh/.zshrczsh/.zshrc.local.templatezsh/starship.toml
- Add shfmt -w PostToolUse hook for .sh files (auto-formatter alongside shellcheck)
- shellcheck now outputs but doesn't block so Claude can see and fix issues
- Fix KUBECONFIG template value from hardcoded /Users/me to \${HOME} (cross-platform)
- Add shfmt to install.sh brew dependencies
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
The pattern "Bash(kubectl * --context my-local-cluster *)" required at least one argument after the context name, so bare commands like "kubectl get pods --context my-local-cluster" were not matched. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Summary
testing.mdandsecurity.mdrules,settings.local.json.templatefor per-dev overridespr-reviewer(CRITICAL/WARNING/INFO output viagh) andstandup(git log + open PRs)h(),.zshrc.local.template.editorconfig,aws/config.sample, pinned ShellCheck CI,PreToolUsesecret file protection hookWhat changed
Claude Code — global (
~/.claude/)settings.json:PreToolUsehook blocks writes to.env,*.key,*.pem(exit 2 — hard block). Addedterraform fmtandshellcheckPostToolUse hooks.agents/pr-reviewer.md: New agent —/pr-reviewer 42fetches PR viaghand outputs structured CRITICAL / WARNING / INFO review with file:line citationscommands/standup.md: New command —/standuppulls git log + open PRs and formats a three-bullet standupClaude Code — project template (committed to each repo)
CLAUDE.md: Now has Team conventions, CI/CD pipeline, and Reviewers sections — the context teammates actually needsettings.json: Full hook set matching global config (secret protection + gofmt + terraform fmt + shellcheck)settings.local.json.template: Copy →settings.local.jsonfor machine-specific AWS profiles, kubeconfig. Never committed (enforced by new.gitignore).mcp.json: GitHub MCP server — team gets shared PR/issue access without per-machine setuprules/testing.md: Table tests, boundary testing, notime.Sleep, what requires tests and what doesn'trules/security.md: IAM least-priv, K8s no-root, SQL parameterization, secret handlingShell / tooling
install.sh+.zshrc: pyenv installed and initialized; shellcheck installed alongside other toolszsh/starship.toml: Python module added to promptzsh/.aliases:h()function —h k8sfinds all matching aliaseszsh/.zshrc.local.template: Documented template for AWS, K8s, tokens, work pathsaws/config.sample: assume-role and SSO config patterns.editorconfig: Consistent indentation for Go, Shell, TF, YAML, JSON, MarkdownCI
.github/workflows/shellcheck.yml: Pinnedludeeus/action-shellcheckfrom@masterto@2.0.0Test plan
shellcheck install.sh— passes cleanshellcheck -s bash zsh/.zshrc— passes cleanbash -n install.sh— syntax OKpython3 -m json.tool🤖 Generated with Claude Code
Summary by CodeRabbit
New Features
Documentation
Chores