11.3 Saved Replies and Assignees

Key Takeaways

  • Saved replies are personal-account canned responses (maximum 100) that you insert into issues, pull requests, and discussions across every repository and organization you use.
  • GitHub includes a built-in Duplicate issue saved reply for marking duplicates; you create additional replies under Settings → Saved replies and can edit them in the comment box before posting.
  • Issues and pull requests support up to 10 assignees; assignment is two-way with Projects, so grouping a view by assignee and dragging a card reassigns the issue.
  • Assignees mean who is doing the work; pull request reviewers mean who is reviewing the diff; CODEOWNERS automatically requests reviews for owned paths and is not an assignee list.
  • Assigning or mentioning someone on a draft issue does not notify them until you convert the draft into a repository issue.
Last updated: August 2026

Why GH-900 pairs saved replies with assignees

Domain 5's third skill is identify how to use saved replies and assignees to streamline communication. After you can describe Projects and configure fields, the exam asks how teams talk and hand off work without reinventing the same comment or leaving issues unowned. GitHub's docs treat these as issue and pull request features that Projects surfaces, not as project-only widgets. Saved replies live on your personal account. Assignees live on the issue or pull request and sync into project views.

That pairing is deliberate. A board with no owners is a picture. A triage comment you retype fifty times is wasted time. GH-900 expects you to name the built-in features that fix both: saved replies for repeated writing, assignees (including multi-assignee and drag-to-reassign) for ownership.

Saved replies: user-level canned responses

A saved reply is a reusable comment for issues and pull requests. GitHub's About saved replies page adds two facts candidates miss: once created, a saved reply also works in discussions, and saved replies are tied to your personal account. Create them once; use them in every repository and every organization you belong to. They are not org templates, not repository files, and not CODEOWNERS entries.

Limits and built-ins:

  • Maximum 100 saved replies per user. At the cap, delete unused replies or edit existing ones—GitHub does not give you a 101st slot.
  • GitHub provides a Duplicate issue saved reply that marks an issue as a duplicate and tracks it with a similar issue. You do not have to author that one from scratch.
  • Body text supports Markdown. Settings → Saved replies (under Code, planning, and automation): title, Write field, Preview, Add saved reply.

To insert a reply, open the comment box on an issue, pull request, or discussion, click the reply-arrow control above the field, pick a title (you can type to filter), optionally edit the pasted text, then comment. Keyboard shortcuts can autofill the box. The saved reply can be the entire comment or a starting paragraph you customize—GH-900 will offer “saved replies cannot be edited after insert” as a wrong answer.

What saved replies are not:

  • Not organization-wide policy. Your teammate does not see your replies unless they created their own.
  • Not issue templates. Templates pre-fill a new issue form from .github/ISSUE_TEMPLATE. Saved replies pre-fill a comment you are about to post.
  • Not project status updates. Status updates (On track / At risk) belong to the project side panel (section 11.4).
  • Not Actions bots. A workflow can comment with GITHUB_TOKEN; that is automation, not a saved reply.

Typical exam stories: “maintainers keep pasting the same reproduction checklist,” “mark duplicates without hunting the syntax,” “welcome first-time contributors with a short Markdown note.” All three are saved replies. “Require review from the docs team when README changes” is CODEOWNERS, not a saved reply.

Assignees: who is doing the work

Assignees clarify who is working on an issue or pull request. GitHub's Assigning issues and pull requests page is the source for GH-900 numbers and who is eligible.

Both issues and pull requests support up to 10 assignees. You can assign yourself, anyone who has commented, anyone with write permission on the repository, and organization members with read permission on the repository. You assign from the issue sidebar, from the list view Assign control (bulk), from the create-issue dialog inside a project, or—this is the Projects-specific gesture GitHub calls out in About Projects—by grouping the project by assignee and dragging items into another person's group. Because of two-way sync, that drag updates the issue. You can also assign Copilot on products that support the cloud agent; GH-900 may mention it as an assignee option, not as a replacement for human reviewers.

