Repo sync

CHANGELOG.md

@@ -1,5 +1,27 @@
 # Docs changelog
 
+**23 April 2026**
+
+We added documentation for the new `gh skill` command (public preview), which you can use to discover, install, update, and publish agent skills directly from GitHub CLI.
+
+See [Adding agent skills for GitHub Copilot](https://docs.github.com/en/copilot/how-tos/use-copilot-agents/cloud-agent/add-skills#managing-skills-with-github-cli).
+
+<hr>
+
+**21 April 2026**
+
+We reorganized the Copilot how-tos for GitHub.com into a new [Copilot on GitHub](https://docs.github.com/en/copilot/how-tos/copilot-on-github) category, structured around five task-based map topics that follow the way people actually use Copilot on GitHub:
+
+* [Set up Copilot](https://docs.github.com/en/copilot/how-tos/copilot-on-github/set-up-copilot): Enable Copilot, configure AI models, and set up code review.
+* [Chat with Copilot](https://docs.github.com/en/copilot/how-tos/copilot-on-github/chat-with-copilot): A streamlined [quickstart](https://docs.github.com/en/copilot/how-tos/copilot-on-github/chat-with-copilot/get-started-with-chat) with example prompts, plus focused articles for chat on GitHub and chat on GitHub Mobile.
+* [Customize Copilot](https://docs.github.com/en/copilot/how-tos/copilot-on-github/customize-copilot): Add custom instructions, customize coding agents (MCP, hooks, skills, firewall), and curate context with Spaces and content exclusions. A new [quickstart](https://docs.github.com/en/copilot/how-tos/copilot-on-github/customize-copilot/customize-copilot-overview) walks through a scenario that ties these features together.
+* [Copilot for GitHub tasks](https://docs.github.com/en/copilot/how-tos/copilot-on-github/copilot-for-github-tasks): Create issues, generate PR summaries, and use the GitHub MCP server from the web UI.
+* [Use Copilot agents](https://docs.github.com/en/copilot/how-tos/copilot-on-github/use-copilot-agents) — Six articles following the agent workflow end-to-end: kick off a task, research and iterate, monitor sessions, request code review, and review output. Includes a new [hands-on quickstart](https://docs.github.com/en/copilot/how-tos/copilot-on-github/use-copilot-agents/overview) you can complete in about ten minutes.
+
+Every article was revised for plain language, scannable structure, and value-focused intros. Web-specific content was separated from IDE and CLI content so you see only what's relevant to GitHub.com.
+
+<hr>
+
 **21 April 2026**
 
 We recently published two new guides for organizations adopting Copilot cloud agent.

content/actions/how-tos/manage-runners/use-actions-runner-controller/deploy-runner-scale-sets.md

@@ -35,6 +35,9 @@ You can deploy runner scale sets with ARC's Helm charts or by deploying the nece
    * Update the `NAMESPACE` value to the location you want the runner pods to be created.
    * Set the `GITHUB_CONFIG_URL` value to the URL of your repository, organization, or enterprise. This is the entity that the runners will belong to.
    * This example command installs the latest version of the Helm chart. To install a specific version, you can pass the `--version` argument with the version of the chart you want to install. You can find the list of releases in the [`actions-runner-controller`](https://github.com/actions/actions-runner-controller/pkgs/container/actions-runner-controller-charts%2Fgha-runner-scale-set) repository.
+
+   > [!NOTE]
+   > This example uses a {% data variables.product.pat_generic %} to keep the initial setup short. If you are registering runners at the repository or organization level, we recommend authenticating with a {% data variables.product.prodname_github_app %} instead. For more information, see [AUTOTITLE](/actions/hosting-your-own-runners/managing-self-hosted-runners-with-actions-runner-controller/authenticating-to-the-github-api). Enterprise-level runners require {% data variables.product.pat_v1 %} authentication.
     {% ifversion not ghes %}
 
      ```bash copy

content/actions/how-tos/secure-your-work/security-harden-deployments/oidc-in-aws.md

@@ -70,17 +70,6 @@ Edit the trust policy, adding the `sub` field to the validation conditions. For
 }
 ```
 
-For repositories created after June 18, 2026, or that have opted in to immutable subject claims, the `sub` claim includes immutable owner and repository IDs (not available on {% data variables.product.prodname_ghe_server %}). Make sure your trust policy matches the format your repository uses. For more information, see [AUTOTITLE](/actions/reference/openid-connect-reference#immutable-subject-claims).
-
-```json copy
-"Condition": {
-  "StringEquals": {
-    "token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
-    "token.actions.githubusercontent.com:sub": "repo:octo-org-123456/octo-repo-456789:ref:refs/heads/octo-branch"
-  }
-}
-```
-
 If you use a workflow with an environment, the `sub` field must reference the environment name: `repo:ORG-NAME/REPO-NAME:environment:ENVIRONMENT-NAME`. For more information, see [AUTOTITLE](/actions/reference/openid-connect-reference#filtering-for-a-specific-environment).
 
 {% data reusables.actions.oidc-deployment-protection-rules %}

content/actions/how-tos/secure-your-work/security-harden-deployments/oidc-in-azure.md

@@ -32,8 +32,6 @@ This guide gives an overview of how to configure Azure to trust {% data variable
 
 {% data reusables.actions.oidc-on-ghecom %}
 
-For repositories created after June 18, 2026, and repository renames or transfers after that date, use an immutable default OIDC `sub` claim that includes owner and repository IDs (not available on {% data variables.product.prodname_ghe_server %}). Existing repositories keep the previous format unless they opt in. For more information, see [AUTOTITLE](/actions/reference/openid-connect-reference#immutable-subject-claims).
-
 {% ifversion ghes %}
 {% data reusables.actions.oidc-endpoints %}
   <!-- This note is indented to align with the above reusable. -->

content/actions/how-tos/secure-your-work/security-harden-deployments/oidc-in-google-cloud-platform.md

@@ -31,8 +31,6 @@ This guide gives an overview of how to configure GCP to trust {% data variables.
 
 {% data reusables.actions.oidc-on-ghecom %}
 
-For repositories created after June 18, 2026, and repository renames or transfers after that date, use an immutable default OIDC `sub` claim that includes owner and repository IDs (not available on {% data variables.product.prodname_ghe_server %}). Existing repositories keep the previous format unless they opt in. For more information, see [AUTOTITLE](/actions/reference/openid-connect-reference#immutable-subject-claims).
-
 {% ifversion ghes %}
 {% data reusables.actions.oidc-endpoints %}
   <!-- This note is indented to align with the above reusable. -->

content/actions/reference/security/oidc.md

@@ -26,7 +26,7 @@ The OIDC token includes the following claims.
 | ----------- | -----| ---------------------- |
 | `aud`| Audience | By default, this is the URL of the repository owner, such as the organization that owns the repository. You can set a custom audience with a toolkit command: [`core.getIDToken(audience)`](https://www.npmjs.com/package/@actions/core/v/1.6.0) |
 | `iss`| Issuer | The issuer of the OIDC token: {% ifversion ghes %}`https://HOSTNAME/_services/token`{% else %}`https://token.actions.githubusercontent.com`{% endif %} |
-| `sub`| Subject | Defines the subject claim that is to be validated by the cloud provider. This setting is essential for making sure that access tokens are only allocated in a predictable way. For repositories using immutable subject claims, the `sub` format includes immutable owner and repository IDs (not available on {% data variables.product.prodname_ghe_server %}). |
+| `sub`| Subject | Defines the subject claim that is to be validated by the cloud provider. This setting is essential for making sure that access tokens are only allocated in a predictable way. |
 
 ### Additional standard JOSE header parameters and claims
 
@@ -163,22 +163,6 @@ You can configure a subject that includes metadata containing colons. In this ex
 
 {% endif %}
 
-## Immutable subject claims
-
-The OpenID Connect (OIDC) specification requires subject (`sub`) claims to be locally unique and never reassigned. Previously, the default `sub` format used only organization and repository names. If a namespace was recycled, a different owner could create the same subject value.
-
-To help prevent this scenario, repositories created after June 18, 2026 now use an immutable default subject format that includes both the owner ID and repository ID. This rollout does not include {% data variables.product.prodname_ghe_server %}.
-
-* Syntax: `repo:OWNER-ID/REPO-ID:ref:refs/heads/BRANCH`
-* Previous format example: `repo:octo-org/octo-repo:ref:refs/heads/main`
-* Immutable format example: `repo:octo-org-123456/octo-repo-456789:ref:refs/heads/main`
-
-The `-` separator is used between names and IDs because `-` cannot appear in {% data variables.product.github %} usernames or repository names.
-
-Repositories created before June 18, 2026 keep the previous format unless you opt in to immutable subject claims. You can opt in at the organization or repository level by using the OIDC settings UI or REST API.
-
-Repository renames and transfers after June 18, 2026 also move to the immutable subject format.
-
 ## Configuring the subject in your cloud provider
 
 To configure the subject in your cloud provider's trust relationship, you must add the subject string to its trust configuration. The following examples demonstrate how various cloud providers can accept the same `repo:octo-org/octo-repo:ref:refs/heads/demo-branch` subject in different ways:
@@ -190,15 +174,6 @@ To configure the subject in your cloud provider's trust relationship, you must a
 | Google Cloud Platform| `(assertion.sub=='repo:octo-org/octo-repo:ref:refs/heads/demo-branch')` |
 | HashiCorp Vault| `bound_subject="repo:octo-org/octo-repo:ref:refs/heads/demo-branch"` |
 
-For repositories created after June 18, 2026, or that have opted in to immutable subject claims, the `sub` claim includes `owner_id` and `repo_id` as shown in the immutable examples. Update your trust policies to match the format your repository uses. Immutable subject claims are not available on {% data variables.product.prodname_ghe_server %}.
-
-| Cloud provider | Immutable format example |
-| ------ | ----------- |
-| Amazon Web Services | `"token.actions.githubusercontent.com:sub": "repo:octo-org-123456/octo-repo-456789:ref:refs/heads/demo-branch"` |
-| Azure| `repo:octo-org-123456/octo-repo-456789:ref:refs/heads/demo-branch` |
-| Google Cloud Platform| `(assertion.sub=='repo:octo-org-123456/octo-repo#456789:ref:refs/heads/demo-branch')` |
-| HashiCorp Vault| `bound_subject="repo:octo-org-123456/octo-repo-456789:ref:refs/heads/demo-branch"` |
-
 For more information about configuring specific cloud providers, see the guides listed in [AUTOTITLE](/actions/how-tos/security-for-github-actions/security-hardening-your-deployments).
 
 ## Customizing the token claims
@@ -340,7 +315,6 @@ Customizing the claims results in a new format for the entire `sub` claim, which
 > [!NOTE]
 > The `sub` claim uses the shortened form `repo` (for example, `repo:ORG-NAME/REPO-NAME`) instead of `repository` to reference the repository. {% ifversion fpt or ghec or ghes > 3.15 %}
 > Any `:` within the context value will be replaced with `%3A`. {% endif %}
-> For repositories using immutable subject claims (not available on {% data variables.product.prodname_ghe_server %}), `owner_id` and `repo_id` are always included in the `repo` segment of the `sub` claim, even when you customize claims with `include_claim_keys`. You can't remove these IDs from the immutable format.
 
 The following example templates demonstrate various ways to customize the subject claim. To configure these settings on {% data variables.product.prodname_dotcom %}, admins use the REST API to specify a list of claims that must be included in the subject (`sub`) claim.
 

content/admin/data-residency/feature-overview-for-github-enterprise-cloud-with-data-residency.md

@@ -31,6 +31,7 @@ The following features are currently unavailable on {% data variables.enterprise
 | Some features currently in {% data variables.release-phases.public_preview %} or {% data variables.release-phases.private_preview %} | Certain features that are in a preview phase on {% data variables.product.prodname_dotcom_the_website %} may not be available on {% data variables.enterprise.data_residency_site %} until GA. | |
 | Migrations REST API | Currently unavailable. | [AUTOTITLE](/rest/migrations) |
 | Streaming audit logs to Amazon S3 with OpenID Connect (OIDC) | Currently unavailable. | [AUTOTITLE](/admin/monitoring-activity-in-your-enterprise/reviewing-audit-logs-for-your-enterprise/streaming-the-audit-log-for-your-enterprise) |
+| Organization-level dependency insights | Currently unavailable. | [AUTOTITLE](/organizations/collaborating-with-groups-in-organizations/viewing-insights-for-dependencies-in-your-organization) |
 
 ## Permanently unavailable features
 

content/code-security/concepts/supply-chain-security/dependency-graph-data.md

@@ -54,10 +54,18 @@ To enable automatic dependency submission, see [AUTOTITLE](/code-security/supply
 
 ## {% data variables.product.prodname_dependabot %} graph jobs
 
-This method uses a special type of {% data variables.product.prodname_dependabot %} job that builds a dependency snapshot and uploads it to the dependency submission API. This is currently only supported for **Go** dependencies.
+{% data variables.product.prodname_dependabot %} graph jobs use a special type of {% data variables.product.prodname_dependabot %} job to build a dependency snapshot and upload it to the dependency submission API. {% data variables.product.prodname_dependabot %} graph jobs are currently supported for **Go** and **Python** dependencies.
+
+For supported ecosystems, {% data variables.product.prodname_dependabot %} graph jobs provide:
+
+* Full transitive dependency coverage, which means {% data variables.product.prodname_dependabot %} can alert you to vulnerabilities in indirect dependencies that static analysis may miss.
+* Private registry access through {% data variables.product.prodname_dependabot %} secrets configured at the organization or repository level. For more information, see [AUTOTITLE](/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/configuring-access-to-private-registries-for-dependabot).
+* Private packages that are not accessible through configured {% data variables.product.prodname_dependabot %} secrets are gracefully omitted from the dependency graph without causing a failure.
 
 This approach is similar to automatic dependency submission, but does not incur charges for {% data variables.product.prodname_actions %} minutes. It can also access organization-wide configurations for private registries you've set up for {% data variables.product.prodname_dependabot %}.
 
+> [!NOTE] {% data variables.product.prodname_dependabot %} graph jobs take precedence over automatic dependency submission. For example, if your Python repository previously used automatic dependency submission, those jobs will no longer run once {% data variables.product.prodname_dependabot %} graph jobs are active. The only requirement is that the dependency graph is enabled for your repository.
+
 {% endif %}
 
 ## The {% data variables.dependency-submission-api.name %}

content/code-security/how-tos/secure-your-supply-chain/secure-your-dependencies/configuring-automatic-dependency-submission-for-your-repository.md

@@ -19,6 +19,9 @@ Dependency graph must be enabled for the repository for you to enable automatic
 
 You must also enable {% data variables.product.prodname_actions %} for the repository in order to use automatic dependency submission. For more information, see [AUTOTITLE](/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository).
 
+> [!NOTE]
+> For ecosystems that support {% data variables.product.prodname_dependabot %} graph jobs, you do not need to enable automatic dependency submission. {% data variables.product.prodname_dependabot %} graph jobs run automatically when the dependency graph is enabled for your repository, and they take precedence over automatic dependency submission. See [AUTOTITLE](/code-security/concepts/supply-chain-security/dependency-graph-data#dependabot-graph-jobs).
+
 ## Enabling automatic dependency submission
 
 Repository administrators can enable or disable automatic dependency submission for a repository by following the steps outlined in this procedure.
@@ -39,14 +42,24 @@ You can view details about the automatic workflows run by viewing the **Actions*
 
 > [!NOTE] After you enable automatic dependency submission, we'll automatically trigger a run of the action. Once enabled, it'll run each time a commit to the default branch updates a manifest.
 
-## Accessing private registries with self-hosted runners
+## Accessing private registries
+
+### Using {% data variables.product.prodname_dependabot %} secrets
+
+For ecosystems that support {% data variables.product.prodname_dependabot %} graph jobs, you can configure access to private registries using {% data variables.product.prodname_dependabot %} secrets at the organization or repository level.
+
+When {% data variables.product.prodname_dependabot %} graph jobs encounter private packages that are not accessible through configured secrets, those packages are gracefully omitted from the dependency graph without causing a failure.
+
+For more information on configuring private registry access, see [AUTOTITLE](/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/configuring-access-to-private-registries-for-dependabot).
+
+### Using self-hosted runners
 
-You can configure self-hosted runners to run automatic dependency submission jobs, instead of using the {% data variables.product.prodname_actions %} infrastructure. This is necessary to access private Maven registries. The self-hosted runners must be running on Linux or macOS. For .NET and Python auto-submission, they must have access to the public internet in order to download the latest component-detection release.
+You can configure **self-hosted runners** to run automatic dependency submission jobs, instead of using the {% data variables.product.prodname_actions %} infrastructure. This is necessary to access private registries for ecosystems that do not support {% data variables.product.prodname_dependabot %} graph jobs, or when your registries are only reachable from within your network. The self-hosted runners must be running on Linux or macOS. For .NET and Python auto-submission, they must have access to the public internet in order to download the latest component-detection release.
 
 1. Provision one or more self-hosted runners, at the repository or organization level. For more information, see [AUTOTITLE](/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners) and [AUTOTITLE](/actions/hosting-your-own-runners/managing-self-hosted-runners/adding-self-hosted-runners).
 1. Assign a `dependency-submission` label to each runner you want automatic dependency submission to use. For more information, see [AUTOTITLE](/actions/hosting-your-own-runners/managing-self-hosted-runners/using-labels-with-self-hosted-runners#assigning-a-label-to-a-self-hosted-runner).
 {% data reusables.repositories.navigate-to-code-security-and-analysis %}
-1. Under "Dependency graph", click the dropdown menu next to “Automatic dependency submission”, then select **Enabled for labeled runners**.
+1. Under "Dependency graph", click the dropdown menu next to "Automatic dependency submission", then select **Enabled for labeled runners**.
 
 Once enabled, automatic dependency submission jobs will run on the self-hosted runners, unless:
 * The self-hosted runners are unavailable.