diff --git a/content/actions/publishing-packages/publishing-nodejs-packages.md b/content/actions/publishing-packages/publishing-nodejs-packages.md
index eeb00473132a..daf069e0a136 100644
--- a/content/actions/publishing-packages/publishing-nodejs-packages.md
+++ b/content/actions/publishing-packages/publishing-nodejs-packages.md
@@ -40,13 +40,13 @@ You may also find it helpful to have a basic understanding of the following:
 
 ## About package configuration
 
- The `name` and `version` fields in the _package.json_ file create a unique identifier that registries use to link your package to a registry. You can add a summary for the package listing page by including a `description` field in the _package.json_ file. For more information, see "[Creating a package.json file](https://docs.npmjs.com/creating-a-package-json-file)" and "[Creating Node.js modules](https://docs.npmjs.com/creating-node-js-modules)" in the npm documentation.
+ The `name` and `version` fields in the `package.json` file create a unique identifier that registries use to link your package to a registry. You can add a summary for the package listing page by including a `description` field in the `package.json` file. For more information, see "[Creating a package.json file](https://docs.npmjs.com/creating-a-package-json-file)" and "[Creating Node.js modules](https://docs.npmjs.com/creating-node-js-modules)" in the npm documentation.
 
-When a local _.npmrc_ file exists and has a `registry` value specified, the `npm publish` command uses the registry configured in the _.npmrc_ file. {% data reusables.actions.setup-node-intro %}
+When a local `.npmrc` file exists and has a `registry` value specified, the `npm publish` command uses the registry configured in the `.npmrc` file. {% data reusables.actions.setup-node-intro %}
 
 You can specify the Node.js version installed on the runner using the `setup-node` action.
 
-If you add steps in your workflow to configure the `publishConfig` fields in your _package.json_ file, you don't need to specify the registry-url using the `setup-node` action, but you will be limited to publishing the package to one registry. For more information, see "[publishConfig](https://docs.npmjs.com/cli/v9/configuring-npm/package-json#publishconfig)" in the npm documentation.
+If you add steps in your workflow to configure the `publishConfig` fields in your `package.json` file, you don't need to specify the registry-url using the `setup-node` action, but you will be limited to publishing the package to one registry. For more information, see "[publishConfig](https://docs.npmjs.com/cli/v9/configuring-npm/package-json#publishconfig)" in the npm documentation.
 
 ## Publishing packages to the npm registry
 
@@ -54,11 +54,11 @@ You can trigger a workflow to publish your package every time you publish a new
 
 To perform authenticated operations against the npm registry in your workflow, you'll need to store your npm authentication token as a secret. For example, create a repository secret called `NPM_TOKEN`. For more information, see "[AUTOTITLE](/actions/security-guides/encrypted-secrets)."
 
-By default, npm uses the `name` field of the _package.json_ file to determine the name of your published package. When publishing to a global namespace, you only need to include the package name. For example, you would publish a package named `my-package` to `https://www.npmjs.com/package/my-package`.
+By default, npm uses the `name` field of the `package.json` file to determine the name of your published package. When publishing to a global namespace, you only need to include the package name. For example, you would publish a package named `my-package` to `https://www.npmjs.com/package/my-package`.
 
-If you're publishing a package that includes a scope prefix, include the scope in the name of your _package.json_ file. For example, if your npm scope prefix is "octocat" and the package name is "hello-world", the `name` in your _package.json_ file should be `@octocat/hello-world`. If your npm package uses a scope prefix and the package is public, you need to use the option `npm publish --access public`. This is an option that npm requires to prevent someone from publishing a private package unintentionally.
+If you're publishing a package that includes a scope prefix, include the scope in the name of your `package.json` file. For example, if your npm scope prefix is "octocat" and the package name is "hello-world", the `name` in your `package.json` file should be `@octocat/hello-world`. If your npm package uses a scope prefix and the package is public, you need to use the option `npm publish --access public`. This is an option that npm requires to prevent someone from publishing a private package unintentionally.
 
-This example stores the `NPM_TOKEN` secret in the `NODE_AUTH_TOKEN` environment variable. When the `setup-node` action creates an _.npmrc_ file, it references the token from the `NODE_AUTH_TOKEN` environment variable.
+This example stores the `NPM_TOKEN` secret in the `NODE_AUTH_TOKEN` environment variable. When the `setup-node` action creates an `.npmrc` file, it references the token from the `NODE_AUTH_TOKEN` environment variable.
 
 ```yaml copy
 name: Publish Package to npmjs
@@ -81,7 +81,7 @@ jobs:
           NODE_AUTH_TOKEN: {% raw %}${{ secrets.NPM_TOKEN }}{% endraw %}
 ```
 
