<command_purpose> Perform exhaustive code reviews using multi-agent analysis, ultra-thinking, and Git worktrees for deep local inspection. </command_purpose>
Performs exhaustive multi-agent code reviews using Git worktrees for deep local analysis.
/plugin marketplace add shivrajkumar/traya-plugin/plugin install traya-frontend-engineering@traya-plugin<command_purpose> Perform exhaustive code reviews using multi-agent analysis, ultra-thinking, and Git worktrees for deep local inspection. </command_purpose>
<role>Senior Code Review Architect with expertise in security, performance, architecture, and quality assurance</role>
<review_target> #$ARGUMENTS </review_target>
<critical_requirement> MUST create worktree FIRST to enable local code analysis. No exceptions. </critical_requirement>
<thinking> First, I need to determine the review target type and set up the worktree. This enables all subsequent agents to analyze actual code, not just diffs. </thinking><task_list>
Determine review type: PR number (numeric), GitHub URL, file path (.md), or empty (latest PR)
Create worktree directory structure at $git_root/.worktrees/reviews/pr-$identifier
Check out PR branch in isolated worktree using gh pr checkout
Navigate to worktree - ALL subsequent analysis happens here
Fetch PR metadata using gh pr view --json for title, body, files, linked issues
Clone PR branch into worktree with full history gh pr checkout $identifier
Set up language-specific analysis tools
Prepare security scanning environment
Ensure that the worktree is set up correctly and that the PR is checked out. ONLY then proceed to the next step.
</task_list>
<project_type_detection>
Check for these indicators to determine project type:
TypeScript/React/Next.js Project:
tsconfig.jsonpackage.json with TypeScript, React, or Next.js dependencies.ts, .tsx, .jsx filesnext.config.js or next.config.ts (for Next.js)Based on detection, set appropriate reviewers for parallel execution.
</project_type_detection>
<parallel_tasks>
Run ALL or most of these agents at the same time, adjusting language-specific reviewers based on project type:
Language-Specific Reviewers (choose based on project type):
For TypeScript/React/Next.js projects:
Universal Reviewers (run for all project types): 2. Task git-history-analyzer(PR content) 3. Task pattern-recognition-specialist(PR content) 4. Task architecture-strategist(PR content) 5. Task security-sentinel(PR content) 6. Task performance-oracle(PR content)
</parallel_tasks>
<ultrathink_instruction> For each phase below, spend maximum cognitive effort. Think step by step. Consider all angles. Question assumptions. And bring all reviews in a synthesis to the user.</ultrathink_instruction>
<deliverable> Complete system context map with component interactions </deliverable><thinking_prompt> ULTRA-THINK: Put yourself in each stakeholder's shoes. What matters to them? What are their pain points? </thinking_prompt>
<stakeholder_perspectives>
Developer Perspective <questions>
Operations Perspective <questions>
End User Perspective <questions>
Security Team Perspective <questions>
Business Perspective <questions>
<thinking_prompt> ULTRA-THINK: Explore edge cases and failure scenarios. What could go wrong? How does the system behave under stress? </thinking_prompt>
<scenario_checklist>
Run the Task code-simplicity-reviewer() to see if we can simplify the code.
<critical_requirement> All findings MUST be converted to actionable todos in the CLI todo system </critical_requirement>
<synthesis_tasks>
For EACH finding, present in this format:
---
Finding #X: [Brief Title]
Severity: 🔴 P1 / 🟡 P2 / 🔵 P3
Category: [Security/Performance/Architecture/Quality/etc.]
Description:
[Detailed explanation of the issue or improvement]
Location: [file_path:line_number]
Problem:
[What's wrong or could be better]
Impact:
[Why this matters, what could happen]
Proposed Solution:
[How to fix it]
Effort: Small/Medium/Large
---
Do you want to add this to the todo list?
1. yes - create todo file
2. next - skip this finding
3. custom - modify before creating
<todo_creation_process>
Determine next issue ID:
ls todos/ | grep -o '^[0-9]\+' | sort -n | tail -1
Generate filename:
{next_id}-pending-{priority}-{brief-description}.md
Example: 042-pending-p1-sql-injection-risk.md
Create file from template:
cp todos/000-pending-p1-TEMPLATE.md todos/{new_filename}
Populate with finding data:
---
status: pending
priority: p1 # or p2, p3 based on severity
issue_id: "042"
tags: [code-review, security, rails] # add relevant tags
dependencies: []
---
# [Finding Title]
## Problem Statement
[Detailed description from finding]
## Findings
- Discovered during code review by [agent names]
- Location: [file_path:line_number]
- [Key discoveries from agents]
## Proposed Solutions
### Option 1: [Primary solution from finding]
- **Pros**: [Benefits]
- **Cons**: [Drawbacks]
- **Effort**: [Small/Medium/Large]
- **Risk**: [Low/Medium/High]
## Recommended Action
[Leave blank - needs manager triage]
## Technical Details
- **Affected Files**: [List from finding]
- **Related Components**: [Models, controllers, services affected]
- **Database Changes**: [Yes/No - describe if yes]
## Resources
- Code review PR: [PR link if applicable]
- Related findings: [Other finding numbers]
- Agent reports: [Which agents flagged this]
## Acceptance Criteria
- [ ] [Specific criteria based on solution]
- [ ] Tests pass
- [ ] Code reviewed
## Work Log
### {date} - Code Review Discovery
**By:** Claude Code Review System
**Actions:**
- Discovered during comprehensive code review
- Analyzed by multiple specialized agents
- Categorized and prioritized
**Learnings:**
- [Key insights from agent analysis]
## Notes
Source: Code review performed on {date}
Review command: /workflows:review {arguments}
Track creation: Add to TodoWrite list if tracking multiple findings
</todo_creation_process>
After processing all findings:
## Code Review Complete
**Review Target:** [PR number or branch]
**Total Findings:** [X]
**Todos Created:** [Y]
### Created Todos:
- `{issue_id}-pending-p1-{description}.md` - {title}
- `{issue_id}-pending-p2-{description}.md` - {title}
...
### Skipped Findings:
- [Finding #Z]: {reason}
...
### Next Steps:
1. Triage pending todos: `ls todos/*-pending-*.md`
2. Use `/triage` to review and approve
3. Work on approved items: `/resolve_todo_parallel`
If user wants to convert all findings to todos without review:
# Ask: "Create todos for all X findings? (yes/no/show-critical-only)"
# If yes: create todo files for all findings in parallel
# If show-critical-only: only present P1 findings for triage