@@ -7,6 +7,7 @@ redirect_from:
   - /github/authenticating-to-github/authorizing-a-personal-access-token-for-use-with-saml-single-sign-on
   - /github/authenticating-to-github/authenticating-with-saml-single-sign-on/authorizing-a-personal-access-token-for-use-with-saml-single-sign-on
   - /authentication/authenticating-with-saml-single-sign-on/authorizing-a-personal-access-token-for-use-with-saml-single-sign-on
+  - /authentication/authenticating-with-single-sign-on/authorizing-credentials-for-single-sign-on-with-a-github-app
 versions:
   ghec: '*'
 shortTitle: '{% data variables.product.pat_generic_caps %} with SSO'
@@ -19,10 +20,6 @@ You must authorize your {% data variables.product.pat_v1 %} after creation befor
 
 {% data reusables.saml.authorized-creds-info %}
 
-Enterprise administrators can use a {% data variables.product.prodname_github_app %} to authorize credentials for multiple organizations. See [AUTOTITLE](/authentication/authenticating-with-single-sign-on/authorizing-credentials-for-single-sign-on-with-a-github-app).
-
-## Authorizing a {% data variables.product.pat_v1 %}
-
 {% data reusables.user-settings.access_settings %}
 {% data reusables.user-settings.developer_settings %}
 {% data reusables.user-settings.personal_access_tokens %}
 
@@ -13,7 +13,6 @@ children:
   - /about-authentication-with-single-sign-on
   - /authorizing-an-ssh-key-for-use-with-single-sign-on
   - /authorizing-a-personal-access-token-for-use-with-single-sign-on
-  - /authorizing-credentials-for-single-sign-on-with-a-github-app
   - /authorizing-an-app-for-single-sign-on
   - /viewing-and-managing-your-active-sso-sessions
 shortTitle: Authenticate with SSO
 
@@ -8,7 +8,7 @@ redirect_from:
   - /enterprise-onboarding/feature-enhancements/about-code-security-for-your-enterprise
   - /enterprise-onboarding/feature-enhancements/about-enterprise-security
 introLinks:
-  overview: '{% ifversion ghes %}/code-security/getting-started/github-security-features{% endif %}'
+  overview: '/code-security/getting-started/github-security-features'
   generate_secret_risk_assessment_report_for_free: '{% ifversion secret-risk-assessment %}https://github.com/get_started?with=risk-assessment{% endif %}'
 layout: discovery-landing
 contentType: landing
 
@@ -27,8 +27,8 @@ These session limits are **soft limits**. If a response is in progress when the
 
 How the limit is set and applied depends on whether you are in an interactive session or running the CLI programmatically.
 
-> [!TIP]
-> {% data variables.product.prodname_ai_credit_singular %} session limits work best when set to > 30 {% data variables.product.prodname_ai_credits_short %} as most model calls will cost more than 20 {% data variables.product.prodname_ai_credits_short %}.
+> [!NOTE]
+> {% data variables.product.prodname_ai_credit_singular %} session limits must be set to at least 30 {% data variables.product.prodname_ai_credits_short %}.
 
 ### Setting a limit within an interactive session
 
 
@@ -16,9 +16,11 @@ docsTeamMetrics:
 
 ## Steer the conversation while {% data variables.product.prodname_copilot_short %} is thinking
 
-While {% data variables.product.prodname_copilot_short %} is working on a task, you can enter a new prompt at any time. Any input you send while {% data variables.product.prodname_copilot_short %} is thinking is treated as steering and is considered in the context of the current task.
+While {% data variables.product.prodname_copilot_short %} is working on a task, you can enter a new prompt at any time. By default, a plain prompt you send while {% data variables.product.prodname_copilot_short %} is thinking is treated as steering and is considered in the context of the current task.
 
