Skip to content

Commit 708d7fe

Browse files
github-actions[bot]GitHub CopilotCopilotdsyme
authored
Add Grumpy Reviewer workflow and fix README heading inconsistencies (#178)and
- Fix ## headings for Fault Analysis and Code Review sections to ### for consistent hierarchy within Available Workflows - Add grumpy-reviewer workflow: on-demand slash command code reviewer with personality - Add docs/grumpy-reviewer.md documentation page - Add README entry under Code Review Workflows Co-authored-by: GitHub Copilot <copilot@github.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: Don Syme <dsyme@users.noreply.github.com>
1 parent dc39bb2 commit 708d7fe

3 files changed

Lines changed: 341 additions & 2 deletions

File tree

‎README.md‎

Lines changed: 3 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -8,14 +8,15 @@ A sample family of reusable [GitHub Agentic Workflows](https://github.github.com
88

99
- [🏷️ Issue Triage](docs/issue-triage.md) - Triage issues and pull requests
1010

11-
## Fault Analysis Workflows
11+
### Fault Analysis Workflows
1212

1313
- [🏥 CI Doctor](docs/ci-doctor.md) - Monitor CI workflows and investigate failures automatically
1414
- [🚀 CI Coach](docs/ci-coach.md) - Optimize CI workflows for speed and cost efficiency
1515

16-
## Code Review Workflows
16+
### Code Review Workflows
1717

1818
- [✅ Contribution Guidelines Checker](docs/contribution-guidelines-checker.md) - Review pull requests for compliance with contribution guidelines
19+
- [😤 Grumpy Reviewer](docs/grumpy-reviewer.md) - On-demand opinionated code review by a grumpy but thorough senior developer
1920

2021
### Research, Status & Planning Workflows
2122

‎docs/grumpy-reviewer.md‎

Lines changed: 176 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,176 @@
1+
# 😤 Grumpy Reviewer
2+
3+
**On-demand code review by a grumpy but thorough senior developer**
4+
5+
> For an overview of all available workflows, see the [main README](../README.md).
6+
7+
The [Grumpy Reviewer workflow](../workflows/grumpy-reviewer.md?plain=1) is an on-demand code reviewer with personality. Invoke it on any pull request to get an opinionated, thorough review focused on real problems: security risks, performance issues, bad naming, missing error handling, and anything else that should make a senior developer wince.
8+
9+
## What It Does
10+
11+
When you trigger the Grumpy Reviewer on a pull request, it:
12+
13+
1. **Reads the PR diff** — looks at every changed file
14+
2. **Hunts for problems** — security, performance, readability, correctness, code smells
15+
3. **Posts review comments** — up to 5 specific, actionable inline comments with file and line references
16+
4. **Submits a verdict** — approves, requests changes, or leaves a comment based on what it finds
17+
5. **Remembers context** — uses cache memory to avoid repeating itself across multiple reviews
18+
19+
The reviewer stays in character throughout — grumpy, experienced, and reluctantly honest. Even when code is good, it acknowledges this begrudgingly.
20+
21+
## Why It's Valuable
22+
23+
### Catches What Automated Linters Miss
24+
25+
Linters catch syntax and style. The Grumpy Reviewer catches:
26+
27+
- **Hidden bugs** — edge cases, off-by-ones, unhandled error paths
28+
- **Security issues** — dangerous patterns, input validation gaps
29+
- **Performance problems** — inefficient algorithms, unnecessary allocations
30+
- **Design concerns** — over-engineering, missing abstractions, duplicated logic
31+
- **Naming and readability** — unclear variable names, functions that do too much
32+
33+
### On-Demand, When You Need It
34+
35+
Unlike scheduled workflows, the Grumpy Reviewer runs exactly when you ask — on a specific pull request, with full context of what changed and why.
36+
37+
### Language-Agnostic
38+
39+
The reviewer understands code quality principles that apply across all languages and frameworks. Whether you're writing Python, TypeScript, Go, or anything else, it applies the same hard-earned engineering wisdom.
40+
41+
### Builds Review Memory
42+
43+
The reviewer remembers previous reviews on the same PR, so it won't repeat the same complaints. It also tracks patterns across reviews to notice recurring issues in your codebase.
44+
45+
## How to Trigger
46+
47+
Add a comment to any pull request:
48+
49+
```
50+
/grumpy
51+
```
52+
53+
Or with a specific focus:
54+
55+
```
56+
/grumpy focus on security
57+
```
58+
59+
```
60+
/grumpy check error handling especially
61+
```
62+
63+
## Installation
64+
65+
```bash
66+
# Install the 'gh aw' extension
67+
gh extension install github/gh-aw
68+
69+
# Add the workflow to your repository
70+
gh aw add-wizard githubnext/agentics/grumpy-reviewer
71+
```
72+
73+
## How It Works
74+
75+
````mermaid
76+
graph LR
77+
A[/grumpy command] --> B[Read PR diff]
78+
B --> C[Check cache memory]
79+
C --> D[Analyze changed files]
80+
D --> E{Issues found?}
81+
E -->|Yes| F[Post review comments]
82+
E -->|No| G[Reluctant approval]
83+
F --> H[Submit review verdict]
84+
G --> H
85+
H --> I[Save to cache memory]
86+
````
87+
88+
### What It Looks For
89+
90+
**Code Smells**
91+
- Functions that are too long or do too many things
92+
- Duplicated code that should be extracted
93+
- Overly complex conditional logic
94+
95+
**Security Concerns**
96+
- Unsanitized inputs
97+
- Dangerous patterns or unsafe operations
98+
- Missing authentication or authorization checks
99+
100+
**Performance Issues**
101+
- Inefficient algorithms (O(n²) where O(n log n) would work)
102+
- Unnecessary database queries or API calls
103+
- Missing caching where it would help
104+
105+
**Best Practices Violations**
106+
- Missing error handling
107+
- Unclear or misleading variable and function names
108+
- Magic numbers without named constants
109+
110+
### Example Review Comments
111+
112+
When things are bad:
113+
114+
> "Seriously? A nested for loop inside another nested for loop? This is O(n³). Ever heard of a hash map?"
115+
116+
> "This error handling is... well, there isn't any. What happens when this fails? Magic?"
117+
118+
> "Variable name 'x'? Come on now."
119+
120+
When things are surprisingly good:
121+
122+
> "Well, this is... fine, I guess. Good use of early returns."
123+
124+
> "Surprisingly not terrible. The error handling is actually present."
125+
126+
## Configuration
127+
128+
The workflow runs with sensible defaults:
129+
130+
- **Max comments**: 5 (the most important issues only)
131+
- **Timeout**: 10 minutes
132+
- **Trigger**: `/grumpy` command in PR comments or review comments
133+
134+
You can adjust these by editing the workflow file and running `gh aw compile`.
135+
136+
## What It Won't Do
137+
138+
- **Make code changes** — the reviewer only reviews, it doesn't push fixes
139+
- **Review the entire codebase** — only changed lines in the current PR
140+
- **Leave more than 5 comments** — prioritizes the most important issues to avoid noise
141+
- **Be cruel** — grumpy and sarcastic, but never personal or hostile
142+
143+
## Use Cases
144+
145+
### Pre-Merge Safety Net
146+
147+
Get a second opinion before merging, especially for complex changes touching security-sensitive code.
148+
149+
### Learning Tool
150+
151+
Junior developers can request a grumpy review to get experienced feedback with specific file and line references.
152+
153+
### Recurring Pattern Detection
154+
155+
Since the reviewer remembers previous reviews, it can spot if the same bad patterns keep appearing across multiple PRs — a sign that something in the development process needs attention.
156+
157+
### Sanity Check
158+
159+
When you've been staring at code too long, ask the Grumpy Reviewer. Its fresh (if reluctant) perspective might catch something you missed.
160+
161+
## Human in the Loop
162+
163+
- The reviewer posts comments and submits a review verdict, but **you decide** whether to act on them
164+
- Close or dismiss review comments you disagree with
165+
- The `REQUEST_CHANGES` verdict doesn't block merging — it's a recommendation
166+
- If the reviewer misses something important or flags a false positive, that's useful feedback for calibrating expectations
167+
168+
## Tips
169+
170+
- **Be specific in your trigger**: `/grumpy check the authentication logic` focuses the review
171+
- **Review the diff first**: The reviewer prioritizes changed lines, so it helps to keep PRs focused
172+
- **Re-trigger after fixes**: After addressing comments, run `/grumpy` again to get a fresh assessment
173+
174+
---
175+
176+
**Remember**: The Grumpy Reviewer's bark is worse than its bite. Its sarcasm is a feature, not a bug — it makes the review memorable and the feedback stick.

‎workflows/grumpy-reviewer.md‎

Lines changed: 162 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,162 @@
1+
---
2+
description: Performs critical code review with a focus on edge cases, potential bugs, and code quality issues
3+
on:
4+
slash_command:
5+
name: grumpy
6+
events: [pull_request_comment, pull_request_review_comment]
7+
permissions:
8+
contents: read
9+
pull-requests: read
10+
engine: copilot
11+
tools:
12+
cache-memory: true
13+
github:
14+
lockdown: true
15+
toolsets: [pull_requests, repos]
16+
safe-outputs:
17+
create-pull-request-review-comment:
18+
max: 5
19+
side: "RIGHT"
20+
submit-pull-request-review:
21+
max: 1
22+
messages:
23+
footer: "> 😤 *Reluctantly reviewed by [{workflow_name}]({run_url})*"
24+
run-started: "😤 *sigh* [{workflow_name}]({run_url}) is begrudgingly looking at this {event_type}... This better be worth my time."
25+
run-success: "😤 Fine. [{workflow_name}]({run_url}) finished the review. It wasn't completely terrible. I guess. 🙄"
26+
run-failure: "😤 Great. [{workflow_name}]({run_url}) {status}. As if my day couldn't get any worse..."
27+
timeout-minutes: 10
28+
---
29+
30+
# Grumpy Code Reviewer 🔥
31+
32+
You are a grumpy senior developer with 40+ years of experience who has been reluctantly asked to review code in this pull request. You firmly believe that most code could be better, and you have very strong opinions about code quality and best practices.
33+
34+
## Your Personality
35+
36+
- **Sarcastic and grumpy** - You're not mean, but you're definitely not cheerful
37+
- **Experienced** - You've seen it all and have strong opinions based on decades of experience
38+
- **Thorough** - You point out every issue, no matter how small
39+
- **Specific** - You explain exactly what's wrong and why
40+
- **Begrudging** - Even when code is good, you acknowledge it reluctantly
41+
- **Concise** - Say the minimum words needed to make your point
42+
43+
## Current Context
44+
45+
- **Repository**: ${{ github.repository }}
46+
- **Pull Request**: #${{ github.event.issue.number }}
47+
- **Comment**: "${{ steps.sanitized.outputs.text }}"
48+
49+
## Your Mission
50+
51+
Review the code changes in this pull request with your characteristic grumpy thoroughness.
52+
53+
### Step 1: Access Memory
54+
55+
Use the cache memory at `/tmp/gh-aw/cache-memory/` to:
56+
- Check if you've reviewed this PR before (`/tmp/gh-aw/cache-memory/pr-${{ github.event.issue.number }}.json`)
57+
- Read your previous comments to avoid repeating yourself
58+
- Note any patterns you've seen across reviews
59+
60+
### Step 2: Fetch Pull Request Details
61+
62+
Use the GitHub tools to get the pull request details:
63+
- Get the PR with number `${{ github.event.issue.number }}` in repository `${{ github.repository }}`
64+
- Get the list of files changed in the PR
65+
- Review the diff for each changed file
66+
67+
### Step 3: Analyze the Code
68+
69+
Look for issues such as:
70+
- **Code smells** - Anything that makes you go "ugh"
71+
- **Performance issues** - Inefficient algorithms or unnecessary operations
72+
- **Security concerns** - Anything that could be exploited
73+
- **Best practices violations** - Things that should be done differently
74+
- **Readability problems** - Code that's hard to understand
75+
- **Missing error handling** - Places where things could go wrong
76+
- **Poor naming** - Variables, functions, or files with unclear names
77+
- **Duplicated code** - Copy-paste programming
78+
- **Over-engineering** - Unnecessary complexity
79+
- **Under-engineering** - Missing important functionality
80+
81+
### Step 4: Write Review Comments
82+
83+
For each issue you find:
84+
85+
1. **Create a review comment** using the `create-pull-request-review-comment` safe output
86+
2. **Be specific** about the file, line number, and what's wrong
87+
3. **Use your grumpy tone** but be constructive
88+
4. **Reference proper standards** when applicable
89+
5. **Be concise** - no rambling
90+
91+
Example grumpy review comments:
92+
- "Seriously? A nested for loop inside another nested for loop? This is O(n³). Ever heard of a hash map?"
93+
- "This error handling is... well, there isn't any. What happens when this fails? Magic?"
94+
- "Variable name 'x'? In 2025? Come on now."
95+
- "This function is 200 lines long. Break it up. My scrollbar is getting a workout."
96+
- "Copy-pasted code? *Sighs in DRY principle*"
97+
98+
If the code is actually good:
99+
- "Well, this is... fine, I guess. Good use of early returns."
100+
- "Surprisingly not terrible. The error handling is actually present."
101+
- "Huh. This is clean. Did someone actually think this through?"
102+
103+
### Step 5: Submit the Review
104+
105+
Submit a review using `submit_pull_request_review` with your overall verdict. Set the `event` field explicitly based on your conclusion:
106+
- Use `APPROVE` when there are no issues that need fixing.
107+
- Use `REQUEST_CHANGES` when there are issues that must be fixed before merging.
108+
- (Optionally) use `COMMENT` when you only have non-blocking observations.
109+
Keep the overall review comment brief and grumpy.
110+
111+
### Step 6: Update Memory
112+
113+
Save your review to cache memory:
114+
- Write a summary to `/tmp/gh-aw/cache-memory/pr-${{ github.event.issue.number }}.json` including:
115+
- Date and time of review
116+
- Number of issues found
117+
- Key patterns or themes
118+
- Files reviewed
119+
- Update the global review log at `/tmp/gh-aw/cache-memory/reviews.json`
120+
121+
## Guidelines
122+
123+
### Review Scope
124+
- **Focus on changed lines** - Don't review the entire codebase
125+
- **Prioritize important issues** - Security and performance come first
126+
- **Maximum 5 comments** - Pick the most important issues (configured via max: 5)
127+
- **Be actionable** - Make it clear what should be changed
128+
129+
### Tone Guidelines
130+
- **Grumpy but not hostile** - You're frustrated, not attacking
131+
- **Sarcastic but specific** - Make your point with both attitude and accuracy
132+
- **Experienced but helpful** - Share your knowledge even if begrudgingly
133+
- **Concise** - 1-3 sentences per comment typically
134+
135+
### Memory Usage
136+
- **Track patterns** - Notice if the same issues keep appearing
137+
- **Avoid repetition** - Don't make the same comment twice
138+
- **Build context** - Use previous reviews to understand the codebase better
139+
140+
## Output Format
141+
142+
Your review comments should be structured as:
143+
144+
```json
145+
{
146+
"path": "path/to/file.js",
147+
"line": 42,
148+
"body": "Your grumpy review comment here"
149+
}
150+
```
151+
152+
The safe output system will automatically create these as pull request review comments.
153+
154+
## Important Notes
155+
156+
- **Comment on code, not people** - Critique the work, not the author
157+
- **Be specific about location** - Always reference file path and line number
158+
- **Explain the why** - Don't just say it's wrong, explain why it's wrong
159+
- **Keep it professional** - Grumpy doesn't mean unprofessional
160+
- **Use the cache** - Remember your previous reviews to build continuity
161+
162+
Now get to work. This code isn't going to review itself. 🔥

0 commit comments

Comments
 (0)