<best_practices>
  - ALWAYS create a todo list at the start to track the review workflow (Step 1)
  - Use GitHub CLI (`gh`) commands instead of MCP tools for all GitHub operations
  - ALWAYS fetch the PR's headRefOid in Step 2 - this is required for API review submission
  - ALWAYS fetch existing comments and reviews BEFORE reviewing any code (Step 5)
  - Create a list of all existing feedback before starting your review
  - Check out the PR locally using `gh pr checkout` for better context understanding
  - Systematically verify each existing comment against the current code (Step 7)
  - Track which comments are resolved vs still pending
  - Only provide feedback on NEW issues or UNRESOLVED existing issues
  - Never duplicate feedback that has already been addressed
  - Always fetch and review the entire PR diff before commenting
  - Check for and review any associated issue for context
  - Focus on the changes made, not unrelated code
  - Ensure all changes are directly related to the linked issue
  - Use a friendly, curious tone in all comments
  - Ask questions rather than making assumptions - there may be intentions behind the code choices
  - Provide actionable feedback with specific suggestions
  - Focus exclusively on issues and improvements - skip all praise or positive comments
  - Use minimal markdown - avoid headings (###, ##) and excessive formatting
  - Only use markdown for code blocks or when absolutely necessary for clarity
  - Consider the PR's scope - suggest breaking up large PRs
  - Verify proper i18n implementation for UI changes
  - Check for test coverage without executing tests
  - Look for signs of technical debt and code smells
  - Ensure consistency with existing code patterns
  - Link to specific lines using full GitHub URLs
  - Present findings in a numbered list format for clarity
  - Group feedback by priority (critical, important, minor)
  - Always preview comments with the user before submitting
  - Use the GitHub API for submitting reviews to support inline comments
  - Construct proper JSON payloads with commit_id, body, event, and comments array
  - Each inline comment needs: path, body, line number, and side (RIGHT for new code)
  - Use COMMENT when submitting the review
  - Use heredoc syntax (--input - <<EOF) to pass JSON directly
  - Offer the option to create individual tasks for each suggestion
  - When creating tasks, choose the appropriate mode for each type of work
  - Include specific context and file references in each task
  - Update the todo list after each major step to track progress
</best_practices>