-There is no separate instruction queue. To provide additional instructions, enter another prompt while {% data variables.product.prodname_copilot_short %} is running. {% data variables.product.prodname_copilot_short %} processes each message in order as part of the active task.
+## Queue a prompt to be processed next
+
+You can also queue a message instead of steering with it, by pressing <kbd>Ctrl</kbd>+<kbd>Enter</kbd> (or <kbd>Ctrl</kbd>+<kbd>Q</kbd>) instead of <kbd>Enter</kbd>. A queued message waits until the current task finishes, then runs as the next turn, instead of being folded into the task that's in progress. For more information about queued prompts, see [AUTOTITLE](/copilot/concepts/agents/copilot-cli/cancel-and-roll-back).
 
 Steering lets you:
 
 
@@ -51,7 +51,7 @@ A `copilot-setup-steps.yml` file looks like a normal {% data variables.product.p
 
 Here is a simple example of a `copilot-setup-steps.yml` file for a TypeScript project that clones the project, installs Node.js and downloads and caches the project's dependencies. You should customize this to fit your own project, including its language(s), its dependencies, and the workflow triggers you need. For example, you wouldn't typically run on both `push` and `pull_request`.
 
-```yaml copy
+```yaml
 name: "Copilot Setup Steps"
 
 # Automatically run the setup steps when they are changed to allow for easy validation, and
 
@@ -79,7 +79,7 @@ Creating this file is optional but is a good idea if you use {% data variables.c
 
    <!-- markdownlint-disable -->
    ```text copy
-   Analyze this repository to understand the dependencies that need to be installed on the development environment to work on the code in this repository. Using this information, and the details about the `copilot-setup-steps.yml` file that are given in https://docs.github.com/copilot/how-tos/use-copilot-agents/cloud-agent/customize-the-agent-environment, add a `.github/workflows/copilot-setup-steps.yml` to this repository. This Actions workflow file should install, in the development environment for {% data variables.copilot.copilot_cloud_agent %}, all of the dependencies necessary to work on the code in this repository. Make sure that the workflow job is named `copilot-setup-steps`.
+   Analyze this repository to understand the dependencies that need to be installed on the development environment to work on the code in this repository. Using this information, and the details about the `copilot-setup-steps.yml` file that are given in https://docs.github.com/copilot/how-tos/use-copilot-agents/cloud-agent/customize-the-agent-environment, add a `.github/workflows/copilot-setup-steps.yml` to this repository. This Actions workflow file should install, in the development environment for {% data variables.copilot.copilot_cloud_agent %}, all of the dependencies necessary to work on the code in this repository. Make sure that the workflow job is named `copilot-setup-steps`, and that the workflow includes a `workflow_dispatch` trigger so that it can be run manually. Choose any other triggers to suit this repository; there's no need to run on both `push` and `pull_request`.
    ```
    <!-- markdownlint-enable -->
 
@@ -97,12 +97,6 @@ Creating this file is optional but is a good idea if you use {% data variables.c
    ```yaml
    on:
      workflow_dispatch:
-     push:
-       paths:
-         - .github/workflows/copilot-setup-steps.yml
-     pull_request:
-       paths:
-         - .github/workflows/copilot-setup-steps.yml
 
    jobs:
      copilot-setup-steps:
 
@@ -69,7 +69,7 @@ If your instance has subdomain isolation enabled:
 {% endif %}
 
 ```shell
-//{% ifversion fpt or ghec %}npm.pkg.github.com{% else %}npm.HOSTNAME/{% endif %}/:_authToken=TOKEN
+//{% ifversion fpt or ghec %}npm.pkg.github.com{% else %}npm.HOSTNAME{% endif %}/:_authToken=TOKEN
 ```
 
 {% ifversion ghes %}
@@ -161,7 +161,7 @@ You can use `publishConfig` element in the `package.json` file to specify the re
 
    ```shell
    "publishConfig": {
-     "registry": "https://{% ifversion fpt or ghec %}npm.pkg.github.com{% else %}npm. HOSTNAME/{% endif %}"
+     "registry": "https://{% ifversion fpt or ghec %}npm.pkg.github.com{% else %}npm.HOSTNAME/{% endif %}"
    },
    ```
 
@@ -225,23 +225,23 @@ You also need to add the `.npmrc` file to your project so that all requests to i
 
 ### Installing packages from other organizations
 
-By default, you can only use {% data variables.product.prodname_registry %} packages from one organization. If you'd like to route package requests to multiple organizations and users, you can add additional lines to your `.npmrc` file, replacing {% ifversion ghes %}`HOSTNAME` with the host name of {% data variables.location.product_location %} and {% endif %}`NAMESPACE` with the name of the personal account or organization {% ifversion packages-npm-v2 %}to which the package is scoped{% else %}that owns the repository containing the project{% endif %}.
+By default, you can only use {% data variables.product.prodname_registry %} packages from one organization. If you'd like to route package requests to multiple organizations and users, you can add additional lines to your `.npmrc` file, replacing {% ifversion ghes %}`HOSTNAME` with the host name of {% data variables.location.product_location %} and {% endif %}`NAMESPACE1` and `NAMESPACE2` with the names of the personal accounts or organizations {% ifversion packages-npm-v2 %}to which the packages are scoped{% else %}that own the repositories containing the projects{% endif %}.
 
 {% ifversion ghes %}
 If your instance has subdomain isolation enabled:
 {% endif %}
 
 ```shell
-@NAMESPACE:registry=https://{% ifversion fpt or ghec %}npm.pkg.github.com{% else %}npm.HOSTNAME{% endif %}
-@NAMESPACE:registry=https://{% ifversion fpt or ghec %}npm.pkg.github.com{% else %}npm.HOSTNAME{% endif %}
+@NAMESPACE1:registry=https://{% ifversion fpt or ghec %}npm.pkg.github.com{% else %}npm.HOSTNAME{% endif %}
+@NAMESPACE2:registry=https://{% ifversion fpt or ghec %}npm.pkg.github.com{% else %}npm.HOSTNAME{% endif %}
 ```
 
 {% ifversion ghes %}
 If your instance has subdomain isolation disabled:
 
 ```shell
-@NAMESPACE:registry=https://HOSTNAME/_registry/npm
-@NAMESPACE:registry=https://HOSTNAME/_registry/npm
+@NAMESPACE1:registry=https://HOSTNAME/_registry/npm
+@NAMESPACE2:registry=https://HOSTNAME/_registry/npm
 ```
 
 {% endif %}
 
@@ -50,6 +50,25 @@ Use the pull request status checks box to identify which commit must pass.
 
 See [AUTOTITLE](/rest/pulls/pulls#get-a-pull-request).
 
+## Checks from some workflow jobs are not evaluated
+
+A {% data variables.product.prodname_actions %} workflow run can report checks that do not appear in a pull request's checks section or satisfy required status checks in a branch ruleset. For checks created by workflow jobs to be evaluated for a pull request, the workflow run must be triggered by one of these events:
+
+* `push`
+* `pull_request`
+* `pull_request_review`
+* `pull_request_target`
+* `deployment`
+* `deployment_status`
+
+For example, if a workflow is triggered by `workflow_dispatch` on a pull request's head branch, checks reported by its jobs do not appear in the pull request's checks section. Even if the checks pass for the head commit, they do not satisfy a required status check in a branch ruleset.
+
+Check the event that triggered the workflow run. If the workflow uses another event, update its `on` configuration to use an eligible event appropriate for your workflow, such as `pull_request`. See [AUTOTITLE](/actions/reference/workflows-and-actions/events-that-trigger-workflows).
+
+This restriction applies only to checks created by workflow jobs, not to checks created by an external {% data variables.product.prodname_github_app %}.
+
+Merge queues require the separate `merge_group` event. See [Status checks with {% data variables.product.prodname_actions %} and a Merge queue](#status-checks-with-github-actions-and-a-merge-queue).
+
 ## Handling skipped but required checks
 
 | Cause | Result | How to fix or check |