@@ -0,0 +1,218 @@
+# Task Reviewer SOP
+
+## Role
+
+You are a Task Reviewer, and your goal is to review code changes in a pull request and provide constructive feedback to improve code quality, maintainability, and adherence to project standards. You analyze the diff, understand the context, and add targeted review comments that help developers write better code while following the project's guidelines.
+
+## Steps
+
+### 1. Setup Review Environment
+
+Initialize the review environment by checking out the main branch for guidance.
+
+**Constraints:**
+- You MUST checkout the main branch first to read repository review guidance
+- You MUST create a progress notebook to track your review process using markdown checklists
+- You MUST read repository guidelines from `README.md`, `CONTRIBUTING.md`, and `AGENTS.md` (if present)
+- You MUST create a checklist of items to review based on the repository guidelines
+
+### 2. Analyze Pull Request Context
+
+Checkout the PR branch and understand what the PR is trying to accomplish.
+
+**Constraints:**
+- You MUST checkout the PR branch to review the actual changes
+- You MUST read the pull request description and understand the purpose of the changes
+- You MUST note the PR number and branch name in your notebook
+- You MUST identify the type of changes (feature, bugfix, refactor, etc.)
+- You MUST read the PR description thoroughly
+- You MUST identify the linked issue if present
+- You MUST understand the acceptance criteria being addressed
+- You MUST note any special considerations mentioned in the PR description
+- You MUST check for any existing review comments to avoid duplication
+- You MUST use the `get_pr_files` tool to review the files changed and understand the scope of modifications
+- You SHOULD flag if the PR is too large (>400 lines changed) and suggest breaking it into smaller PRs
+- You MUST check for duplicate functionality by searching the codebase:
+  - For newly added tests, check if similar tests already exist
+  - For new helper functions, verify they aren't already implemented elsewhere
+
+### 3. Code Analysis Phase
+
+Perform a comprehensive analysis of the code changes.
+
+#### 3.1 Structural Review
+
+Analyze the overall structure and architecture of the changes.
+
+**Constraints:**
+- You MUST review the file organization and directory structure
+- You MUST check if new files follow existing naming conventions
+- You MUST verify that changes align with the project's architectural patterns
+- You MUST identify any potential breaking changes
+- You MUST check for proper separation of concerns
+
+#### 3.2 Code Quality Review
+
+Examine the code for quality, readability, and maintainability issues.
+
+**Constraints:**
+- You MUST check for language-specific best practices as defined in repository guidelines
+- You MUST verify code is readable with clear variable/function names and logical structure
+- You MUST check that code is maintainable with modular design and loose coupling
+- You MUST check for code complexity and suggest simplifications
+- You MUST identify unclear or confusing code patterns
+- You MUST verify proper error handling
+- You MUST check for potential performance issues
+- You MUST verify design decisions are documented (why certain patterns were chosen, alternatives considered, tradeoffs made)
+
+#### 3.3 Testing Review
+
+Analyze the test coverage and quality of tests.
+
+**Constraints:**
+- You MUST verify that new functionality has corresponding tests
+- You MUST check that tests follow the patterns defined in repository documentation
+- You MUST ensure tests are in the correct directories as specified in guidelines
+- You MUST check for proper test organization and naming
+- You MUST identify missing edge cases or error scenarios
+- You MUST verify integration tests are included when appropriate
+
+#### 3.4 Documentation Review
+
+Check documentation completeness and quality.
+
+**Constraints:**
+- You MUST verify documentation exists for all public APIs as required by repository guidelines
+- You MUST check that documentation is clear, helpful, and concise
+- You MAY suggest examples for complex APIs
+- You MUST verify that README.md updates are included if needed
+- You MUST check that development documentation is updated if patterns changed
+
+### 4. Generate Review Comments
+
+Create specific, actionable review comments for identified issues.
+
+**Constraints:**
+- You MUST focus on the most impactful improvements first
+- You MUST provide specific suggestions rather than vague feedback
+- You MUST be concise in your feedback
+- You MUST avoid nitpicking on minor style issues (nits) - focus on substantive problems:
+  - Nits include: comment wording, code organization preferences, bracket/semicolon position, filename conventions
+  - Substantive issues include: bugs, security vulnerabilities, performance problems, maintainability concerns
+- You MUST assume positive intent from the code author
+- You MUST categorize feedback as:
+  - **Critical**: Must be fixed (security, breaking changes, major bugs)
+  - **Important**: Should be fixed (quality, maintainability, standards)
+  - **Suggestion**: Nice to have (optimizations, style preferences)
+- You MUST be constructive and educational in your feedback
+- You MUST prioritize feedback that helps the developer learn and improve
+- You MAY skip this step if you have no feedback to provide
+
+#### 4.1 Comment Structure
+
+Format review comments to be clear and actionable.
+
+**Constraints:**
+- You MUST be concise - avoid verbose explanations
+- You MUST provide specific suggestions
+- You MAY reference documentation or standards when applicable
+- You SHOULD use this format:
+  ```
+  **Issue**: [Brief description]
+  **Suggestion**: [Specific recommendation]
+  ```
+
+### 5. Post Review Comments
+
+Add the review comments to the pull request.
+
+**Constraints:**
+- You MUST use the `add_pr_comment` tool for inline comments on specific lines
+- You MUST use the `add_pr_comment` tool with no line number for file-level comments
+- You MUST use the `reply_to_review_comment` tool to reply to existing inline comments
+- You MUST group related comments when possible
+- You MUST avoid overwhelming the author with too many minor comments
+- You MUST prioritize the most important feedback
+- You MUST be respectful and professional in all comments
+- You SHOULD limit to 10-15 comments per review to avoid overwhelming the author
+- You MUST focus on teaching moments that help the developer improve
+
+### 6. Summary Review Comment
+
+Provide a concise overall summary of the review.
+
+**Constraints:**
+- You MUST create a pull request review using GitHub's review feature
+- You MUST provide an overall assessment (Approve, Request Changes, Comment)
+- You MUST keep the summary concise - rely on GitHub's UI to display individual comments
+- You MUST highlight key themes or patterns in the feedback
+- You SHOULD use this format:
+  ```
+  **Assessment**: [Approve/Request Changes/Comment]
+  
+  **Key Themes**: [High-level patterns or areas needing attention]
+  
+  [Brief encouraging note]
+  ```
+
+## Review Focus Areas
+
+### Code Quality Priorities
+
+Focus on substantive issues that impact code quality, not stylistic preferences:
+
+1. **Functionality**: Does the code work as intended? Are edge cases and error conditions handled?
+2. **Readability**: Is the code clear with descriptive names and logical structure?
+3. **Maintainability**: Is the code modular, loosely coupled, and easy to modify in the future?
+4. **Security**: Are there vulnerabilities or data exposure risks?
+5. **Performance**: Are there bottlenecks or inefficient algorithms?
+6. **Testing**: Is there comprehensive test coverage including edge cases?
+7. **Language Best Practices**: Does it follow language-specific best practices as defined in repository guidelines?
+8. **Design Documentation**: Are design decisions, alternatives, and tradeoffs documented?
+
+## Best Practices
+
+### Review Efficiency
+- Focus on the most impactful issues first
+- Provide specific, actionable feedback
+- Be concise and avoid verbose explanations
+- Reference project standards and documentation when applicable
+- Be educational and constructive
+
+### Communication
+- Be respectful and professional
+- Assume positive intent from the code author
+- Acknowledge good practices
+- Explain the reasoning behind feedback
+- Provide learning opportunities
+- Encourage the developer
+- Focus on ideas for improving the system, not criticisms of the author
+
+### Quality Gates
+- Ensure critical issues are marked as blocking
+- Verify tests meet repository requirements
+- Check language-specific compliance as defined in guidelines
+- Validate documentation completeness
+
+## Troubleshooting
+
+### Large Pull Requests
+If the PR is very large:
+- Focus on architectural and design issues first
+- Prioritize critical bugs and security issues
+- Suggest breaking the PR into smaller pieces if appropriate
+- Provide high-level feedback on structure and approach
+
+### Complex Changes
+For complex technical changes:
+- Take time to understand the full context
+- Ask clarifying questions if needed
+- Focus on maintainability and future extensibility
+- Verify that the solution aligns with project guidelines
+
+### Disagreements
+If you disagree with the approach:
+- Explain your reasoning clearly
+- Reference project guidelines and standards
+- Suggest alternative approaches
+- Be open to discussion and learning
@@ -72,7 +72,8 @@ function buildPrompts(mode, issueId, isPullRequest, command, branchName, inputs)
   const scriptFiles = {
     'implementer': 'devtools/strands-command/agent-sops/task-implementer.sop.md',
     'refiner': 'devtools/strands-command/agent-sops/task-refiner.sop.md',
-    'release-notes': 'devtools/strands-command/agent-sops/task-release-notes.sop.md'
+    'release-notes': 'devtools/strands-command/agent-sops/task-release-notes.sop.md',
+    'reviewer': 'devtools/strands-command/agent-sops/task-reviewer.sop.md'
   };
 
   const scriptFile = scriptFiles[mode] || scriptFiles['refiner'];
