diff --git a/docs/triage.md b/docs/triage.md
index 9d54fcfe7..7f8bbbd7b 100644
--- a/docs/triage.md
+++ b/docs/triage.md
@@ -1,27 +1,51 @@
 # Triage role
 
-As we get more issues and pull requests opened on the GitHub CLI, we've decided on a weekly rotation
-triage role. The initial expectation is that the person in the role for the week spends no more than
-2 hours a day on this work; we can refine that as needed.
+As we get more issues and pull requests opened on the GitHub CLI, we've decided on a weekly rotation triage role as defined by our First Responder (FR) rotation. The primary responsibility of the FR during that week is to triage incoming issues from the Open Source community, as defined below. An issue is considered "triaged" when the `needs-triage` label is removed.
 
-## Expectations for incoming issues
+## Expectations for triaging incoming issues
 
-Review and label [open issues missing either the `enhancement`, `bug`, or `docs` label](https://github.com/cli/cli/issues?q=is%3Aopen+is%3Aissue+-label%3Abug%2Cenhancement%2Cdocs+).
+Review and label [open issues missing either the `enhancement`, `bug`, or `docs` label](https://github.com/cli/cli/issues?q=is%3Aopen+is%3Aissue+-label%3Abug%2Cenhancement%2Cdocs+) and the label(s) corresponding to the command space prefixed with `gh-`, such as `gh-pr` for the `gh pr` command set, or `gh-extension` for the `gh extension` command set. 
 
-Any issue that is accepted to be done as either an `enhancement`, `bug`, or `docs` requires explicit Acceptance Criteria in a comment on the issue before `needs-triage` label is removed.
+Then, engage with the issue and community with the goal to remove the `needs-triage` label from the issue. The heuristics for triaging the different issue types are as follow:
 
-To be considered triaged, `enhancement` issues require at least one of the following additional labels:
+### Bugs
 
-- `core`: reserved for the core CLI team
-- `help wanted`: signal that we are accepting contributions for this
-- `discuss`: add to our team's queue to discuss during a sync
-- `needs-investigation`: work that requires a mystery be solved by the core team before it can move forward
-- `needs-user-input`: we need more information from our users before the task can move forward
+To be considered triaged, `bug` issues require the following:
 
-To be considered triaged, `bug` issues require a severity label: one of `p1`, `p2`, or `p3`, which are defined as follows:
- - `p1`: Affects a large population and inhibits work
- - `p2`: Affects more than a few users but doesn't prevent core functions
- - `p3`: Affects a small number of users or is largely cosmetic
+- A severity label `p1`, `p2`, and `p3`
+- Clearly defined Acceptance Criteria, added to the Issue as a standalone comment (see [example](https://github.com/cli/cli/issues/9469#issuecomment-2292315743))
+
+#### Bug severities
+
+| Severity | Description |
+| - | - |
+| `p1` | Affects a large population and inhibits work |
+| `p2` | Affects more than a few users but doesn't prevent core functions |
+| `p3` | Affects a small number of users or is largely cosmetic |
+
+### Enhancements
+
+To be considered triaged, `enhancement` issues require either
+
+- Clearly defined Acceptance Criteria as above 
+- The `needs-investigation` or `needs-design` label with a clearly defined set of open questions to be investigated.
+
+### Docs
+
+To be considered triaged, `docs` issues require clearly defined Acceptance Criteria, as defined above 
+
+## Additional triaging processes and labels
+
+Before removing the `needs-triage` label, consider adding any of the following labels below.
+
+| Label | Description |
+| - | - |
+| `discuss` | Some issues require discussion with the internal team. Adding this label will automatically open up an internal discussion with the team to facilitate this discussion. |
+| `core` |  Defines what we would like to do internally. We tend to lean towards `help wanted` by default, and adding `core` should be reserved for trickier issues or implementations we have strong opinions/preferences about. |
+| `good first issue` | Used to denote when an issue may be a good candidate for a first-time contributor to the CLI. These are usually small and well defined issues. |
+| `help wanted` |  Defines what we feel the community could solve should they care to contribute, respectively. We tend to lean towards `help wanted` by default, and adding `core` should be reserved for trickier issues or implementations we have strong opinions/preferences about. |
+| `invalid` | Added to spam and abusive issues. |
+| `needs-user-input` | After asking any contributors for more information, add this label so it is clear that the issue has been responded to and we are waiting on the user. |
 
 ## Expectations for community pull requests
 
@@ -29,36 +53,13 @@ All incoming pull requests are assigned to one of the engineers for review on a
 The person in a triage role for a week could take a glance at these pull requests, mostly to see whether
 the changeset is feasible and to allow the associated CI run for new contributors.
 
-## Issue triage flowchart
+## Spam and abuse
 
-- can this be closed outright?
-  - e.g. spam/junk
-  - add the `invalid` label
-  - close without comment
-- do we not want to do it?
-  - e.g. we have already discussed not wanting to do or it's a duplicate issue
-  - add the appropriate label (e.g. `duplicate`)
-  - comment and close
-- do we want external contribution for this?
-  - e.g. the task is relatively straightforward, but the core team does not have the bandwidth to take it on
-  - ensure that the thread contains all the context necessary for someone new to pick this up
-  - add the `help wanted` label
-  - consider adding `good first issue` label
-- do we want external design contribution for this?
-  - e.g. the task is worthwhile, but needs design work to flesh out the details before implementation and the core team does not have the bandwidth to take it on
-  - ensure that the thread contains all the context necessary for someone new to pick this up
-  - add both the `help wanted` and `needs-design` labels
-- do we want to do it?
-  - add the `core` label
-  - comment acknowledging that
-- is it intriguing, but requires discussion?
-  - Add the `discuss` label
-  - Add the `needs-investigation` label if engineering research is required before action can be taken
-- does it need more info from the issue author?
-  - ask the user for details
-  - add the `needs-user-input` label
-- is it a usage/support question?
-  - Convert the Issue to a Discussion
+The primary goal of triaging spam and abuse is to remove distracting and offensive content from our community.
+
+We get a lot of spam. Whenever you determine an issue as spam, add the `invalid` label and close it as "won't do". For spammy comments, simply mark them as spam using GitHub's built-in spam feature.
+
+Abusive contributions are defined by our [Code of Conduct](../.github/CODE-OF-CONDUCT.md). Any contribution you determine abusive should be removed. Repeat offenses or particularly offensive abuse should be reported using GitHub's reporting features and the user blocked. If an entire issue is abusive, label it as `invalid` and close as "won't do".
 
 ## Weekly PR audit