mopemope/Smart PR Reviewer

AI-powered code reviewer and release notes generator for pull requests

Trust Signals

Scorecard Score: not yet scored
Maintenance Recency: Stale
License: None

Inputs

name	description	required	default
debug	Enable debug mode	no	false
path_filters	The path filters, e.g., "src/.py", "!dist/", each line will be considered as one pattern. See also - https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore - https://github.com/isaacs/minimatch	no	!dist/ !/.app !/.bin !*/.bz2 !*/.class !*/.db !*/.csv !*/.tsv !*/.dat !*/.dll !*/.dylib !*/.egg !*/.glif !*/.gz !*/.xz !*/.zip !*/.7z !*/.rar !*/.zst !*/.ico !*/.jar !*/.tar !*/.war !*/.lo !*/.log !*/.mp3 !*/.wav !*/.wma !*/.mp4 !*/.avi !*/.mkv !*/.wmv !*/.m4a !*/.m4v !*/.3gp !*/.3g2 !*/.rm !*/.mov !*/.flv !*/.iso !*/.swf !*/.flac !*/.nar !*/.o !*/.ogg !*/.otf !*/.p !*/.pdf !*/.doc !*/.docx !*/.xls !*/.xlsx !*/.ppt !*/.pptx !*/.pkl !*/.pickle !*/.pyc !*/.pyd !*/.pyo !*/.pub !*/.pem !*/.rkt !*/.so !*/.ss !*/.eot !*/.exe !*/.pb.go !*/.lock !*/.ttf !*/.yaml !*/.yml !*/.cfg !*/.toml !*/.ini !*/.mod !*/.sum !*/.work !*/.json !*/.mmd !*/.svg !*/.jpeg !*/.jpg !*/.png !*/.gif !*/.bmp !*/.tiff !*/.webm !*/.woff !*/.woff2 !*/.dot !*/.md5sum !*/.wasm !*/.snap !*/.parquet !/gen/ !/_gen/ !/generated/ !/@generated/ !/vendor/ !*/.min.js !*/.min.js.map !*/.min.js.css !*/.tfstate !*/.tfstate.backup
disable_review	Only provide the summary and skip the code review.	no	false
disable_release_notes	Disable release notes	no	false
summary_model	Model to use for simple tasks like summarizing diff on a file. When multiple models are specified in separate lines, they will be used in order of priority from top to bottom. If a model is unavailable, the next model in the list will be used as a fallback.	yes	openai/gpt-3.5-turbo
model	Model to use for review tasks. When multiple models are specified in separate lines, they will be used in order of priority from top to bottom. If a model is unavailable, the next model in the list will be used as a fallback.	yes	openai/gpt-4o
retries	How many times to retry OpenAI API in case of timeouts or errors?	no	5
timeout_ms	Timeout for OpenAI API call in millis	no	300000
release_notes_title	Title for the release notes	no	Key Changes
system_prompt	System message to be sent to LLM	no	You are a principal software engineer reviewing a GitHub pull request. Think through the diff carefully before you respond. Use any supplied context (language, framework, product intent) to ground your review. Focus on high-impact issues only: - Functional correctness, edge cases, and regression risks - Security vulnerabilities (cite Severity + impact when you find one) - Concurrency and state safety concerns - Performance regressions that materially affect behavior - Maintainability blockers that will hinder future changes Skip minor formatting, naming, or documentation nits unless they mask a real defect. Do not praise the author or summarize the PR. For each diff hunk you review: 1. Reason about behavior using the PR description and surrounding code. 2. When you find a problem, start the comment with `start-end:` (new line numbers), explain the issue succinctly, and show the minimal fix in a fenced `diff` block. Do not use `suggestion` code fences. 3. Separate multiple comments with `---`. When the issue is security related, append `Severity: <Critical\|High\|Medium\|Low>` plus a one-line impact statement. If a hunk has no actionable issues, respond with `LGTM!` for that hunk. Justify every claim, stay concise, and prefer concrete guidance over open-ended questions.
summarize_release_notes	The prompt for generating release notes in the same chat as summarize stage	no	Craft concise release notes for the pull request. Focus on the purpose and user impact, categorizing changes as "New Feature", "Bug Fix", "Documentation", "Refactor", "Style", "Test", "Chore", or "Revert". Provide a bullet-point list, e.g., "- New Feature: Added search functionality to the UI". Limit your response to 50-100 words and emphasize features visible to the end-user while omitting code-level details.
use_file_content	If true, it will also provide the file content as context when review or summary.	no	false
custom_review_policy	Set the policies for reviewing the modified code.	no	""
language	the response language	no	en-US
comment_greeting	Greeting message for the comment	no	Review bot comments:
ignore_keywords	Ignore keywords for the review	no	@review-bot: ignore @review-bot: no-review @review-bot: skip-review
base_url	Specify the URL when using OpenAI-compatible API	no	""
file_type_prompts	File type specific prompts in YAML format to enhance review quality. Each file type can have customized review guidelines and focus areas. Example: javascript: \| Focus on ES6+ best practices and modern JavaScript patterns. Check for proper async/await usage and error handling. Verify performance optimizations and security considerations. python: \| Focus on PEP8 compliance and Python best practices. Check for proper type hints and exception handling. Verify security vulnerabilities and performance issues. typescript: \| Focus on type safety and TypeScript best practices. Check for proper interface definitions and generic usage. Verify strict mode compliance and null safety. go: \| Focus on Go idioms and best practices. Check for proper error handling and goroutine usage. Verify memory efficiency and concurrency patterns. Supported file types include: javascript, typescript, python, java, go, rust, cpp, c, php, ruby, swift, kotlin, scala, shell, sql, html, css, yaml, json, markdown, docker, and many more.	no	""

Outputs

no outputs