6.3 Linking PRs, Templates, Filters, and Assignments

Why linking, templates, filters, and assignments are one skill

The January 2026 GH-900 outline states Domain 3.2 as a single bullet: explain how to link pull requests to issues and manage templates, filters, and assignments. That is not four trivia piles. It is the operating system around issues and PRs. Linking shows that a fix is in progress and can close the work item. Templates make incoming issues and PRs complete. Filters (search qualifiers) find the right records. Assignments—and the neighboring reviewer and CODEOWNERS mechanisms—answer who is doing the work versus who must approve the change.

GitHub's Linking a pull request to an issue article is the linking source of truth.

Linking pull requests to issues

You can link automatically with keywords or manually from the Development sidebar. Linked work tells collaborators "someone is implementing this" and, for keyword links into the default branch, closes the issue when the pull request (or a closing commit) merges.

Closing keywords

Put a supported keyword in the pull request description (the summary the author writes at create time) or in a commit message:

• close / closes / closed
• fix / fixes / fixed
• resolve / resolves / resolved

Keywords may use a colon and any capitalization: Closes: #10, CLOSES #10. Using a keyword to reference a pull request comment from another pull request links those PRs; merging the referencing PR also closes the referenced PR.

Default-branch rule (highest-yield trap): keywords are interpreted only when the pull request targets the repository default branch. Target any other branch and GitHub ignores the keywords: no Development link from the keyword, and merging does not close the issues.

Commit-message keywords close the issue when that commit reaches the default branch, but the pull request that happens to contain the commit is not listed as a linked pull request. If the exam asks how to make the PR show up in the issue's Development section, a description keyword or a manual sidebar link is the answer, not a buried commit message.

To drop a keyword link, edit the pull request description and remove the keyword. Keyword links cannot be cleared from the sidebar alone.

Development sidebar (manual linking)

Anyone with write permissions can link manually.

From a pull request: open the PR → right sidebar Development → choose the issue. You can manually link up to ten issues per pull request, and for this direction the issue and pull request must be in the same repository.

From an issue: open the issue → Development → pick the repository → pick a pull request or a branch → Apply. From the issue side, the linked PR or branch may live in a different repository. GitHub remembers the last repository you picked.

Manual links can be manually unlinked. That is the difference from keyword links. Manual linking also works when you are merging into a non-default branch and still want the issue to show that work is in progress—knowing that auto-close will not fire until a default-branch merge with a keyword (or a later default-branch PR).

You can search linked work with linked:pr (issues that have a closing-reference PR) and linked:issue (PRs linked to an issue they may close). Negate with -linked:pr to find issues nobody is implementing.

Templates: issues and pull requests

Issue and pull request templates standardize what contributors submit. They must live on the default branch; a template committed only to a feature branch is invisible in the chooser.

Issue templates

Issue templates sit in the hidden .github/ISSUE_TEMPLATE directory.

• Markdown templates use a .md extension (names are not case sensitive) with YAML front matter keys name: and about: so they appear in the community profile checklist.
• Issue forms use a .yml extension with name: and description:. Forms render web fields (the GitHub form schema) and convert submitted values into a Markdown issue body. You can mark fields required, set default labels, and set default assignees.
• config.yml in .github/ISSUE_TEMPLATE customizes the template chooser (for example, whether blank issues are allowed, or extra contact links).

The template builder can commit straight to the default branch or open a pull request. Contributors then pick "Bug report" versus "Feature request" instead of a blank textarea. Security vulnerability reporting is a SECURITY.md policy, not an ordinary issue template—send reporters to the security policy instead of a public bug form when the topic is a vulnerability.

Pull request templates

A pull request template pre-fills the PR body. Store it on the default branch in one of three places: the repository root, the docs/ folder, or the hidden .github/ directory. Filenames are not case sensitive and may use .md or .txt. A common name is PULL_REQUEST_TEMPLATE.md. Unlike issue templates, PR templates are not required to live under ISSUE_TEMPLATE.

You can also set organization- or personal-account default community health files, including templates, that apply when a repository has not defined its own.

Exam traps: putting bug.md in the repo root will not drive the issue chooser. Putting PULL_REQUEST_TEMPLATE.md only under .github/ISSUE_TEMPLATE/ is the wrong folder. Templates on my-feature are unused until they reach the default branch.

Filters and search qualifiers

The Issues and Pull requests tabs have UI filters. Under the hood they are search qualifiers you can type anywhere GitHub search runs. Search is not case sensitive. Quote multi-word values. Prefix - to exclude (except some missing-metadata forms).

Qualifiers GH-900 is most likely to show:

involves:USERNAME is a logical OR of author, assignee, mentions, and commenter. user-review-requested:@me finds PRs where you personally were asked to review, as opposed to a team request.

A realistic filter on an exam might read: is:issue is:open label:bug -linked:pr assignee:@me—open bugs assigned to you that still have no implementing pull request.

Assignees vs reviewers vs CODEOWNERS

These three mechanisms sit next to each other on a pull request and are the most common Domain 3 mix-up.

Assignees (issues and PRs, maximum 10) communicate who is doing the work. Eligible people: yourself, commenters, users with write access, and org members with read access. Assigning does not request a review and does not grant merge rights. Filter: assignee:.

Reviewers are people or teams requested to review a pull request. They submit Comment, Approve, or Request changes. Read access is enough to perform a review; write (or triage, to assign a reviewer) is required to request one. Reviewers appear in the Reviewers sidebar, not the Assignees sidebar. Filter: review-requested:, reviewed-by:.

CODEOWNERS is a file named CODEOWNERS in .github/, the repository root, or docs/ (GitHub searches in that order). Patterns map paths to @user or @org/team. Those people or teams must have write permission (teams must be visible and have write even if members already have write elsewhere). When a non-draft pull request touches a matching path, GitHub automatically requests those owners. The CODEOWNERS file that matters is the one on the base branch of the pull request. Owners are not auto-requested on drafts; marking ready fires the requests. Branch protection can require a code-owner approval; if several owners match one pattern, any one of them can satisfy that requirement. CODEOWNERS files must stay under 3 MB. Invalid lines are skipped. You cannot use gitignore-style ! negation, character ranges [ ], or escaped # patterns.

A person can be all three at once. The exam still wants you to pick the mechanism: assign for ownership of the ticket, request review for feedback, CODEOWNERS for path-based automatic review.

Exam scenarios and traps

• Keywords on a PR into gh-pages when main is default: no auto-close.
• "Show on the issue that a branch is in progress, even before a PR exists" → issue Development sidebar can link a branch, not only a PR.
• Ten-issue cap is on manual PR→issue links. Do not invent a 100-issue sidebar.
• Write permission for sidebar linking; you cannot manually link with comment-only access.
• Issue forms are .yml in .github/ISSUE_TEMPLATE. PR templates are not required to live there.
• review-requested: stops matching after that person reviews. review-involves: keeps them.
• CODEOWNERS does not assign the issue. It requests PR review.
• Draft + CODEOWNERS: no auto-request until ready.
• assignee:@me is:pr review:changes_requested is how you find your PRs that are blocked on feedback—not label:reviewer.

Wire the four tools together the way GitHub designed them: a template produces a complete issue, an assignee owns it, a filter finds it, a pull request links it in Development, keywords close it on default-branch merge, and CODEOWNERS plus reviewers guard the merge. That is Domain 3.2.