Skip to main content
The pull request template helps maintain consistency across all PRs by providing a standard structure for contributors to follow. Your template is located at .github/pull_request_template.md.

​
Template Structure

Here’s the current PR template from the repository: 
## Description

## Checklist
- [ ] Lint & tests OK
- [ ] Security reviewed
- [ ] Docs updated
This template includes:
  • Description section: A dedicated space for contributors to explain what changed and why
  • Checklist items: Essential pre-merge requirements that must be verified
The template automatically populates when creating a new pull request on GitHub, making it easy for contributors to fill in the required information.

​
Checklist Items Explained

Each checklist item serves a specific purpose:
Ensures that:
  • All linting rules pass without warnings or errors
  • Unit tests, integration tests, and e2e tests all pass
  • Code coverage requirements are met
  • The build completes successfully
Contributors should run npm test or your project’s equivalent before submitting.
Requires the contributor to:
  • Review code for potential security vulnerabilities
  • Check for exposed secrets or API keys
  • Validate input sanitization and authentication
  • Consider potential attack vectors
For sensitive changes, a dedicated security review from a team member may be required.
Ensures documentation stays in sync with code changes:
  • Update README files if user-facing features changed
  • Add or modify API documentation
  • Update configuration examples
  • Add migration guides for breaking changes

​
Customization Guide

​
Adding More Sections

You can extend the template with additional sections that fit your workflow: 
## Description

## Type of Change
- [ ] Bug fix
- [ ] New feature
- [ ] Breaking change
- [ ] Documentation update

## Testing
Describe the testing performed:

## Screenshots
(If applicable)

## Related Issues
Closes #

## Checklist
- [ ] Lint & tests OK
- [ ] Security reviewed
- [ ] Docs updated
- [ ] Reviewed my own code
- [ ] Added tests for new functionality

​
Adding Conditional Checklists

For different types of changes, you can include conditional sections: 
## Frontend Changes
- [ ] Tested in Chrome, Firefox, Safari
- [ ] Mobile responsive
- [ ] Accessibility checked

## Backend Changes
- [ ] Database migrations included
- [ ] API endpoints documented
- [ ] Performance impact assessed
Keep your template concise but comprehensive. Too many required fields can slow down contributions, while too few can lead to incomplete PRs.

​
Adding Review Guidelines

Help reviewers by including guidance: 
## For Reviewers

**Focus Areas:**
- [ ] Code quality and maintainability
- [ ] Test coverage
- [ ] Performance implications
- [ ] Security considerations

**Merge Requirements:**
- At least 2 approvals required
- All CI checks must pass
- No unresolved conversations

​
Best Practices

  1. Keep it actionable: Every section should have a clear purpose
  2. Use checkboxes: They provide visual progress and clear completion status
  3. Include examples: Link to exemplary PRs for reference
  4. Update regularly: Review and refine based on team feedback
  5. Automate checks: Use GitHub Actions to enforce checklist items

​
Multiple Templates

For projects with diverse contribution types, you can create multiple PR templates: 
.github/
  PULL_REQUEST_TEMPLATE/
    feature.md
    bugfix.md
    hotfix.md
Contributors can then choose the appropriate template using query parameters: 
https://github.com/owner/repo/compare/main...branch?template=feature.md
When using multiple templates, remove the root pull_request_template.md file to prevent conflicts.

​
Integration with CI/CD

You can enforce checklist items using GitHub Actions: 
name: PR Checklist Validation

on:
  pull_request:
    types: [opened, edited]

jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - name: Check all boxes are ticked
        run: |
          if [[ $(echo "${{ github.event.pull_request.body }}" | grep -c "\[x\]") -lt 3 ]]; then
            echo "Please complete all checklist items"
            exit 1
          fi
This ensures contributors don’t skip important verification steps.

​
See Also

Build docs developers (and LLMs) love

Get started for freeTalk to us