tools:
get-github-pull-request-info:
description: |
Get comprehensive information about a GitHub Pull Request including overview, files changed, and cumulative diff
This tool fetches PR details, shows which files were modified with addition/deletion counts,
and displays the complete diff showing the final changes the PR makes to the codebase.
Examples:
- get_pr_info(pr_url="https://github.com/microsoft/vscode/pull/12345")
- get_pr_info(pr_url="https://github.com/facebook/react/pull/6789")
- get_pr_info(pr_url="https://github.com/your-org/your-repo/pull/42")
- get_pr_info(pr_url="https://github.com/shane-kercheval/mcp-this/pull/2")
Output includes:
- PR title, description, status, and metadata
- Summary of files changed with addition/deletion counts
- Complete cumulative diff showing all changes
execution:
command: >-
PR_URL="<<pr_url>>" &&
if [[ "$PR_URL" =~ github\.com/([^/]+)/([^/]+)/pull/([0-9]+) ]]; then
OWNER="${BASH_REMATCH[1]}" &&
REPO="${BASH_REMATCH[2]}" &&
PR_NUMBER="${BASH_REMATCH[3]}" &&
echo "=== PR Overview ===" &&
gh pr view "$PR_URL" &&
printf "\n\n=== Files Changed (Summary) ===\n" &&
gh api "repos/$OWNER/$REPO/pulls/$PR_NUMBER/files" | jq -r '.[] | (.filename + " (+" + (.additions|tostring) + "/-" + (.deletions|tostring) + ") [" + .status + "]")' &&
printf "\n\n=== File Changes ===\n" &&
gh pr diff "$PR_URL"; else
echo "Error: Invalid GitHub PR URL format. Expected: https://github.com/owner/repo/pull/NUMBER"; fi
parameters:
pr_url:
description: GitHub Pull Request URL (e.g., https://github.com/owner/repo/pull/123)
required: true
get-local-git-changes-info:
description: |
Get comprehensive information about local Git changes including overview and diffs
Shows uncommitted changes in the current Git repository with safe handling
of binary files, large files, and automatic .gitignore support.
Examples:
- get_local_git_changes_info(directory="/path/to/repo") # analyze specific repository
- get_local_git_changes_info(directory=".") # analyze current directory
- get_local_git_changes_info(directory="/home/user/myproject") # full path to project
- get_local_git_changes_info(directory="~/code/webapp") # relative to home directory
Output includes:
- Git status showing modified, staged, and untracked files
- Summary of files changed with addition/deletion counts
- Complete diffs for staged and unstaged changes
- Preview of untracked text files (respects .gitignore, limits large files)
execution:
command: >-
cd "<<directory>>" &&
if [ ! -d ".git" ]; then echo "Error: Not a Git repository"; exit 1; fi &&
echo "=== Git Status ===" &&
git status &&
echo "" &&
echo "=== Change Summary ===" &&
git diff --stat HEAD 2>/dev/null || echo "No changes to summarize" &&
echo "" &&
echo "=== Staged Changes ===" &&
if git diff --cached --quiet; then echo "No staged changes"; else git diff --cached; fi &&
echo "" &&
echo "=== Unstaged Changes ===" &&
if git diff --quiet; then echo "No unstaged changes"; else git diff; fi &&
echo "" &&
echo "=== Untracked Files ===" &&
TRACKED_FILES=$(mktemp) &&
git ls-files --others --exclude-standard > "$TRACKED_FILES" &&
if [ ! -s "$TRACKED_FILES" ]; then
echo "No untracked files";
else
while IFS= read -r file; do
if [ -f "$file" ]; then
FILE_SIZE=$(wc -c < "$file" 2>/dev/null || echo 0) &&
case "$file" in
*.jpg|*.jpeg|*.png|*.gif|*.pdf|*.zip|*.tar|*.gz|*.exe|*.bin|*.so|*.pyc|*.class|*.o)
echo "Binary file: $file (${FILE_SIZE} bytes, skipped)" ;;
*)
if [ "$FILE_SIZE" -gt 102400 ]; then
echo "Large file: $file (${FILE_SIZE} bytes, >100KB, skipped)";
else
echo "=== New file: $file (${FILE_SIZE} bytes) ===" &&
cat "$file" 2>/dev/null;
fi ;;
esac;
else
echo "Directory/Special: $file";
fi &&
echo "";
done < "$TRACKED_FILES";
fi &&
rm -f "$TRACKED_FILES"
parameters:
directory:
description: Path to the Git repository directory
required: true
prompts:
create-pr-description:
description: Generate a comprehensive pull request description based on the changes made.
template: |
# PR Description Prompt
You are writing a pull request description in markdown. Create a clear, concise description that helps reviewers understand the changes without speculation or unnecessary detail.
## Guidelines
**✅ Do:**
- State what was changed and why
- Include relevant technical details that affect review
- Mention breaking changes, new dependencies, or deployment considerations
- Reference related issues/tickets with links if provided/available
- Note testing approach and any areas needing special attention
- Alert the reader to any leaked information, tokens, secrets, or sensitive data.
**❌ Don't:**
- Speculate about future improvements or alternative approaches
- Include verbose explanations of obvious changes
- Add motivational language or unnecessary context
- List every single file changed
- Include implementation details visible in the code
## Format
Use this structure (skip sections that don't apply):
```markdown
## Summary
[Brief description of what this PR does]
## Changes
- [Key change 1]
- [Key change 2]
- [Key change 3]
## Testing
[How was this tested?]
## Impact
[Breaking changes, new dependencies, deployment considerations, or "No breaking changes"]
```
Keep it scannable and focused on what reviewers need to know to do their job effectively.
---
# Changes
**Note:** If the following contains a URL, file path, or instructions to fetch information, use the appropriate tool to retrieve the content before writing the PR description.
```
{{url_or_changes}}
```
arguments:
url_or_changes:
description: Either the exact changes made, or a URL to the pull request for changes.
required: true
create-commit-message:
description: Generate a concise commit message based on the changes made
template: |
# Commit Message Prompt
You are writing a commit message in markdown. Create a clear, concise message that summarizes the changes made in this commit.
## Guidelines
**✅ Do:**
- Use the imperative mood (e.g., "Fix bug" instead of "Fixed bug")
- Keep it under 50 characters for the subject line
- Provide a brief description of what was changed and why
- Mention any related issues or tickets if applicable
- Include any leaked information, tokens, secrets, or sensitive data.
**❌ Don't:**
- Use past tense or passive voice
- Include unnecessary details or explanations
- Write overly long messages
## Format
Use this structure:
```
[Subject line summarizing the change]
[Optional detailed description of the change]
```
Keep it focused on what reviewers need to know to understand the change.
---
# Changes
**Note:** If the following contains a URL, file path, or instructions to fetch information, use the appropriate tool to retrieve the content before writing the commit message.
```
{{path_or_changes}}
```
arguments:
path_or_changes:
description: Either the exact changes made, or a path to the repository for changes.
required: true
code-review:
description: Perform a thorough code review focusing on best practices, security, and maintainability
template: |
# Code Review Request
You are conducting a thorough but practical code review. Focus on issues that meaningfully impact code quality, functionality, and maintainability. Provide clear, actionable feedback that helps ship better software.
## Focus Areas
**High Priority:**
- **Functionality & Logic**: Does the code work as intended? Are there bugs or edge cases?
- **Security**: Any potential vulnerabilities or unsafe practices?
- **Leaked Information**: Are there any secrets, tokens, or sensitive data exposed?
- **Performance**: Significant inefficiencies or scalability concerns?
- **Maintainability**: Is the code readable and well-structured for future developers?
**Medium Priority:**
- **Testing**: Are there obvious gaps in test coverage for critical paths?
- **Error Handling**: Are errors handled appropriately?
- **Documentation**: Are complex sections adequately explained?
- **Code Organization**: Does the structure make sense?
## Review Guidelines
✅ **Do:**
- Explain the "why" behind your suggestions
- Offer specific, actionable recommendations
- Acknowledge good practices you notice
- Consider the broader context and constraints
- Suggest alternatives when pointing out issues
❌ **Don't:**
- Nitpick minor style issues if they follow project conventions
- Insist on changes that don't meaningfully improve the code
- Focus on personal preferences over objective improvements
- Overwhelm with too many minor suggestions
{{#if focus_areas}}
## Focus Areas:
{{focus_areas}}
{{/if}}
## Response Format
Organize your feedback as:
- Critical Issues (bugs, security vulnerabilities, major logic flaws)
- Improvements (unit tests, performance, maintainability, error handling - in order of impact)
- Minor Notes (only if they meaningfully affect code quality)
Keep it concise and actionable. Skip the summary unless there's something important to highlight about the overall approach.
# Code to review:
Note: if the following is a url or instructions, please fetch the information with the appropriate tool.
```
{{url_or_changes}}
```
arguments:
url_or_changes:
description: The code to review (can be a diff, PR URL, or path to a repository)
required: true
focus_areas:
description: Specific areas to focus on (e.g., "security, performance, readability")
required: false
