What this template is for
Code review is the engineering practice with the widest quality variance. The same PR reviewed by three different engineers gets three different sets of feedback. That variance is not always bad - different reviewers catch different things - but the floor should be predictable.
This template defines the floor. Every code review ticket gets the same sub-task checklist, so a reviewer cannot ship a change without at least considering correctness, tests, security, performance, observability, docs, and rollout.
When to use it
Use a code review ticket for changes that warrant an explicit review beyond your team’s PR-approval default. Typical triggers:
- Security-sensitive code (auth, payments, PII handling)
- Schema or data-migration changes
- Public-API additions or breaking changes
- Hot-path refactors with performance implications
- Anything touching a service the author does not own
For routine changes, a normal PR approval is enough - do not create review tickets for everything, or the signal disappears.
Sub-task breakdown
The sub-tasks above are the explicit checklist. STM Issue Templates can auto-create them on every code-review ticket using an On Create Issue Executor scoped to the code-review issue type or label. The reviewer opens the ticket and the checklist is already there - no copy-pasting from a wiki, no forgetting the security item on the day it actually matters.
Fields to add to your Jira create screen
These are the fields a project admin should make sure exist on the Create Issue screen for this issue type (Project settings → Screens). Without these on the screen, reporters can't provide the information triage needs - and STM can't reference them either.
| Field | Example value | Required |
|---|---|---|
Summary | Code review - payments-svc PR #1284 | Yes |
Pull Request URL (custom) | https://github.com/org/repo/pull/1284 | Yes |
Author | @alex.chen | Yes |
Reviewer/s | @priya.patel, @marek.s | Yes |
Review Type (custom) | Feature / Refactor / Hotfix / Security-sensitive | Yes |
Linked Story/Bug | PROJ-1142 | No |
Risk (custom) | Low / Medium / High | No |
Test Coverage Delta (custom) | +3.2% / -1.1% / unchanged | No |
Component/s | payments-svc | No |
Labels | code-review, security-sensitive | No |
Note on custom fields. STM currently supports up to 5 custom fields per template. You can add as many custom fields as you like to your Jira Create Issue screen - the 5-field limit only applies if you want STM to set or update those custom fields itself.
Sub-tasks STM creates automatically
Build an STM sub-task template containing the items below, then wire it to an On Create Issue Executor scoped to this issue type. Whenever a new issue of this type is created in the project, STM creates the full sub-task set in one step - with assignee, due date, and components inherited from the parent unless you override them.
- Correctness - does the code do what the linked story says?
- Tests - new tests cover happy path and at least one failure mode
- Security - input validation, secrets, authz checks on new endpoints
- Performance - obvious N+1s, hot-path allocations, unbounded queries
- Observability - logs/metrics/traces added for new code paths
- Docs - README / runbook / API reference updated if behaviour changed
- Rollout - feature flag, migration order, and rollback path confirmed
Common questions
What is a Jira code review checklist used for?
It is a reusable checklist of the things every reviewer should verify - correctness, tests, security, performance, observability, docs, rollout. Instead of relying on each reviewer's habits, the checklist makes the review contract explicit so review quality is consistent regardless of who picks up the ticket.
Should every pull request have its own Jira ticket?
Not usually. The PR itself lives in your VCS; the linked story or bug is the work tracker. Create a separate code-review Jira ticket only for changes that need an explicit checklist beyond the team default - security-sensitive code, schema changes, public-API additions, or hot-path refactors.
How do you make a code review checklist mandatory?
Two parts. First, configure the project's workflow so the linked story cannot move to Done unless the review ticket is resolved. Second, auto-create the review sub-task checklist on every review ticket using [STM Issue Templates](/stm/) so reviewers cannot start without the checklist in front of them.
What does a good security-sensitive code review check?
Input validation at trust boundaries, authentication on new endpoints, authorization on resource access, secrets not committed or logged, dependency changes reviewed for CVEs, and any cryptography reviewed by someone other than the author. Tag the review ticket as security-sensitive so the checklist surfaces those items.
Automate the sub-tasks with STM
STM Issue Templates saves the sub-task list above as a reusable template and creates them on every new issue of this type - via an Executor on issue creation, on status transition, or triggered manually from the issue's "Create bulk sub-tasks" menu. STM does not change the parent issue's create screen (that's a Jira project-settings job) but it removes the manual work of creating the sub-tasks every time.
Try STM on the Atlassian Marketplace ↗ See how STM templates are built →