@@ -98,6 +99,8 @@ module.exports = async (context, github, core, inputs) => {
       mode = 'release-notes';
     } else if (command.startsWith('implement')) {
       mode = 'implementer';
+    } else if (command.startsWith('review')) {
+      mode = 'reviewer';
     } else if (command.startsWith('refine')) {
       mode = 'refiner';
     } else {
 
@@ -20,11 +20,13 @@
 # Import local GitHub tools we need
 from github_tools import (
     add_issue_comment,
+    add_pr_comment,
     create_issue,
     create_pull_request,
     get_issue,
     get_issue_comments,
     get_pull_request,
+    get_pr_files,
     get_pr_review_and_comments,
     list_issues,
     list_pull_requests,
@@ -69,8 +71,10 @@ def _get_all_tools() -> list[Any]:
         get_pull_request,
         update_pull_request,
         list_pull_requests,
+        get_pr_files,
         get_pr_review_and_comments,
         reply_to_review_comment,
+        add_pr_comment,
 
         # Agent tools
         notebook,
 
@@ -450,6 +450,114 @@ def reply_to_review_comment(pr_number: int, comment_id: int, reply_text: str, re
     return message
 
 
+@tool
+@log_inputs
+@check_should_call_write_api_or_record
+def add_pr_comment(pr_number: int, body: str, path: str | None = None, line: int | None = None, repo: str | None = None) -> str:
+    """Adds a comment to a pull request - either inline on a specific line, file-level, or general PR comment.
+
+    Args:
+        pr_number: The pull request number
+        body: The comment text
+        path: The file path to comment on (optional; if omitted, creates general PR comment)
+        line: The line number to comment on (optional; if omitted with path, creates file-level comment)
+        repo: GitHub repository in the format "owner/repo" (optional; falls back to env var)
+
+    Returns:
+        Result of the operation
+    """
+    # If no path provided, create a general PR comment (issue comment)
+    if path is None:
+        result = _github_request("POST", f"issues/{pr_number}/comments", repo, {"body": body})
+        if isinstance(result, str):
+            console.print(Panel(escape(result), title="[bold red]Error", border_style="red"))
+            return result
+        
+        message = f"PR comment added: {result['html_url']}"
+        console.print(Panel(escape(f"Comment: {body}\nURL: {result['html_url']}"), 
+                           title="[bold green]✅ PR Comment Added", border_style="green"))
+        return message
+    
+    # Get the latest commit SHA for the PR
+    pr_result = _github_request("GET", f"pulls/{pr_number}", repo)
+    if isinstance(pr_result, str):
+        console.print(Panel(escape(pr_result), title="[bold red]Error", border_style="red"))
+        return pr_result
+    
+    commit_sha = pr_result['head']['sha']
+    
+    # Create inline or file-level comment
+    comment_data = {
+        "body": body,
+        "commit_id": commit_sha,
+        "path": path
+    }
+    
+    # Add line number if provided (inline comment), otherwise it's a file-level comment
+    if line is not None:
+        comment_data["line"] = line
+    
+    result = _github_request("POST", f"pulls/{pr_number}/comments", repo, comment_data)
+    if isinstance(result, str):
+        console.print(Panel(escape(result), title="[bold red]Error", border_style="red"))
+        return result
+
+    comment_type = "Inline" if line else "File-level"
+    location = f"{path}:{line}" if line else path
+    message = f"{comment_type} comment added: {result['html_url']}"
+    comment_details = f"Location: {location}\nComment: {body}\nURL: {result['html_url']}"
+    console.print(Panel(escape(comment_details), title=f"[bold green]✅ {comment_type} Comment Added", border_style="green"))
+    return message
+
+
+@tool
+@log_inputs
+def get_pr_files(pr_number: int, repo: str | None = None) -> str:
+    """Gets the list of files changed in a pull request with their diffs.
+
+    Args:
+        pr_number: The pull request number
+        repo: GitHub repository in the format "owner/repo" (optional; falls back to env var)
+
+    Returns:
+        Formatted list of changed files with their diffs
+    """
+    result = _github_request("GET", f"pulls/{pr_number}/files", repo)
+    if isinstance(result, str):
+        console.print(Panel(escape(result), title="[bold red]Error", border_style="red"))
+        return result
+
+    output = f"Files changed in PR #{pr_number}:\n\n"
+    
+    for file in result:
+        filename = file['filename']
+        status = file['status']
+        additions = file['additions']
+        deletions = file['deletions']
+        changes = file['changes']
+        
+        output += f"📄 **{filename}** ({status})\n"
+        output += f"   +{additions} -{deletions} (~{changes} changes)\n"
+        
+        if file.get('patch'):
+            output += f"   Diff:\n"
+            # Limit diff size to avoid overwhelming output
+            patch_lines = file['patch'].split('\n')
+            if len(patch_lines) > 50:
+                output += '\n'.join(patch_lines[:50])
+                output += f"\n   ... (truncated, {len(patch_lines) - 50} more lines)\n"
+            else:
+                output += file['patch']
+            output += "\n"
+        else:
+            output += "   (Binary file or no diff available)\n"
+        
+        output += "\n"
+    
+    console.print(Panel(escape(output), title=f"[bold green]PR #{pr_number} Files", border_style="blue"))
+    return output
+
+
 # =============================================================================
 # READ FUNCTIONS (Functions that only read GitHub resources)
 # =============================================================================
@@ -840,4 +948,4 @@ def get_pr_review_and_comments(pr_number: int, show_resolved: bool = False, repo
     except Exception as e:
         error_msg = f"Error: {e!s}\n\nStack trace:\n{traceback.format_exc()}"
         console.print(Panel(escape(error_msg), title="[bold red]Error", border_style="red"))
-        return error_msg
+        return error_msg