IMPORTANT: Always check for and use PR template if available
3.1. PR Template Detection and Parsing
Check for PR template in common locations:
.github/PULL_REQUEST_TEMPLATE.md
.github/pull_request_template.md
.github/PULL_REQUEST_TEMPLATE/
(directory with multiple templates)
docs/pull_request_template.md
Read and parse template comprehensively: If found, analyze the template to extract:
Structural elements: Required sections, checklists, format requirements
Content requirements: What information needs to be provided in each section
Process instructions: Any workflow enhancements or prerequisites specified in the template
Validation requirements: Any checks, sign-offs, or verifications mentioned
Extract actionable instructions from template:
Commit requirements: Look for DCO sign-off, commit message format, commit signing requirements
Pre-submission actions: Build commands, test commands, linting, format checks
Documentation requirements: Which docs must be updated, links that must be added
Review requirements: Required reviewers, approval processes, special considerations
Examples of template instructions to identify and execute:
"All commits must include a
Signed-off-by
line" → Validate commits have DCO sign-off, amend if missing
"Run
npm test
before submitting" → Execute test command
"PR title follows Conventional Commits format" → Validate title format
"Update CHANGELOG.md" → Check if changelog was updated
Any bash commands shown in code blocks → Consider if they should be executed
3.2. Analyze Changes for PR Content
Review git diff: Analyze
git diff main...HEAD
to understand scope of changes
Review commit history: Use
git log main..HEAD
to understand implementation progression
Identify change types: Determine if changes include:
New features, bug fixes, refactoring, documentation, tests, configuration, dependencies
Breaking changes or backward-compatible changes
Performance improvements or security fixes
Check modified files: Identify which areas of codebase were affected
Source code files
Test files
Documentation files
Configuration files
3.3. Auto-Fill PR Information
Automatically populate what can be deduced from analysis:
PR Title:
Follow template title format if specified (e.g., Conventional Commits:
feat(scope): description
)
Extract from PRD title/description and commit messages
Include issue reference if required by template
Description sections:
What/Why: Extract from PRD objectives and implementation details
Related issues: Automatically link using
Closes #[issue-id]
or
Fixes #[issue-id]
Type of change: Check appropriate boxes based on file analysis
Testing checklist:
Mark "Tests added/updated" if test files were modified
Note: Tests run in CI/CD automatically
Documentation checklist:
Mark items based on which docs were updated (README, API docs, code comments)
Check if CONTRIBUTING.md guidelines followed
Security checklist:
Scan commits for potential secrets or credentials
Flag if authentication/authorization code changed
Note any dependency updates
3.4. Prompt User for Information That Cannot Be Deduced
IMPORTANT: Don't just ask - analyze and propose answers, then let user confirm or correct
For each item, use available context to propose an answer, then present it to the user for confirmation:
Manual testing results:
Analyze PRD testing strategy section to understand what testing was planned
Check git commits for testing-related messages
Propose testing approach based on change type (e.g., "Documentation reviewed for accuracy and clarity, cross-references validated")
Present proposal and ask: "Is this accurate, or would you like to modify?"
Breaking changes:
Scan commits and PRD for breaking change indicators
If detected, propose migration guidance based on PRD content
If not detected, confirm: "No breaking changes detected. Correct?"
Performance implications:
Analyze change type: Documentation/config changes typically have no performance impact
Propose answer based on analysis (e.g., "No performance impact - documentation only")
Ask: "Correct, or are there performance considerations?"
Security considerations:
Check if security-sensitive files were modified (auth, credentials, API keys)
Scan commits for security-related keywords
Propose security status (e.g., "No security implications - documentation changes only")
Ask: "Accurate, or are there security considerations to document?"
Reviewer focus areas:
Analyze PRD objectives and git changes to identify key areas
Propose specific focus areas (e.g., "Verify documentation accuracy, check cross-reference links, confirm workflow examples match implementation")
Present list and ask: "Are these the right focus areas, or should I adjust?"
Follow-up work:
Check PRD for "Future Enhancements" or "Out of Scope" sections
Analyze other PRDs in
prds/
directory for related work
Propose follow-up items if any (e.g., "Future enhancements listed in PRD: template validation, AI-powered descriptions")
Ask: "Should I list these, or is there other follow-up work?"
Additional context:
Review PRD for special considerations
Check if this is a dogfooding/testing PR
Propose any relevant context (e.g., "This PR itself tests the enhanced workflow it documents")
Ask: "Anything else reviewers should know?"
Presentation Format:
Present all proposed answers together in a summary format:
markdown
📋 **Proposed PR Information** (based on analysis)
**Manual Testing:** [proposed answer]
**Breaking Changes:** [proposed answer]
**Performance Impact:** [proposed answer]
**Security Considerations:** [proposed answer]
**Reviewer Focus:** [proposed list]
**Follow-up Work:** [proposed items or "None"]
**Additional Context:** [proposed context or "None"]
Please review and respond:
- Type "yes" or "confirm" to accept all
- Specify corrections for any items that need changes
3.5. Execute Template Requirements
IMPORTANT: Before creating the PR, identify and execute any actionable requirements from the template
Analyze template for actionable instructions:
Scan template content for imperative statements, requirements, or commands
Look for patterns like "must", "should", "run", "execute", "ensure", "verify"
Identify bash commands in code blocks that appear to be prerequisites
Extract any validation requirements mentioned in checklists
✅ Feature is live and functional
✅ All tests passing in production
✅ Documentation is accurate and complete
✅ PRD issue is closed with completion summary
✅ Team is notified of feature availability
The PRD implementation is only considered done when users can successfully use the feature as documented.