-In the example above, the `setup-node` action creates an _.npmrc_ file on the runner with the following contents:
+In the example above, the `setup-node` action creates an `.npmrc` file on the runner with the following contents:
 
 ```ini
 //registry.npmjs.org/:_authToken=${NODE_AUTH_TOKEN}
@@ -97,9 +97,9 @@ You can trigger a workflow to publish your package every time you publish a new
 
 ### Configuring the destination repository
 
-Linking your package to {% data variables.product.prodname_registry %} using the `repository` key is optional. If you choose not to provide the `repository` key in your _package.json_ file, then {% data variables.product.prodname_registry %} publishes a package in the {% data variables.product.prodname_dotcom %} repository you specify in the `name` field of the _package.json_ file. For example, a package named `@my-org/test` is published to the `my-org/test` {% data variables.product.prodname_dotcom %} repository. If the `url` specified in the `repository` key is invalid, your package may still be published however it won't be linked to the repository source as intended.
+Linking your package to {% data variables.product.prodname_registry %} using the `repository` key is optional. If you choose not to provide the `repository` key in your `package.json` file, then {% ifversion packages-npm-v2 %}your package will not be linked to a repository when it is published, but you can choose to connect the package to a repository later.{% else %}{% data variables.product.prodname_registry %} publishes a package in the {% data variables.product.prodname_dotcom %} repository you specify in the `name` field of the `package.json` file. For example, a package named `@my-org/test` is published to the `my-org/test` {% data variables.product.prodname_dotcom %} repository. If the `url` specified in the `repository` key is invalid, your package may still be published however it won't be linked to the repository source as intended.{% endif %}
 
-If you do provide the `repository` key in your _package.json_ file, then the repository in that key is used as the destination npm registry for {% data variables.product.prodname_registry %}. For example, publishing the below _package.json_ results in a package named `my-package` published to the `octocat/my-other-repo` {% data variables.product.prodname_dotcom %} repository. Once published, only the repository source is updated, and the package doesn't inherit any permissions from the destination repository.
+If you do provide the `repository` key in your `package.json` file, then the repository in that key is used as the destination npm registry for {% data variables.product.prodname_registry %}. For example, publishing the below `package.json` results in a package named `my-package` published to the `octocat/my-other-repo` {% data variables.product.prodname_dotcom %} repository.{% ifversion packages-npm-v2 %}{% else %} Once published, only the repository source is updated, and the package doesn't inherit any permissions from the destination repository.{% endif %}
 
 ```json
 {
@@ -118,7 +118,7 @@ If you want to publish your package to a different repository, you must use a {%
 
 ### Example workflow
 
-This example stores the `GITHUB_TOKEN` secret in the `NODE_AUTH_TOKEN` environment variable. When the `setup-node` action creates an _.npmrc_ file, it references the token from the `NODE_AUTH_TOKEN` environment variable.
+This example stores the `GITHUB_TOKEN` secret in the `NODE_AUTH_TOKEN` environment variable. When the `setup-node` action creates an `.npmrc` file, it references the token from the `NODE_AUTH_TOKEN` environment variable.
 
 ```yaml copy
 name: Publish package to GitHub Packages
@@ -146,7 +146,7 @@ jobs:
           NODE_AUTH_TOKEN: {% raw %}${{ secrets.GITHUB_TOKEN }}{% endraw %}
 ```
 
-The `setup-node` action creates an _.npmrc_ file on the runner. When you use the `scope` input to the `setup-node` action, the _.npmrc_ file includes the scope prefix. By default, the `setup-node` action sets the scope in the _.npmrc_ file to the account that contains that workflow file.
+The `setup-node` action creates an `.npmrc` file on the runner. When you use the `scope` input to the `setup-node` action, the `.npmrc` file includes the scope prefix. By default, the `setup-node` action sets the scope in the `.npmrc` file to the account that contains that workflow file.
 
 ```ini
 //npm.pkg.github.com/:_authToken=${NODE_AUTH_TOKEN}
diff --git a/content/authentication/connecting-to-github-with-ssh/adding-a-new-ssh-key-to-your-github-account.md b/content/authentication/connecting-to-github-with-ssh/adding-a-new-ssh-key-to-your-github-account.md
index 989465e64643..1ad9014b7b31 100644
--- a/content/authentication/connecting-to-github-with-ssh/adding-a-new-ssh-key-to-your-github-account.md
+++ b/content/authentication/connecting-to-github-with-ssh/adding-a-new-ssh-key-to-your-github-account.md
@@ -63,7 +63,7 @@ Before you can use the {% data variables.product.prodname_cli %} to add an SSH k
 
 {% ifversion ssh-commit-verification %}At present, you can only use {% data variables.product.prodname_cli %} to add SSH authentication keys, you cannot add SSH signing keys.{% endif %}
 
-To add an SSH authentication key to your GitHub account, use the `ssh-key add` subcommand, specifying your public key.
+To add an SSH authentication key to your GitHub account, use the `ssh-key add` subcommand, specifying your public key. If you're prompted to request additional scopes, follow the instructions in the command line.
 
 ```shell
 gh ssh-key add KEY-FILE
diff --git a/content/organizations/managing-organization-settings/creating-rulesets-for-repositories-in-your-organization.md b/content/organizations/managing-organization-settings/creating-rulesets-for-repositories-in-your-organization.md
new file mode 100644
index 000000000000..96a1a0479733
--- /dev/null
+++ b/content/organizations/managing-organization-settings/creating-rulesets-for-repositories-in-your-organization.md
@@ -0,0 +1,93 @@
+---
+title: Creating rulesets for repositories in your organization
+intro: 'You can create a ruleset to target multiple repositories in your organization.'
+versions:
+  feature: repo-rules-enterprise
+permissions: 'Organization owners can create rulesets at the organization level.'
+topics:
+  - Organizations
+shortTitle: Create rulesets
+---
+
+## Introduction
+
+You can create rulesets in your organization to control how users can interact with repositories in your organization. You can control things like who can push commits to a certain branch and how the commits must be formatted, or who can delete or rename a tag. You can also prevent people from renaming repositories.
+
+When you create a ruleset for an organization, you use `fnmatch` syntax to define which repositories in your organization, and which branches or tags in those repositories, are targeted by the ruleset. This provides a quicker way to target repositories in your organization than creating a separate ruleset for each repository. For more information, see "[About `fnmatch` patterns for branches, tags, and repositories](#about-fnmatch-patterns-for-branches-tags-and-repositories)."
+
+Forks do not inherit rulesets from their upstream repositories. However, forks owned by your organization are subject to the rulesets you create, like any other repository.
+
+To create a ruleset, complete the following procedures:
+
+- [Creating a branch or tag ruleset](#creating-a-branch-or-tag-ruleset)
+- [Granting bypass permissions for your ruleset](#granting-bypass-permissions-for-your-ruleset)
+- [Choosing which repositories to target in your organization](#choosing-which-repositories-to-target-in-your-organization)
+- [Choosing which branches or tags to target](#choosing-which-branches-or-tags-to-target)
+- [Selecting branch or tag protections](#selecting-branch-or-tag-protections)
+- [Adding metadata restrictions](#adding-metadata-restrictions)
+- [Finalizing your ruleset and next steps](#finalizing-your-ruleset-and-next-steps)
+
+## Creating a branch or tag ruleset
+
+{% data reusables.profile.access_org %}
+{% data reusables.profile.org_settings %}
+{% data reusables.organizations.access-ruleset-settings %}
+{% data reusables.repositories.create-ruleset-step %}
+{% data reusables.repositories.rulesets-general-step %}
+
+## Granting bypass permissions for your ruleset
+
+{% data reusables.repositories.rulesets-bypass-step %}
+
+## Choosing which repositories to target in your organization
+
+With your ruleset, you can choose to target all repositories in your organization, repositories in your organization that match a certain naming convention, or a list of manually selected repositories in your organization.
+
+If a repository is targeted by a ruleset created at the organization level, only owners of the organization can edit the ruleset. However, people with admin access to the repository, or with a custom role including the "edit repository rules" permission, can create additional rulesets at the repository level. The rules in these rulesets will be aggregated with the rules defined at the organization level. The result is that creating a new ruleset can make the rules targeting a branch or tag more restrictive, but never less restrictive. For more information on creating rulesets, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets)."
+
+### Targeting all repositories in your organization
+
+To target all repositories in your organization, in the "Target repositories" section, select {% octicon "goal" aria-hidden="true" %} **Target: REPOSITORIES**, then click **All repositories**.
+
+### Targeting repositories by naming convention in your organization
+
+1. To target a dynamic list of repositories in your organization by naming convention, in the "Target repositories" section, select {% octicon "goal" aria-hidden="true" %} **Target: REPOSITORIES**, then click **Dynamic list of repositories**.
+1. To begin defining a targeting pattern, in the "Targeting criteria" section, select **Add a target** {% octicon "triangle-down" aria-hidden="true" %}, then click **Include by pattern** or **Exclude by pattern**.
+1. In the modal dialog that appears, enter a repository naming pattern using `fnmatch` syntax, then click **Add Inclusion pattern** or **Add Exclusion pattern**. For more information on `fnmatch` syntax, see "[Using `fnmatch` syntax](#using-fnmatch-syntax)."
+
+  {% note %}
+
+  **Note:** You can add multiple targeting criteria to the same ruleset. For example, you could include any repositories matching the pattern `*cat*`, then specifically exclude a repository matching the pattern `not-a-cat`.
+
+  {% endnote %}
+
+1. Optionally, on the ruleset configuration page, select **Prevent renaming of target repositories**.
+
+### Targeting select repositories in your organization
+
+1. To target a static, manually selected list of repositories in your organization, in the "Target repositories" section, select {% octicon "goal" aria-hidden="true" %} **Target: REPOSITORIES**, then click **Select repositories**.
+1. To select repositories to target, in the "Targeting criteria" section, select {% octicon "repo" aria-hidden="true" %} **Select repositories**, then search for the name of each repository you would like to target. Select each repository from the search results.
+
+## Choosing which branches or tags to target
+
+{% data reusables.repositories.rulesets-target-branches %}
+
+## Selecting branch or tag protections
+
+{% data reusables.repositories.rulesets-protections-step %}
+
+## Adding metadata restrictions
+
+{% data reusables.repositories.rulesets-metadata-step %}
+
+## Finalizing your ruleset and next steps
+
+{% data reusables.repositories.rulesets-create-and-insights-step %}
+
+## About `fnmatch` patterns for branches, tags, and repositories
+
+{% data reusables.repositories.rulesets-fnmatch %}
+
+## About regular expressions for commit metadata
+
+{% data reusables.repositories.rulesets-commit-regex %}
\ No newline at end of file
diff --git a/content/organizations/managing-organization-settings/index.md b/content/organizations/managing-organization-settings/index.md
index cafe197671dc..eea0501d4e45 100644
--- a/content/organizations/managing-organization-settings/index.md
+++ b/content/organizations/managing-organization-settings/index.md
@@ -46,6 +46,7 @@ children:
   - /disabling-insights-for-projects-in-your-organization
   - /managing-base-permissions-for-projects
   - /allowing-project-visibility-changes-in-your-organization
+  - /creating-rulesets-for-repositories-in-your-organization
   - /managing-rulesets-for-repositories-in-your-organization
 shortTitle: Manage organization settings
 ---
diff --git a/content/organizations/managing-organization-settings/managing-rulesets-for-repositories-in-your-organization.md b/content/organizations/managing-organization-settings/managing-rulesets-for-repositories-in-your-organization.md
index 8aed4d112b19..d83b80f32b44 100644
--- a/content/organizations/managing-organization-settings/managing-rulesets-for-repositories-in-your-organization.md
+++ b/content/organizations/managing-organization-settings/managing-rulesets-for-repositories-in-your-organization.md
@@ -1,6 +1,6 @@
 ---
 title: Managing rulesets for repositories in your organization
-intro: 'You can create a ruleset to target multiple repositories in your organization.'
+intro: 'You can edit, monitor, and delete existing rulesets to alter how people can interact with repositories in your organization.'
 versions:
   feature: repo-rules-enterprise
 permissions: 'Organization owners can manage rulesets at the organization level.'
@@ -11,51 +11,12 @@ shortTitle: Manage rulesets
 
 ## About managing rulesets for an organization
 
-You can create rulesets in your organization to control how users can interact with repositories in your organization. You can control things like who can push commits to a certain branch and how the commits must be formatted, or who can delete or rename a tag. You can also prevent people from renaming repositories.
-
-When you create a ruleset for an organization, you use `fnmatch` syntax to define which repositories in your organization, and which branches or tags in those repositories, are targeted by the ruleset. For more information, see "[Using fnmatch syntax](#using-fnmatch-syntax)." This provides a quicker way for managing rulesets than creating a separate ruleset for each repository you want to target.
-
-{% data reusables.repositories.ruleset-bypass %}
+After creating a ruleset at the organization level, you can make changes to the ruleset to alter how people can interact with the targeted repositories. For example, you can add rules to better protect the branches or tags in those repositories, or you can switch your ruleset from "Evaluate" mode to "Active" after testing its effects on the contributor experience for your repositories.
 
 You can use the REST and GraphQL APIs to manage rulesets. For more information, see "[AUTOTITLE](/rest/orgs/rules)" and "[AUTOTITLE](/graphql/reference/mutations#createrepositoryruleset)."
 
-If a repository is targeted by a ruleset created at organization level, only owners of the organization can edit this ruleset. However, people with admin access to the repository, or with a custom role including the "edit repository rules" permission, can create additional rulesets at the repository level. The rules in these rulesets will be aggregated with the rules defined at organization level. The result is that creating a new ruleset can make the rules targeting a branch or tag more restrictive, but never less restrictive. For more information, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets)."
-
-{% data reusables.repositories.rulesets-sudo-mode %}
-
-Forks do not inherit rulesets from their upstream repositories. However, forks owned by your organization are subject to the rulesets you create, like any other repository.
-
 {% data reusables.repositories.rulesets-anyone-can-view %}
 
-## Creating a ruleset
-
-{% data reusables.profile.access_org %}
-{% data reusables.profile.org_settings %}
-{% data reusables.organizations.access-ruleset-settings %}
-{% data reusables.repositories.create-ruleset-step %}
-{% data reusables.repositories.rulesets-general-step %}
-{% data reusables.repositories.rulesets-bypass-step %}
-1. In the "Target repositories" section, select {% octicon "goal" aria-hidden="true" %} **Target: REPOSITORIES**, then click:
-    - **All repositories** to target all repositories in the organization,
-    - **Dynamic list of repositories** to target a dynamically updated list of repositories based on their names, or
-    - **Select repositories** to target a static list of repositories that you manually select.
-1. If you chose to target a dynamic list of repositories, in the "Targeting criteria" section:
-     - Select **Add a target** {% octicon "triangle-down" aria-hidden="true" %}, then click **Include by pattern** or **Exclude by pattern**.
-     - In the modal dialog that appears, enter a repository naming pattern using `fnmatch` syntax, then click **Add Inclusion pattern** or **Add Exclusion pattern**. For more information on `fnmatch` syntax, see "[Using `fnmatch` syntax](#using-fnmatch-syntax)."
-     - Optionally, on the ruleset configuration page, select **Prevent renaming of target repositories**.
-
-    {% note %}
-
-    **Note:** You can add multiple targeting criteria to the same ruleset. For example, you could include any repositories matching the pattern `*cat*`, then specifically exclude a repository matching the pattern `not-a-cat`.
-
-    {% endnote %}
-
-1. If you chose to target a static list of select repositories, in the "Targeting criteria" section, select {% octicon "repo" aria-hidden="true" %} **Select repositories**, then search for the name of each repository you would like to target. Select each repository from the search results.
-{% data reusables.repositories.rulesets-target-branches %}
-{% data reusables.repositories.rulesets-protections-step %}
-{% data reusables.repositories.rulesets-metadata-step %}
-{% data reusables.repositories.rulesets-create-step %}
-
 ## Editing a ruleset
 
 {% data reusables.repositories.about-editing-rulesets %}
@@ -85,11 +46,3 @@ You can view insights for rulesets to see how rulesets are affecting the reposit
    ![Screenshot of an organization's settings page. In the sidebar, a link labeled "Repository rule insights" is outlined in orange.](/assets/images/help/organizations/repository-rule-insights.png)
 1. On the "Rule Insights" page, use the dropdown menus at the top of the page to filter the actions by ruleset, repository, actor, and time period.
 {% data reusables.repositories.rulesets-view-rule-runs %}
-
-## Using `fnmatch` syntax
-
-{% data reusables.repositories.rulesets-fnmatch %}
-
-## Using regular expressions for commit metadata
-
-{% data reusables.repositories.rulesets-commit-regex %}
diff --git a/content/packages/working-with-a-github-packages-registry/working-with-the-npm-registry.md b/content/packages/working-with-a-github-packages-registry/working-with-the-npm-registry.md
index 9aa4196a1a27..d578a5146b14 100644
--- a/content/packages/working-with-a-github-packages-registry/working-with-the-npm-registry.md
+++ b/content/packages/working-with-a-github-packages-registry/working-with-the-npm-registry.md
@@ -123,15 +123,15 @@ $ npm login --scope=@NAMESPACE --auth-type=legacy --registry=https://HOSTNAME/_r
 The {% data variables.product.prodname_registry %} registry stores npm packages within your organization or personal account, and allows you to associate a package with a repository. You can choose whether to inherit permissions from a repository, or set granular permissions independently of a repository.
 
 {% data reusables.package_registry.publishing-user-scoped-packages %} For more information on linking a published package with a repository, see "[AUTOTITLE](/packages/learn-github-packages/connecting-a-repository-to-a-package)."
-{% endif %}
 
-By default, your package is published in the {% data variables.product.prodname_dotcom %} repository that you specify in the name field of the _package.json_ file. For example, you would publish a package named `@my-org/test` to the `my-org/test` {% data variables.product.prodname_dotcom %} repository. If you're running [npm v8.5.3](https://github.com/npm/cli/releases/tag/v8.5.3) or later, you can add a summary for the package listing page by including a _README.md_ file in your package directory. For more information, see "[Working with package.json](https://docs.npmjs.com/getting-started/using-a-package.json)" and "[How to create Node.js Modules](https://docs.npmjs.com/getting-started/creating-node-modules)" in the npm documentation.
+You can connect a package to a repository as soon as the package is published by including a `repository` field in the `package.json` file. You can also use this method to connect multiple packages to the same repository. For more information, see "[Publishing multiple packages to the same repository](#publishing-multiple-packages-to-the-same-repository)."
+{% else %}
+By default, your package is published in the {% data variables.product.prodname_dotcom %} repository that you specify in the `name` field of the `package.json` file. For example, you would publish a package named `@my-org/test` to the `my-org/test` {% data variables.product.prodname_dotcom %} repository. You can publish multiple packages to the same {% data variables.product.prodname_dotcom %} repository by including a `repository` field in the `package.json` file. For more information, see "[Publishing multiple packages to the same repository](#publishing-multiple-packages-to-the-same-repository)."
+{% endif %}
 
 {% data reusables.package_registry.auto-inherit-permissions-note %}
 
-You can publish multiple packages to the same {% data variables.product.prodname_dotcom %} repository by including a `URL` field in the _package.json_ file. For more information, see "[Publishing multiple packages to the same repository](#publishing-multiple-packages-to-the-same-repository)."
-
-You can set up the scope mapping for your project using either a local _.npmrc_ file in the project or using the `publishConfig` option in the _package.json_. {% data variables.product.prodname_registry %} only supports scoped npm packages. Scoped packages have names with the format of `@NAMESPACE/PACKAGE-NAME`. Scoped packages always begin with an `@` symbol. You may need to update the name in your _package.json_ to use the scoped name. For example, if you're the user `octocat` and your package is named `test`, you would assign the scoped package name as follows: `"name": "@octocat/test"`.
+You can set up the scope mapping for your project using either a local `.npmrc` file in the project or using the `publishConfig` option in the `package.json`. {% data variables.product.prodname_registry %} only supports scoped npm packages. Scoped packages have names with the format of `@NAMESPACE/PACKAGE-NAME`. Scoped packages always begin with an `@` symbol. You may need to update the name in your `package.json` to use the scoped name. For example, if you're the user `octocat` and your package is named `test`, you would assign the scoped package name as follows: `"name": "@octocat/test"`.
 
 {% data reusables.package_registry.viewing-packages %}
 
@@ -142,15 +142,15 @@ You can use an _.npmrc_ file to configure the scope mapping for your project. In
 {% data reusables.package_registry.authenticate-step %}
 {% data reusables.package_registry.create-npmrc-owner-step %}
 {% data reusables.package_registry.add-npmrc-to-repo-step %}
-1. Verify the name of your package in your project's _package.json_. The `name` field must contain the scope and the name of the package. For example, if your package is called "test", and you are publishing to the "My-org" {% data variables.product.prodname_dotcom %} organization, the `name` field in your _package.json_ should be `@my-org/test`.
+1. Verify the name of your package in your project's `package.json`. The `name` field must contain the scope and the name of the package. For example, if your package is called "test", and you are publishing to the "My-org" {% data variables.product.prodname_dotcom %} organization, the `name` field in your `package.json` should be `@my-org/test`.
 {% data reusables.package_registry.verify_repository_field %}
 {% data reusables.package_registry.publish_package %}
 
-### Publishing a package using `publishConfig` in the _package.json_ file
+### Publishing a package using `publishConfig` in the `package.json` file
 
-You can use `publishConfig` element in the _package.json_ file to specify the registry where you want the package published. For more information, see "[publishConfig](https://docs.npmjs.com/files/package.json#publishconfig)" in the npm documentation.
+You can use `publishConfig` element in the `package.json` file to specify the registry where you want the package published. For more information, see "[publishConfig](https://docs.npmjs.com/files/package.json#publishconfig)" in the npm documentation.
 
-1. Edit the _package.json_ file for your package and include a `publishConfig` entry.
+1. Edit the `package.json` file for your package and include a `publishConfig` entry.
    {% ifversion ghes %}
    If your instance has subdomain isolation enabled:
    {% endif %}
@@ -176,7 +176,7 @@ You can use `publishConfig` element in the _package.json_ file to specify the re
 
 ## Publishing multiple packages to the same repository
 
-To publish multiple packages {% ifversion packages-npm-v2 %}and link them {% endif %}to the same repository, you can include the URL of the {% data variables.product.prodname_dotcom %} repository in the `repository` field of the _package.json_ file for each package.
+To publish multiple packages {% ifversion packages-npm-v2 %}and link them {% endif %}to the same repository, you can include the URL of the {% data variables.product.prodname_dotcom %} repository in the `repository` field of the `package.json` file for each package. For more information, see "[Creating a package.json file](https://docs.npmjs.com/creating-a-package-json-file)" and "[Creating Node.js modules](https://docs.npmjs.com/creating-node-js-modules)" in the npm documentation.
 
 To ensure the repository's URL is correct, replace `REPOSITORY` with the name of the repository containing the package you want to publish, and `OWNER` with the name of the personal account or organization on {% data variables.product.prodname_dotcom %} that owns the repository.
 
@@ -188,7 +188,7 @@ To ensure the repository's URL is correct, replace `REPOSITORY` with the name of
 
 ## Installing a package
 
-You can install packages from {% data variables.product.prodname_registry %} by adding the packages as dependencies in the _package.json_ file for your project. For more information on using a _package.json_ in your project, see "[Working with package.json](https://docs.npmjs.com/getting-started/using-a-package.json)" in the npm documentation.
+You can install packages from {% data variables.product.prodname_registry %} by adding the packages as dependencies in the `package.json` file for your project. For more information on using a `package.json` in your project, see "[Working with package.json](https://docs.npmjs.com/getting-started/using-a-package.json)" in the npm documentation.
 
 By default, you can add packages from one organization. For more information, see "[Installing packages from other organizations](#installing-packages-from-other-organizations)."
 
@@ -201,7 +201,7 @@ By default, you can only use npm packages hosted on your enterprise, and you wil
 {% data reusables.package_registry.authenticate-step %}
 {% data reusables.package_registry.create-npmrc-owner-step %}
 {% data reusables.package_registry.add-npmrc-to-repo-step %}
-1. Configure _package.json_ in your project to use the package you are installing. To add your package dependencies to the _package.json_ file for {% data variables.product.prodname_registry %}, specify the full-scoped package name, such as `@my-org/server`. For packages from _npmjs.com_, specify the full name, such as `@babel/core` or `@lodash`. Replace `ORGANIZATION_NAME/PACKAGE_NAME` with your package dependency.
+1. Configure `package.json` in your project to use the package you are installing. To add your package dependencies to the `package.json` file for {% data variables.product.prodname_registry %}, specify the full-scoped package name, such as `@my-org/server`. For packages from _npmjs.com_, specify the full name, such as `@babel/core` or `@lodash`. Replace `ORGANIZATION_NAME/PACKAGE_NAME` with your package dependency.
 
    ```json
    {
diff --git a/content/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets.md b/content/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets.md
index a92700803621..bec96d3ee75d 100644
--- a/content/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets.md
+++ b/content/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets.md
@@ -14,9 +14,9 @@ shortTitle: About rulesets
 
 A ruleset is a named list of rules that applies to a repository{% ifversion repo-rules-enterprise %}, or to multiple repositories in an organization{% endif %}. You can create rulesets to control how people can interact with selected branches and tags in a repository. You can control things like who can push commits to a certain branch{% ifversion repo-rules-enterprise %} and how the commits must be formatted{% endif %}, or who can delete or rename a tag. For example, you could set up a ruleset for your repository's `feature` branch that requires signed commits and blocks force pushes for all users except repository administrators.
 
-For each ruleset you create, you specify which branches or tags in your repository{% ifversion repo-rules-enterprise %}, or which repositories in your organization,{% endif %} the ruleset applies to. You can use `fnmatch` syntax to define a pattern to target specific {% ifversion repo-rules-enterprise %}branches, tags, and repositories{% else %}branches and tags{% endif %}. For example, you could use the pattern `releases/**/*` to target all branches in your repository whose name starts with the string `releases/`. For more information on `fnmatch` syntax, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/managing-rulesets-for-a-repository#using-fnmatch-syntax)."
+For each ruleset you create, you specify which branches or tags in your repository{% ifversion repo-rules-enterprise %}, or which repositories in your organization,{% endif %} the ruleset applies to. You can use `fnmatch` syntax to define a pattern to target specific {% ifversion repo-rules-enterprise %}branches, tags, and repositories{% else %}branches and tags{% endif %}. For example, you could use the pattern `releases/**/*` to target all branches in your repository whose name starts with the string `releases/`. For more information on `fnmatch` syntax, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/creating-rulesets-for-a-repository#using-fnmatch-syntax)."
 
-{% data reusables.repositories.ruleset-bypass %}
+When you create a ruleset, you can allow certain users to bypass the rules in the ruleset. This can be users with a certain role, such as repository administrator, or it can be specific teams or {% data variables.product.prodname_github_apps %}.
 
 ## About rulesets, protected branches, and protected tags
 
diff --git a/content/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets.md b/content/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets.md
index bb526623bd1d..3ef2805ac70a 100644
--- a/content/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets.md
+++ b/content/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets.md
@@ -14,7 +14,7 @@ You can create rulesets to control how users can interact with selected branches
 
 When you create a ruleset, you can allow certain users to bypass the rules in the ruleset. This can be users with certain permissions, specific teams, or {% data variables.product.prodname_github_apps %}. For more information, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets)."
 
-For more information on creating and managing rulesets, see {% ifversion ghec %}"[AUTOTITLE](/enterprise-cloud@latest/organizations/managing-organization-settings/managing-rulesets-for-repositories-in-your-organization)" and {% endif %}"[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/managing-rulesets-for-a-repository)."
+For more information on creating rulesets, see {% ifversion ghec %}"[AUTOTITLE](/enterprise-cloud@latest/organizations/managing-organization-settings/creating-rulesets-for-repositories-in-your-organization)" and {% endif %}"[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/creating-rulesets-for-a-repository)."
 
 ## Restrict creations
 
@@ -136,7 +136,7 @@ If a site administrator has blocked force pushes to the default branch only, you
 
 {% data reusables.repositories.rulesets-metadata-restrictions-notes %}
 
-Organizations on a {% data variables.product.prodname_enterprise %} plan can access additional rules to control how commit metadata must be formatted. You can use literal strings or regular expression syntax to define a pattern that the commit metadata must conform to. For example, you can require that commit messages contain a {% data variables.product.company_short %} issue number, or that the committer or author has an email address ending in `@octoorg.com`. You can also control the format of new branch names and tag names. For a selection of useful regular expressions for commit metadata, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/managing-rulesets-for-a-repository#using-regular-expressions-for-commit-metadata)."
+Organizations on a {% data variables.product.prodname_enterprise %} plan can access additional rules to control how commit metadata must be formatted. You can use literal strings or regular expression syntax to define a pattern that the commit metadata must conform to. For example, you can require that commit messages contain a {% data variables.product.company_short %} issue number, or that the committer or author has an email address ending in `@octoorg.com`. You can also control the format of new branch names and tag names. For a selection of useful regular expressions for commit metadata, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/creating-rulesets-for-a-repository#using-regular-expressions-for-commit-metadata)."
 
 If a contributor tries to update a branch or tag with a commit that doesn't meet your requirements, the contributor will see an error telling them what was wrong with their commit. This error can appear both in the command line, when the user pushes, and on {% data variables.product.prodname_dotcom_the_website %}, when the user tries to make a commit or merge a pull request. Commits are immutable in Git: once a contributor has created a commit, they cannot edit the commit's metadata, so they may need to perform a rebase to rewrite their commit history with new commits before they can successfully contribute their work to the repository.
 
diff --git a/content/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/creating-rulesets-for-a-repository.md b/content/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/creating-rulesets-for-a-repository.md
new file mode 100644
index 000000000000..a25b07b3fb89
--- /dev/null
+++ b/content/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/creating-rulesets-for-a-repository.md
@@ -0,0 +1,67 @@
+---
+title: Creating rulesets for a repository
+intro: 'You can add rulesets to a repository to control how people can interact with specific branches and tags.'
+product: '{% data reusables.gated-features.repo-rules %}'
+versions:
+  feature: repo-rules
+permissions: '{% data reusables.repositories.repo-rules-permissions %}'
+topics:
+  - Repositories
+shortTitle: Create a ruleset
+---
+
+## Introduction
+
+You can create rulesets to control how users can interact with selected branches and tags in a repository. When you create a ruleset, you can allow certain users to bypass the rules in the ruleset. This can be users with certain permissions, specific teams, or {% data variables.product.prodname_github_apps %}. For more information on rulesets, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets)."
+
+To create a ruleset, complete the following procedures:
+
+- [Creating a branch or tag ruleset](#creating-a-branch-or-tag-ruleset)
+- [Granting bypass permissions for your ruleset](#granting-bypass-permissions-for-your-ruleset)
+- [Choosing which branches or tags to target](#choosing-which-branches-or-tags-to-target)
+- [Selecting branch or tag protections](#selecting-branch-or-tag-protections){% ifversion repo-rules-enterprise %}
+- [Adding metadata restrictions](#adding-metadata-restrictions)
+- [Finalizing your ruleset and next steps](#finalizing-your-ruleset-and-next-steps){% endif %}
+
+## Creating a branch or tag ruleset
+
+{% data reusables.repositories.navigate-to-repo %}
+{% data reusables.repositories.sidebar-settings %}
+{% data reusables.repositories.repo-rulesets-settings %}
+{% data reusables.repositories.create-ruleset-step %}
+{% data reusables.repositories.rulesets-general-step %}
+
+## Granting bypass permissions for your ruleset
+
+{% data reusables.repositories.rulesets-bypass-step %}
+
+## Choosing which branches or tags to target
+
+{% data reusables.repositories.rulesets-target-branches %}
+
+## Selecting branch or tag protections
+
+{% data reusables.repositories.rulesets-protections-step %}
+{% ifversion fpt %}
+{% data reusables.repositories.rulesets-create-and-insights-step %}
+{% else %}
+
+## Adding metadata restrictions
+
+{% data reusables.repositories.rulesets-metadata-step %}
+
+## Finalizing your ruleset and next steps
+
+{% data reusables.repositories.rulesets-create-and-insights-step %}
+{% endif %}
+
+## Using `fnmatch` syntax
+
+{% data reusables.repositories.rulesets-fnmatch %}
+{% ifversion repo-rules-enterprise %}
+
+## Using regular expressions for commit metadata
+
+{% data reusables.repositories.rulesets-commit-regex %}
+
+{% endif %}
diff --git a/content/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/index.md b/content/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/index.md
index 801c99ee07c3..2fe369127983 100644
--- a/content/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/index.md
+++ b/content/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/index.md
@@ -8,9 +8,9 @@ topics:
   - Repositories
 children:
   - /about-rulesets
+  - /creating-rulesets-for-a-repository
   - /managing-rulesets-for-a-repository
   - /available-rules-for-rulesets
   - /troubleshooting-rules
 shortTitle: Manage rulesets
 ---
-
diff --git a/content/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/managing-rulesets-for-a-repository.md b/content/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/managing-rulesets-for-a-repository.md
index 960a0607f85d..3520227f03a8 100644
--- a/content/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/managing-rulesets-for-a-repository.md
+++ b/content/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/managing-rulesets-for-a-repository.md
@@ -1,6 +1,6 @@
 ---
 title: Managing rulesets for a repository
-intro: 'You can add rulesets to a repository to control how people can interact with specific branches and tags.'
+intro: 'You can edit, monitor, and delete existing rulesets in a repository to alter how people can interact with specific branches and tags.'
 product: '{% data reusables.gated-features.repo-rules %}'
 versions:
   feature: repo-rules
@@ -10,16 +10,14 @@ topics:
 shortTitle: Manage a ruleset
 ---
 
-You can create rulesets to control how users can interact with selected branches and tags in a repository. When you create a ruleset, you can allow certain users to bypass the rules in the ruleset. This can be users with certain permissions, specific teams, or {% data variables.product.prodname_github_apps %}. For more information, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets)."
+After creating a ruleset, you can make changes to the ruleset to alter how people can interact with the targeted branches or tags. For example, you can add rules to better protect your branches or tags, or you can {% ifversion repo-rules-enterprise %}switch your ruleset from "Evaluate" mode to "Active" after testing its effects on the contributor experience for your repository{% else %}temporarily disable a ruleset to troubleshoot any unintended effects on the contributor experience for your repository{% endif %}.
 
 You can use the REST and GraphQL APIs to manage rulesets. For more information, see "[AUTOTITLE](/rest/repos/rules)" and "[AUTOTITLE](/graphql/reference/mutations#createrepositoryruleset)."
 
-{% data reusables.repositories.rulesets-sudo-mode %}
-
 {% ifversion repo-rules-enterprise %}
 {% tip %}
 
-**Tip:** If you're the owner of an organization, you can create rulesets at the organization level. You can apply these rulesets to specific repositories in your organization, and to specific branches in those repositories. For more information, see "[AUTOTITLE](/organizations/managing-organization-settings/managing-rulesets-for-repositories-in-your-organization)."
+**Tip:** If you're the owner of an organization, you can create rulesets at the organization level. You can apply these rulesets to specific repositories in your organization, and to specific branches in those repositories. For more information, see "[AUTOTITLE](/organizations/managing-organization-settings/creating-rulesets-for-repositories-in-your-organization)."
 
 {% endtip %}
 {% endif %}
@@ -38,19 +36,6 @@ Anyone with read access to a repository can view the rulesets targeting the repo
    ![Screenshot of the "Rulesets" page. Above a ruleset, a dropdown menu, labeled with a branch icon and "team-test," is highlighted with an orange outline.](/assets/images/help/repository/rulesets-branch-selector.png)
 1. Click the name of the ruleset you want to view.
 
-## Creating a ruleset
-
-{% data reusables.repositories.navigate-to-repo %}
-{% data reusables.repositories.sidebar-settings %}
-{% data reusables.repositories.repo-rulesets-settings %}
-{% data reusables.repositories.create-ruleset-step %}
-{% data reusables.repositories.rulesets-general-step %}
-{% data reusables.repositories.rulesets-bypass-step %}
-{% data reusables.repositories.rulesets-target-branches %}
-{% data reusables.repositories.rulesets-protections-step %}{% ifversion repo-rules-enterprise %}
-{% data reusables.repositories.rulesets-metadata-step %}{% endif %}
-{% data reusables.repositories.rulesets-create-step %}
-
 ## Editing a ruleset
 
 {% ifversion repo-rules-enterprise %}
@@ -92,15 +77,3 @@ You can view insights for rulesets to see how rulesets are affecting a repositor
 {% data reusables.repositories.rulesets-view-rule-runs %}
 
 {% endif %}
-
-## Using `fnmatch` syntax
-
-{% data reusables.repositories.rulesets-fnmatch %}
-
-{% ifversion repo-rules-enterprise %}
-
-## Using regular expressions for commit metadata
-
-{% data reusables.repositories.rulesets-commit-regex %}
-
-{% endif %}
diff --git a/data/reusables/repositories/ruleset-bypass.md b/data/reusables/repositories/ruleset-bypass.md
deleted file mode 100644
index 439ff6ede215..000000000000
--- a/data/reusables/repositories/ruleset-bypass.md
+++ /dev/null
@@ -1 +0,0 @@
-When you create a ruleset, you can allow certain users to bypass the rules in the ruleset. This can be users with a certain role, such as repository administrator, or it can be specific teams or {% data variables.product.prodname_github_apps %}.
diff --git a/data/reusables/repositories/rulesets-bypass-step.md b/data/reusables/repositories/rulesets-bypass-step.md
index 84236f3421a0..ca696416edf7 100644
--- a/data/reusables/repositories/rulesets-bypass-step.md
+++ b/data/reusables/repositories/rulesets-bypass-step.md
@@ -1,9 +1,11 @@
-1. Optionally, to grant bypass permissions for the ruleset, in the "Bypass list" section, click {% octicon "plus" aria-hidden="true" %} **Add bypass**.
-   - In the "Add bypass" modal dialog that appears, search for the role, team, or app you would like to grant bypass permissions, then select the role, team, or app from the "Suggestions" section and click **Add Selected**.
-   - The following are eligible for bypass access:
-     - Repository or organization owners.
-     - The maintain or write role, or custom repository roles based on the write role.
-     - Teams.
-     - {% data variables.product.prodname_github_apps %}.
+You can grant certain roles, teams, or apps bypass permissions for your ruleset. The following are eligible for bypass access:
+  - Repository admins or organization owners
+  - The maintain or write role, or custom repository roles based on the write role
+  - Teams
+  - {% data variables.product.prodname_github_apps %}
 
-   Optionally, to grant bypass to an actor without allowing them to push directly to a repository, select **Always** {% octicon "triangle-down" aria-hidden="true" %}, then click **For pull requests only**. That actor is now required to open a pull request to make changes to a repository, creating a clear digital trail with their changes. The actor can then choose to bypass any branch protections and merge that pull request.
+1. To grant bypass permissions for the ruleset, in the "Bypass list" section, click {% octicon "plus" aria-hidden="true" %} **Add bypass**.
+1. In the "Add bypass" modal dialog that appears, search for the role, team, or app you would like to grant bypass permissions, then select the role, team, or app from the "Suggestions" section and click **Add Selected**.
+1. Optionally, to grant bypass to an actor without allowing them to push directly to a repository, select **Always** {% octicon "triangle-down" aria-hidden="true" %}, then click **For pull requests only**.
+
+  The selected actor is now required to open a pull request to make changes to a repository, creating a clear digital trail with their changes. The actor can then choose to bypass any branch protections and merge that pull request.
diff --git a/data/reusables/repositories/rulesets-commit-regex.md b/data/reusables/repositories/rulesets-commit-regex.md
index 3c73ac70a3e9..7a48a7504c04 100644
--- a/data/reusables/repositories/rulesets-commit-regex.md
+++ b/data/reusables/repositories/rulesets-commit-regex.md
@@ -12,11 +12,11 @@ The negative lookahead assertion, denoted `?!`, is not supported. However, for c
 
 {% endnote %}
 
-### Useful regular expression patterns
+#### Useful regular expression patterns
 
 The following examples provide useful patterns for commit metadata. To use these patterns, set **Requirement** to "Must match a given regex pattern".
 
-#### Ensure branch names are compatible with Windows
+##### Ensure branch names are compatible with Windows
 
 You can use the following pattern to ensure that branch names only include numbers, lowercase letters, and the characters `-` and `_`. This ensures branch names are compatible with operating systems that do not use case-sensitive file systems by default.
 
@@ -28,7 +28,7 @@ Matches: `my-branch`
 
 Does not match: `myBranch`
 
-#### Ensure tag names use semantic versioning
+##### Ensure tag names use semantic versioning
 
 You can use the following pattern to ensure tag names conform to semantic versioning. For more information, see the documentation on [semver.org](https://semver.org/).
 
@@ -40,7 +40,7 @@ Matches: `1.2.3`, `10.20.30`, `1.1.2-prerelease+meta`
 
 Does not match: `1.2`, `1.2-SNAPSHOT`
 
-#### Limit length of lines in commit messages
+##### Limit length of lines in commit messages
 
 The [Pro Git book](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines) recommends limiting the first line of a commit message to around 50 characters.
 
@@ -50,7 +50,7 @@ You can use the following pattern to ensure the first line in a commit message c
 \A.{1,50}$
 ```
 
-#### Ensure commit messages start with a resolution and issue number
+##### Ensure commit messages start with a resolution and issue number
 
 You can use the following pattern to ensure that commit messages contain the word `Resolves:` or `Fixes:`, followed by a string like `#1234`.
 
@@ -62,7 +62,7 @@ Matches: `Fixes: #1234`
 
 Does not match: `Add conditional logic to foo.bar`
 
-#### Enforce conventional commits
+##### Enforce conventional commits
 
 You can use the following pattern to ensure that commit messages conform to the Conventional Commits specification. For more information, see [conventionalcommits.org](https://www.conventionalcommits.org/).
 
diff --git a/data/reusables/repositories/rulesets-create-and-insights-step.md b/data/reusables/repositories/rulesets-create-and-insights-step.md
new file mode 100644
index 000000000000..a00fd1f7fbfb
--- /dev/null
+++ b/data/reusables/repositories/rulesets-create-and-insights-step.md
@@ -0,0 +1,5 @@
+To finish creating your ruleset, click **Create**. If the enforcement status of the ruleset is set to "Active", the ruleset takes effect immediately.
+
+{% ifversion repo-rules-enterprise %}
+You can view insights for the ruleset to see how the rules are affecting your contributors. If the enforcement status is set to "Evaluate", you can see which actions would have passed or failed if the ruleset was active. For more information on insights for rulesets, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/managing-rulesets-for-a-repository#viewing-insights-for-rulesets)."
+{% endif %}
diff --git a/data/reusables/repositories/rulesets-create-step.md b/data/reusables/repositories/rulesets-create-step.md
deleted file mode 100644
index 4e3793c0cf02..000000000000
--- a/data/reusables/repositories/rulesets-create-step.md
+++ /dev/null
@@ -1 +0,0 @@
-1. To create the ruleset, click **Create**.
diff --git a/data/reusables/repositories/rulesets-general-step.md b/data/reusables/repositories/rulesets-general-step.md
index 70153c2b6798..6dbca92f28e2 100644
--- a/data/reusables/repositories/rulesets-general-step.md
+++ b/data/reusables/repositories/rulesets-general-step.md
@@ -1,3 +1,4 @@
-1. In the "General" section:
-   - Type a name for the ruleset.
-   - Select the enforcement status. You must set the status to **Active** if you want the ruleset to be enforced. {% ifversion repo-rules-enterprise %}Alternatively, if you set the status to **Evaluate**, the ruleset will not be enforced, but you will be able to monitor which actions would or would not violate rules on the "Rule Insights" page. For more information, see "[Viewing insights for rulesets](#viewing-insights-for-rulesets)."{% endif %}
+1. In the "General" section, type a name for the ruleset, then select {% octicon "skip" aria-hidden="true" %} **Disabled** {% octicon "triangle-down" aria-hidden="true" %} and click one of the following enforcement statuses:
+   - {% octicon "play" aria-hidden="true" %} **Active**: your ruleset will be enforced upon creation.{% ifversion repo-rules-enterprise %}
+   - {% octicon "meter" aria-hidden="true" %} **Evaluate**: your ruleset will not be enforced, but you will be able to monitor which actions would or would not violate rules on the "Rule Insights" page. For more information, see "[Viewing insights for rulesets](#viewing-insights-for-rulesets)."{% endif %}
+   - {% octicon "skip" aria-hidden="true" %} **Disabled**: your ruleset will not be enforced{% ifversion repo-rules-enterprise %} or evaluated{% endif %}.
diff --git a/data/reusables/repositories/rulesets-metadata-step.md b/data/reusables/repositories/rulesets-metadata-step.md
index 99375ed266c1..a5e9b705da65 100644
--- a/data/reusables/repositories/rulesets-metadata-step.md
+++ b/data/reusables/repositories/rulesets-metadata-step.md
@@ -1,10 +1,10 @@
+{% data reusables.repositories.rulesets-metadata-restrictions-notes %}
+
 1. Optionally, in the "Metadata restrictions" section, to add a rule to control the metadata of commits being pushed to the branch or tag, click {% octicon "plus" aria-label="Add metadata restriction" %}.
 
    ![Screenshot of the "Metadata restriction" section. To the right of the header, a plus icon is highlighted with an orange outline.](/assets/images/help/repository/add-metadata-restriction.png)
 
-{% indented_data_reference reusables.repositories.rulesets-metadata-restrictions-notes spaces=3 %}
-
-1. If you're adding a metadata restriction, configure the settings for the metadata restriction rule, then click **Add**. You can add multiple restrictions to the same ruleset.
+1. Configure the settings for the metadata restriction rule, then click **Add**. You can add multiple restrictions to the same ruleset.
 
    For most requirements, such as "Must start with a matching pattern," the pattern you enter is interpreted literally, and wildcards are not supported. For example, the `*` character only represents the literal `*` character.
 
diff --git a/data/reusables/repositories/rulesets-protections-step.md b/data/reusables/repositories/rulesets-protections-step.md
index de93bbefb349..916369403b43 100644
--- a/data/reusables/repositories/rulesets-protections-step.md
+++ b/data/reusables/repositories/rulesets-protections-step.md
@@ -1,9 +1,9 @@
-1. In the "Branch protections" or "Tag protections" section, select the rules you want to include in the ruleset. When you select a rule, you may be able to enter additional settings for the rule. For more information on the rules, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets)."
+In the "Branch protections" or "Tag protections" section, select the rules you want to include in the ruleset. When you select a rule, you may be able to enter additional settings for the rule. For more information on the rules, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets)."
 
-    {% note %}
+{% note %}
 
-    **Notes:** If you select **Require status checks before merging**, in the "Additional settings" section:
-       - You can enter the name of each status check you would like to require. To finish adding the status check as a requirement, you must click {% octicon "plus" aria-label="Add selected status checks" %}.
-       - If you select **Require branches to be up to date before merging**, you must define a check for the protection to take effect.
+**Notes:** If you select **Require status checks before merging**, in the "Additional settings" section:
+- You can enter the name of each status check you would like to require. To finish adding the status check as a requirement, you must click {% octicon "plus" aria-label="Add selected status checks" %}.
+- If you select **Require branches to be up to date before merging**, you must define a check for the protection to take effect.
 
-    {% endnote %}
+{% endnote %}
diff --git a/data/reusables/repositories/rulesets-sudo-mode.md b/data/reusables/repositories/rulesets-sudo-mode.md
deleted file mode 100644
index f999d4a4c3e2..000000000000
--- a/data/reusables/repositories/rulesets-sudo-mode.md
+++ /dev/null
@@ -1 +0,0 @@
-You may be prompted to confirm access to your account before you can create, edit, or delete a ruleset. For more information, see "[AUTOTITLE](/authentication/keeping-your-account-and-data-secure/sudo-mode)."
diff --git a/data/reusables/repositories/rulesets-target-branches.md b/data/reusables/repositories/rulesets-target-branches.md
index 3e11dc86033e..4532c5a3aaa7 100644
--- a/data/reusables/repositories/rulesets-target-branches.md
+++ b/data/reusables/repositories/rulesets-target-branches.md
@@ -1,3 +1,3 @@
-1. In the "Target branches" or "Target tags" section, select **Add a target**, then select how you want to include or exclude branches or tags. You can use `fnmatch` syntax to include or exclude branches or tags based on a pattern. For more information, see "[Using `fnmatch` syntax](#using-fnmatch-syntax)."
+To target branches or tags, in the "Target branches" or "Target tags" section, select **Add a target**, then select how you want to include or exclude branches or tags. You can use `fnmatch` syntax to include or exclude branches or tags based on a pattern. For more information, see "[Using `fnmatch` syntax](#using-fnmatch-syntax)."
 
-   You can add multiple targeting criteria to the same ruleset. For example, you could include the default branch, include any branches matching the pattern `*feature*`, and then specifically exclude a branch matching the pattern `not-a-feature`.
+You can add multiple targeting criteria to the same ruleset. For example, you could include the default branch, include any branches matching the pattern `*feature*`, and then specifically exclude a branch matching the pattern `not-a-feature`.