Draft issues can list assignees as project metadata, but users are not notified of assignment or @mentions on a draft until you convert it to an issue. If the scenario is “make sure Maya is notified she owns this,” convert first, then assign (or assign after conversion). Parking Maya’s name on a draft is a plan, not a notification.

In project views, Assignee is built-in metadata. Group a table or board by assignee to see load. Slice by assignee while columns stay on Status. Filter assignee:@me. Auto-add workflows can target assignee:username or no:assignee so unowned issues land on a triage project. None of those views invent a second ownership model: they display the same assignee list that the issue sidebar shows.

Ten is a hard cap. “Assign the whole 12-person squad” is wrong; split the issue, use a team as a @mention in the body, or use labels such as team-payments for routing—teams are not assignees unless you pick individual members (up to ten). Organization teams can be CODEOWNERS; that still does not assign the issue.

Loading diagram...
Assignees, reviewers, and CODEOWNERS are different jobs

Do not confuse assignees with reviewers or CODEOWNERS

This distinction is the D5.3 trap cluster. All three put a person's name on a pull request. Only one means “you are doing the work.”

RoleObject it attaches toWhat GitHub doesTypical GH-900 cue
AssigneeIssue or pull request (also shown in Projects)Names who is implementing or driving the item; up to 10; two-way with project views“Who owns this bug?” “Drag the card to Priya's column”
ReviewerPull requestRequests that a person review the diff; approvals can be required by rulesets or branch protection“Ask Jordan to review this PR”
CODEOWNERS.github/CODEOWNERS, repo root, or docs/CODEOWNERS on the base branchAutomatically requests review when a pull request touches owned paths; owners need write access; optional “require review from Code Owners”“Docs team must review Markdown changes”

Assignees do not request a review. You can be assigned to a pull request because you are landing the feature and still need a different person as reviewer. Reviewers do not become assignees when they approve. CODEOWNERS never assigns the issue. Code owners are not notified on draft pull requests until the PR is marked ready for review. Required code-owner review is satisfied by any listed owner of the matching path, not all of them. A CODEOWNERS file over 3 MB is ignored.

Saved replies do not assign anyone. A reply can ask someone to self-assign (/assign is not a GitHub-native slash command in the way some chat tools are—you use the sidebar or project drag). Do not pick “create a saved reply named CODEOWNERS” as the way to request path-based reviews.

You can still @mention a team in a saved reply to notify them. Notification is not assignment and is not a review request. GH-900 will stack those verbs: assign, request review, notify, label. Match the verb to the feature.

Exam scenarios and traps

  • “We paste the same ‘needs reproduction steps’ comment twenty times a day” → saved reply on your personal account, usable in every repo.
  • “Cap of canned responses” → 100 per user. There is no org-wide pool of 100.
  • “Two people share implementation, eight more consult” → you can name ten assignees; the rest should be reviewers, mentions, or a label, not assignee slot 11.
  • “Move this issue from Alex's board column to Sam's” → group the project by assignee and drag; the issue sidebar updates.
  • “Notify the owner of a brainstorm that is not an issue yet” → convert the draft issue first; draft assignment is silent.
  • “Automatically request the security team when /auth files change” → CODEOWNERS, not assignees and not a saved reply.
  • “Who should review this pull request?” → reviewers (and maybe CODEOWNERS). Assignment answers who is writing the code.
  • Saved replies work in discussions too; they are not issue-only.
  • Issue templates are not saved replies. Templates fire on create; replies fire on comment.
  • Copilot as an assignee is an agent session, not a CODEOWNERS replacement.

If you can hear “streamline communication” and pick saved replies for repeated text, assignees for ownership (including project drag), and a different product for review routing, you have D5.3. The last Domain 5 skill is how the same project proves progress: insights charts and status updates.

Test Your Knowledge

Where do GitHub saved replies live, and where can you use them?

A
B
C
D
Test Your Knowledge

A project board is grouped by assignee. What happens when you drag an issue from one assignee group into another?

A
B
C
D
Test Your Knowledge

A pull request changes files under /docs. The team wants the docs team to review the diff, while the engineer who is implementing the change stays listed as the person doing the work. Which combination is correct?

A
B
C
D