Compare commits
2 commits
0b3239e632
...
2c54c03d14
Author | SHA1 | Date | |
---|---|---|---|
![]() |
2c54c03d14 | ||
![]() |
f80c549a2d |
3 changed files with 43 additions and 61 deletions
24
gemini/commands/planner.toml
Normal file
24
gemini/commands/planner.toml
Normal file
|
@ -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.
|
||||
"""
|
||||
|
17
gemini/commands/reviewer.toml
Normal file
17
gemini/commands/reviewer.toml
Normal file
|
@ -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}}
|
||||
"""
|
63
home/.zshrc
63
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
|
||||
|
||||
|
@ -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 <github_pr_url>"
|
||||
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
|
||||
|
@ -198,7 +139,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(){
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue