magic-slash v0.42.4 - /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:

1. Identify the current repo by comparing $PWD with the paths in .repositories
2. For each parameter, check the repo config
3. 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
  # Display error and stop
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:

1. Get the current branch name: git branch --show-current
2. Search for open PRs matching the current branch (head parameter)
3. If no match, search for PRs whose title contains the ticket ID
4. 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.

1. PR details: Use mcp__github__get_pull_request to get the PR description, title, base branch, head branch
2. Changed files: Use mcp__github__get_pull_request_files to get the list of modified files
3. Existing comments: Use mcp__github__get_pull_request_comments to see any existing review comments
4. 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:

1. Use Read to read the full file (not just the diff) to understand the complete context
2. Use Grep and Glob to find related files (tests, interfaces, types, imports) for additional context
3. 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

1. Correctness: Logic errors, edge cases, null/undefined handling, race conditions
2. Security: Input validation, injection risks, authentication/authorization, sensitive data exposure
3. Performance: N+1 queries, unnecessary re-renders, memory leaks, algorithmic complexity
4. Code quality: Naming, readability, DRY principle, SOLID principles, consistent patterns
5. Tests: Coverage of new code, edge cases tested, test quality
6. 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:

1. Overall assessment (1-2 sentences)
2. List of blocking issues (if any)
3. List of suggestions (if any)
4. 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:

1. Read the config to get all configured repos
2. For each repo, check if a worktree with the same TICKET-ID exists:

   ls -d {REPO_PATH}-{TICKET_ID} 2>/dev/null
   

3. 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.