The PR Fixer Orchestrator must understand the underlying requirements of a PR before fixing issues. This ensures fixes align with the original intent and all acceptance criteria are met. Linked GitHub Issues Primary source of requirements and acceptance criteria - Issue title and body - Acceptance criteria sections - Technical specifications - User stories or use cases PR Description Often contains implementation notes and context - Feature description - Implementation approach - Testing notes - Breaking changes PR Comments May contain clarifications and additional requirements - Author clarifications - Reviewer questions and answers - Scope changes or additions Code Analysis Infer requirements from the implementation - API contracts - Data flow patterns - Test cases (reveal expected behavior) - Documentation comments Extract Explicit Requirements - Parse linked issues for acceptance criteria - Extract requirements from PR description - Identify success metrics Understand Implementation Intent - Analyze the code changes to understand approach - Identify design decisions made - Note any architectural patterns used Map Requirements to Implementation - Verify each requirement has corresponding code - Identify any missing functionality - Note any extra functionality added Identify Gaps - List unimplemented requirements - Note incomplete features - Identify missing tests - Clear description of the bug - Steps to reproduce - Expected vs actual behavior - Affected versions/environments - Feature description - User stories or use cases - API design (if applicable) - UI/UX specifications - Performance requirements - Motivation for refactoring - Backward compatibility needs - Performance improvements expected - Migration path (if breaking)