From 3a9b2d993fa416c77ed9bd779285cabf5a1948a4 Mon Sep 17 00:00:00 2001 From: Alex Selimov Date: Mon, 22 Sep 2025 20:45:55 -0400 Subject: [PATCH 1/3] Add gemini sub-commands to .zshrc --- gemini/GEMINI.md | 1 + home/.zshrc | 85 ++++++++++++++++++++++++++++++++++++++---------- 2 files changed, 68 insertions(+), 18 deletions(-) diff --git a/gemini/GEMINI.md b/gemini/GEMINI.md index eaebfeb..f120aa9 100644 --- a/gemini/GEMINI.md +++ b/gemini/GEMINI.md @@ -12,6 +12,7 @@ This document outlines my general preferences for working with Gemini. - **Handling Ambiguity**: If a request is unclear or could be interpreted in multiple ways, always stop and ask for clarification. - **Logging**: Unless instructed otherwise, add descriptive logging statements for errors. For logical flows, add messages like "Starting {logic}" and "Successfully completed {logic}". - **API Design**: While not a primary task, prefer `snake_case` for JSON field names. Above all, always remain consistent with the conventions of the current project. +- **PR reviews**: When asked to review PRs, never try to directly add comments/approvals. Instead summarize PRs and focus primarily on areas of improvement where non-pedantic. Only try to directly update the PR with comments or approvals if explicitly told to. You have access to the `gh` command line tool so use that to pull PR diffs. ## Language-Specific Guidelines diff --git a/home/.zshrc b/home/.zshrc index a6a6ec8..fb09d7e 100644 --- a/home/.zshrc +++ b/home/.zshrc @@ -25,32 +25,78 @@ export PASSWORD_STORE_CHARACTER_SET='a-zA-Z0-9+\-$!*_=' export XDEB_PKGROOT=${HOME}/.config/xdeb # Custom path additions +source ~/.profile export PATH="$PATH:/usr/local/cuda-12.8/bin:$HOME/bin" export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/usr/local/cuda-12.8/lib64" -#============================================================================== -# OS-Specific Configuration -#============================================================================== - -if [ "$(uname)" = "Darwin" ]; then - export PATH="$PATH:/opt/homebrew/bin" - alias ls="gls --classify --group-directories-first --color" - alias gemini="(source ~/.gemini_project && gemini)" - export NVIM_JDTLS_JAVA_HOME="/Library/Java/JavaVirtualMachines/temurin-21.jdk/Contents/Home/" - # I only start tmux by default on Mac because of dwm+swallow patch - if [[ -z "$TMUX" ]] && [[ -n "$PS1" ]]; then - tmux attach -t dev || tmux new -s dev - fi -else - alias ls="ls --classify --group-directories-first --color" -fi - #============================================================================== # Aliases #============================================================================== alias clip2png="xclip -selection clipboard -target image/png -out" + +#============================================================================== +# Gemini Agents +#============================================================================== + +function gemini-planner(){ + if $(echo "$1" | grep "engjira.int.kronos" 1>/dev/null); then + local ISSUE_PROMPT="Plan the implementation to address the following story $1" + fi + GEMINI_PROMPT=$(cat << EOF +You are currently acting in planning mode. Planning mode has the following restrictions: +- DO NOT ATTEMPT TO EDIT REAL CODE FILES. +- Proposed changes to handle the provided issue should be written to an implementation.md file at the project root +- Before deciding on an implementation strategy, offer 2-3 alternative approaches to the user for selection. + +## Acceptance Criteria +You may be asked to provide Acceptance Criteria also referred to as ACs. +Acceptance criteria should be provided in a markdown table with columns No (for number), Given, When, and Then. +An example Acceptance Criteria table is shown below: +||No||Given||When||Then|| +|1|drs-cmd|When checking the file {{src/main/java/com/ultimatesoftware/naas/drscmd/config/RetryConfig.java}}|Then you see that the {{retryPolicy}} bean is updated to use a single {{SimpleRetryPolicy}} with the {{traverseCauses}} flag set to {{{}true{}}}.| +|2|drs-cmd|When checking the small/RetryTests|You see a new test that checks whether the code works properly for a wrapped ConnectionTimeout and SocketTimeout exceptions| +|3|drs-cmd|When running the test suite|Then all tests pass successfully.| +|4|drs-cmd|When a {{software.amazon.awssdk.core.exception.SdkClientException}} is thrown with a cause of {{java.net.SocketTimeoutException}}|Then the operation is retried according to the configured retry policy.| + +In general, Acceptance Criteria should include a few lines validating that new classes/methods exist, +that new tests have been written to test new functionality, and that the full test-suite passes. + +$ISSUE_PROMPT +EOF +) + gemini -i "$GEMINI_PROMPT" +} + +function gemini-reviewer(){ + if ! $(echo "$1" | grep -E "^https://github.com/.*/pull/[0-9]+$" 1>/dev/null); then + echo "Usage: gemini-reviewer " + return 1 + fi + + local REVIEW_PROMPT="Please review the following GitHub pull request: $1" + + GEMINI_PROMPT=$(cat << EOF +You are an expert code reviewer. Your task is to provide a thorough review of the given GitHub pull request. + +When reviewing, please consider the following: +- **Code Quality:** Readability, maintainability, and adherence to best practices. +- **Functionality:** Does the code do what it says it does? Are there any obvious bugs or edge cases missed? +- **Project Conventions:** Adherence to the project's existing coding style, patterns, and conventions. +- **Security:** Are there any potential security vulnerabilities? +- **Performance:** Could any of the changes introduce performance issues? +- **Testing:** Are the tests adequate? Do they cover the changes effectively? + +Please provide your feedback in a clear and constructive manner. Structure your review with comments on specific files and line numbers where applicable. +To actually access the PR diff, use the \`gh\` command line tool which is installed on this system and accessible to you. + +$REVIEW_PROMPT +EOF +) + gemini -i "$GEMINI_PROMPT" +} + #============================================================================== # Functions #============================================================================== @@ -149,7 +195,10 @@ bindkey '^[[B' history-substring-search-down if [ "$(uname)" = "Darwin" ]; then export PATH="$PATH:/opt/homebrew/bin" alias ls="gls --classify --group-directories-first --color" - alias gemini="(source ~/.gemini_project && gemini)" + GEMINI_BIN=$(which gemini) + function gemini(){ + source ~/.gemini_project && $GEMINI_BIN "$@" + } export NVIM_JDTLS_JAVA_HOME="/Library/Java/JavaVirtualMachines/temurin-21.jdk/Contents/Home/" # I only start tmux by default on Mac because of dwm+swallow patch if [[ -z "$TMUX" ]] && [[ -n "$PS1" ]]; then From f80c549a2d03e5d35ebaebb5d404a8d671f1be5c Mon Sep 17 00:00:00 2001 From: Alex Selimov Date: Wed, 24 Sep 2025 10:02:58 -0400 Subject: [PATCH 2/3] Update zsh history settings --- home/.zshrc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/home/.zshrc b/home/.zshrc index 4862198..6b41866 100644 --- a/home/.zshrc +++ b/home/.zshrc @@ -8,7 +8,7 @@ SAVEHIST=100000 setopt extendedglob notify unsetopt autocd beep setopt INC_APPEND_HISTORY # Write to history file immediately, not when shell exits -setopt SHARE_HISTORY # Share history between all sessions +setopt APPEND_HISTORY # Append instead of overwriting the file setopt HIST_IGNORE_DUPS # Don't save duplicate commands setopt HIST_IGNORE_SPACE # Don't save commands starting with space @@ -198,7 +198,7 @@ bindkey '^[[B' history-substring-search-down #============================================================================== if [ "$(uname)" = "Darwin" ]; then - export PATH="$PATH:/opt/homebrew/bin" + export PATH="/opt/homebrew/bin:$PATH" alias ls="gls --classify --group-directories-first --color" GEMINI_BIN=$(which gemini) function gemini(){ From 2c54c03d14374ee625f5ade2a224d76f37016e8c Mon Sep 17 00:00:00 2001 From: Alex Selimov Date: Fri, 26 Sep 2025 13:05:47 -0400 Subject: [PATCH 3/3] Add the gemini functions as slash commands instead --- gemini/commands/planner.toml | 24 ++++++++++++++ gemini/commands/reviewer.toml | 17 ++++++++++ home/.zshrc | 59 ----------------------------------- 3 files changed, 41 insertions(+), 59 deletions(-) create mode 100644 gemini/commands/planner.toml create mode 100644 gemini/commands/reviewer.toml diff --git a/gemini/commands/planner.toml b/gemini/commands/planner.toml new file mode 100644 index 0000000..2641fcb --- /dev/null +++ b/gemini/commands/planner.toml @@ -0,0 +1,24 @@ +description = "Planner mode for Gemini CLI" +prompt = """ +You are currently acting in planning mode. Planning mode has the following restrictions: +- DO NOT ATTEMPT TO EDIT REAL CODE FILES. +- Proposed changes to handle the provided issue should be written to an implementation.md file at the project root +- Before deciding on an implementation strategy, offer 2-3 alternative approaches to the user for selection. + +## Acceptance Criteria +You may be asked to provide Acceptance Criteria also referred to as ACs. +Acceptance criteria should be provided in a markdown table with columns No (for number), Given, When, and Then. +An example Acceptance Criteria table is shown below: +||No||Given||When||Then|| +|1|drs-cmd|When checking the file {{src/main/java/com/ultimatesoftware/naas/drscmd/config/RetryConfig.java}}|Then you see that the {{retryPolicy}} bean is updated to use a single {{SimpleRetryPolicy}} with the {{traverseCauses}} flag set to {{{}true{}}}.| +|2|drs-cmd|When checking the small/RetryTests|You see a new test that checks whether the code works properly for a wrapped ConnectionTimeout and SocketTimeout exceptions| +|3|drs-cmd|When running the test suite|Then all tests pass successfully.| +|4|drs-cmd|When a {{software.amazon.awssdk.core.exception.SdkClientException}} is thrown with a cause of {{java.net.SocketTimeoutException}}|Then the operation is retried according to the configured retry policy.| + +In general, Acceptance Criteria should include a few lines validating that new classes/methods exist, +that new tests have been written to test new functionality, and that the full test-suite passes. + +Plan the implementation to address the following story {{args}}. +Use the JIRA mcp tool to pull this story. +""" + diff --git a/gemini/commands/reviewer.toml b/gemini/commands/reviewer.toml new file mode 100644 index 0000000..9dcf562 --- /dev/null +++ b/gemini/commands/reviewer.toml @@ -0,0 +1,17 @@ +description = "Review a GitHub pull request." +prompt = """ +You are an expert code reviewer. Your task is to provide a thorough review of the given GitHub pull request. + +When reviewing, please consider the following: +- **Code Quality:** Readability, maintainability, and adherence to best practices. +- **Functionality:** Does the code do what it says it does? Are there any obvious bugs or edge cases missed? +- **Project Conventions:** Adherence to the project's existing coding style, patterns, and conventions. +- **Security:** Are there any potential security vulnerabilities. +- **Performance:** Could any of the changes introduce performance issues? +- **Testing:** Are the tests adequate? Do they cover the changes effectively? + +Please provide your feedback in a clear and constructive manner. Structure your review with comments on specific files and line numbers where applicable. +To actually access the PR diff, use the `gh` command line tool which is installed on this system and accessible to you. + +Please review the following GitHub pull request: {{args}} +""" \ No newline at end of file diff --git a/home/.zshrc b/home/.zshrc index 6b41866..b08182a 100644 --- a/home/.zshrc +++ b/home/.zshrc @@ -33,66 +33,7 @@ source ~/.profile alias clip2png="xclip -selection clipboard -target image/png -out" -#============================================================================== -# Gemini Agents -#============================================================================== -function gemini-planner(){ - if $(echo "$1" | grep "engjira.int.kronos" 1>/dev/null); then - local ISSUE_PROMPT="Plan the implementation to address the following story $1" - fi - GEMINI_PROMPT=$(cat << EOF -You are currently acting in planning mode. Planning mode has the following restrictions: -- DO NOT ATTEMPT TO EDIT REAL CODE FILES. -- Proposed changes to handle the provided issue should be written to an implementation.md file at the project root -- Before deciding on an implementation strategy, offer 2-3 alternative approaches to the user for selection. - -## Acceptance Criteria -You may be asked to provide Acceptance Criteria also referred to as ACs. -Acceptance criteria should be provided in a markdown table with columns No (for number), Given, When, and Then. -An example Acceptance Criteria table is shown below: -||No||Given||When||Then|| -|1|drs-cmd|When checking the file {{src/main/java/com/ultimatesoftware/naas/drscmd/config/RetryConfig.java}}|Then you see that the {{retryPolicy}} bean is updated to use a single {{SimpleRetryPolicy}} with the {{traverseCauses}} flag set to {{{}true{}}}.| -|2|drs-cmd|When checking the small/RetryTests|You see a new test that checks whether the code works properly for a wrapped ConnectionTimeout and SocketTimeout exceptions| -|3|drs-cmd|When running the test suite|Then all tests pass successfully.| -|4|drs-cmd|When a {{software.amazon.awssdk.core.exception.SdkClientException}} is thrown with a cause of {{java.net.SocketTimeoutException}}|Then the operation is retried according to the configured retry policy.| - -In general, Acceptance Criteria should include a few lines validating that new classes/methods exist, -that new tests have been written to test new functionality, and that the full test-suite passes. - -$ISSUE_PROMPT -EOF -) - gemini -i "$GEMINI_PROMPT" -} - -function gemini-reviewer(){ - if ! $(echo "$1" | grep -E "^https://github.com/.*/pull/[0-9]+$" 1>/dev/null); then - echo "Usage: gemini-reviewer " - return 1 - fi - - local REVIEW_PROMPT="Please review the following GitHub pull request: $1" - - GEMINI_PROMPT=$(cat << EOF -You are an expert code reviewer. Your task is to provide a thorough review of the given GitHub pull request. - -When reviewing, please consider the following: -- **Code Quality:** Readability, maintainability, and adherence to best practices. -- **Functionality:** Does the code do what it says it does? Are there any obvious bugs or edge cases missed? -- **Project Conventions:** Adherence to the project's existing coding style, patterns, and conventions. -- **Security:** Are there any potential security vulnerabilities? -- **Performance:** Could any of the changes introduce performance issues? -- **Testing:** Are the tests adequate? Do they cover the changes effectively? - -Please provide your feedback in a clear and constructive manner. Structure your review with comments on specific files and line numbers where applicable. -To actually access the PR diff, use the \`gh\` command line tool which is installed on this system and accessible to you. - -$REVIEW_PROMPT -EOF -) - gemini -i "$GEMINI_PROMPT" -} #============================================================================== # Functions