| name | magic:review |
| description | This skill should be used when the user says "review", "revue de code", "code review", "review the PR", "regarde la PR", "review my PR", "self-review", "auto-review", "check my PR", "vérifie ma PR", or indicates they want to perform a code review on a pull request. |
| argument-hint | <TICKET-ID> (optional) |
| allowed-tools | Bash(*), Read, Glob, Grep, AskUserQuestion, mcp__github__*, mcp__atlassian__* |
magic-slash v0.48.0 - /review
IMPORTANT: You MUST follow EACH step of this skill in order. Do not skip any step and do not take shortcuts. Each step is essential for the proper functioning of the workflow.
NOTE: This skill does NOT modify any files. It only reads code and submits a review on GitHub.
You are an assistant that performs a thorough code review on a pull request. You detect whether this is a self-review (your own PR) or a review of someone else's PR, and adapt accordingly.
References
references/messages.md — All bilingual message templates (EN/FR). Read relevant sections as needed (not the whole file at once).
Configuration
Read ~/.config/magic-slash/config.json and determine the parameters based on the current repo:
- Identify the current repo by comparing
$PWD with the paths in .repositories
- For each parameter, check the repo config
- If no value is defined, use the default value
Language parameters
| Parameter | Repo path | Default |
|---|
| Discussion language | .repositories.<name>.languages.discussion | "en" |
Step 0: Check configuration
Before starting, verify that the Magic Slash configuration exists:
CONFIG_FILE=~/.config/magic-slash/config.json
if [ ! -f "$CONFIG_FILE" ]; then
fi
If the config does not exist, display MSG_CONFIG_ERROR and stop.
Step 1: Detect the ticket
If an argument is provided (e.g., /magic:review PROJ-123), use it as the ticket ID.
Otherwise, extract the ticket ID from the current worktree:
basename "$PWD"
The worktree name follows the pattern {repo-name}-{TICKET-ID} (e.g.: my-api-PROJ-123).
Extract the TICKET-ID using the pattern:
- Jira:
[A-Z]+-\d+ (e.g.: PROJ-123, ABC-456)
- GitHub: the last numeric segment after the repo name (e.g.:
123 in my-api-123)
If no ticket ID is found, ask the user which PR to review.
Step 2: Find the associated PR
Use mcp__github__list_pull_requests to find the PR associated with this ticket. If the MCP call fails (timeout, auth error), retry once. If it fails again, ask the user for the PR number.
Search strategy:
- Get the current branch name:
git branch --show-current
- Search for open PRs matching the current branch (head parameter)
- If no match, search for PRs whose title contains the ticket ID
- If still no match, ask the user for the PR number
Store the PR number and repository info.
Step 3: Detect self-review vs external review
Compare the current branch with the PR's head branch:
CURRENT_BRANCH=$(git branch --show-current)
- Self-review: The current branch matches the PR's head branch (you are the author)
- External review: The current branch does NOT match (you are reviewing someone else's code)
This affects the tone and focus of the review:
- Self-review: Quality gate before requesting human review. Focus on catching issues you might have missed. Friendly, constructive tone.
- External review: Formal code review. Thorough analysis with clear actionable feedback.
Step 4: Update Magic Slash metadata
Update the status to "in review":
[ -n "$MAGIC_SLASH_PORT" ] && [ -n "$MAGIC_SLASH_TERMINAL_ID" ] && curl -s "http://127.0.0.1:$MAGIC_SLASH_PORT/metadata?id=$MAGIC_SLASH_TERMINAL_ID&status=in%20review" > /dev/null 2>&1 || true
Step 5: Retrieve PR details
Gather all necessary information about the PR. For each MCP call below, if it fails (timeout, auth error), retry once. If get_pull_request or get_pull_request_files fails after retry, ask the user for the PR URL. If get_pull_request_comments or get_pull_request_reviews fails after retry, continue without that data — the review can proceed with partial information.
- PR details: Use
mcp__github__get_pull_request to get the PR description, title, base branch, head branch
- Changed files: Use
mcp__github__get_pull_request_files to get the list of modified files
- Existing comments: Use
mcp__github__get_pull_request_comments to see any existing review comments
- Existing reviews: Use
mcp__github__get_pull_request_reviews to see previous reviews
Step 6: Read the source code
For each modified file from Step 5:
- Use
Read to read the full file (not just the diff) to understand the complete context
- Use
Grep and Glob to find related files (tests, interfaces, types, imports) for additional context
- Pay attention to:
- How the modified code integrates with the rest of the codebase
- Whether tests exist for the modified code
- Whether the changes follow existing patterns and conventions
Step 7: Analyze the code
Perform a thorough analysis covering these categories:
Analysis categories
- Correctness: Logic errors, edge cases, null/undefined handling, race conditions
- Security: Input validation, injection risks, authentication/authorization, sensitive data exposure
- Performance: N+1 queries, unnecessary re-renders, memory leaks, algorithmic complexity
- Code quality: Naming, readability, DRY principle, SOLID principles, consistent patterns
- Tests: Coverage of new code, edge cases tested, test quality
- Breaking changes: API changes, schema changes, backwards compatibility
Categorize each finding
- 🚫 Blocking: Must be fixed before merging (bugs, security issues, breaking changes)
- 💡 Suggestion: Improvement that would be nice but not required
- 👍 Praise: Well-done code worth highlighting (good patterns, clever solutions, thorough tests)
Step 8: Submit the review on GitHub
Use mcp__github__create_pull_request_review to submit the review.
Determine the review event
Based on the findings from Step 7:
- APPROVE: No blocking issues found. Code is ready to merge.
- REQUEST_CHANGES: One or more blocking issues found. Must be fixed before merging.
- COMMENT: Only suggestions and praise. No blocking issues, but worth discussing.
Review body format
Write a clear, structured review summary. Include:
- Overall assessment (1-2 sentences)
- List of blocking issues (if any)
- List of suggestions (if any)
- Praise for well-done code (if any)
For inline comments, use the comments parameter with file path, line number, and comment body.
Step 9: Update Magic Slash metadata
Based on the review result, update the status:
- APPROVE: Status remains
PR created (awaiting merge)
[ -n "$MAGIC_SLASH_PORT" ] && [ -n "$MAGIC_SLASH_TERMINAL_ID" ] && curl -s "http://127.0.0.1:$MAGIC_SLASH_PORT/metadata?id=$MAGIC_SLASH_TERMINAL_ID&status=PR%20created" > /dev/null 2>&1 || true
- REQUEST_CHANGES: Status changes to
changes requested
[ -n "$MAGIC_SLASH_PORT" ] && [ -n "$MAGIC_SLASH_TERMINAL_ID" ] && curl -s "http://127.0.0.1:$MAGIC_SLASH_PORT/metadata?id=$MAGIC_SLASH_TERMINAL_ID&status=changes%20requested" > /dev/null 2>&1 || true
Step 10: Summary
Display MSG_REVIEW_SUMMARY based on .languages.discussion.
Include the conditional "Next steps" block based on the review result (APPROVE, REQUEST_CHANGES, or COMMENT) as defined in the message template.
Step 11: Multi-repo support (if applicable)
If the ticket ID is associated with multiple worktrees (full-stack task), repeat Steps 2-10 for each worktree that has an open PR.
To detect multi-repo:
- Read the config to get all configured repos
- For each repo, check if a worktree with the same TICKET-ID exists:
ls -d {REPO_PATH}-{TICKET_ID} 2>/dev/null
- For each found worktree, find and review the associated PR
Display MSG_REVIEW_SUMMARY_FULLSTACK as a combined summary at the end, listing each worktree with its PR number and review result.
Step 12: (Optional) Comment on Jira
12.0: Check Atlassian integration
Read integrations.atlassian from ~/.config/magic-slash/config.json. Default: true.
If integrations.atlassian is false, skip this step entirely.
12.1: Add comment
If the ticket is a Jira ticket and commentOnPR is not false, add a comment on the Jira ticket using MSG_JIRA_REVIEW_COMMENT.
