[pull] main from github:main

.github/CODEOWNERS

@@ -6,9 +6,5 @@
 # Site Policy
 content/site-policy/ @github/site-policy-admins
 
-# Enterprise
-data/release-notes/**/*.yml @github/docs-content-enterprise
-src/ghes-releases/lib/enterprise-dates.json @github/docs-content-enterprise
-
 # Requires review of #actions-oidc-integration, docs-engineering/issues/1506
 # content/actions/deployment/security-hardening-your-deployments/** @github/oidc

.github/actions/create-workflow-failure-issue/action.yml

@@ -89,5 +89,6 @@ runs:
         gh issue create \
           --repo "$ISSUE_REPO" \
           --label "workflow-failure" \
+          --label "workflow-generated" \
           --title "[Workflow Failure] $WORKFLOW_NAME" \
           --body "$body"

.github/instructions/code.instructions.md

@@ -4,10 +4,11 @@ applyTo: "src/**,.github/**,config/**,.devcontainer/**,**Dockerfile,package*.jso
 
 # Copilot code instructions for docs.github.com
 
-For code reviews, follow guidelines, tests, and validate instructions. For creating or updating pull requests or branches, follow the steps instructions.
+For code reviews and for creating or updating pull requests, follow the Guidelines, Tests, and Validate sections below.
 
 ## Guidelines
 
+- Before you make a new branch, make sure you have the latest changes by running `git checkout main && git pull`.
 - If available, use ripgrep (`rg`) instead of `grep`.
 - When using gh cli in double-quoted strings, escape backticks to prevent bash command substitution. In single-quoted strings, backticks do not need escaping.
 - All scripts should be listed in `package.json` and use `tsx`.
@@ -17,6 +18,9 @@ For code reviews, follow guidelines, tests, and validate instructions. For creat
 - We use absolute imports, relative to the `src` directory, using the `@` symbol. For example, `getRedirect` which lives in `src/redirects/lib/get-redirect.ts` can be imported with `import getRedirect from '@/redirects/lib/get-redirect'`. The same rule applies for TypeScript (`.ts`) imports, e.g. `import type { GeneralSearchHit } from '@/search/types'`
 - For updates to the content linter, read important information in `src/content-linter/README.md`.
 - Do not use git force push, and avoid git rebase.
+- When reading issues and pull requests, read all comments as well.
+- When you are updating an existing pull request, after you commit and push, _concisely_ comment on the pull request that you are GitHub Copilot and what changes you made and why.
+- When running in agentic mode, offer the human the option to wait for and review CI checks and automatic Copilot code review comments.
 
 ## Tests
 
@@ -79,30 +83,6 @@ Run the following commands to validate your changes:
 - `npm run prettier`
 - `npm run lint`: you can include `-- --fix`
 
-## Steps
-
-0. Ask the human if they would like you to follow these steps.
-1. If this is new work, make sure you have the latest changes by running `git checkout main && git pull`. If this is existing work, update the branch you are working on with the head branch -- usually `main`.
-2. If the human provides a GitHub issue, use MCP or gh cli to read the issue and all comments.
-3. Begin by evaluating impact, effort, and estimate non-test lines of code that will change. Ask for more context and examples if needed.
-4. If you are running in agentic mode, _stop_ at this point and request approval from the human.
-5. If you need to add or change tests, work on tests before implementing.
-6. Implement the changes needed. If you are running in agentic mode, _stop_ and ask questions at decision points. Please list the options, pros and cons for each decision needed.
-7. Validate your changes before making any commits. See "Validate".
-8. Validate that any new or changed tests pass. See "Tests".
-9. Validate that these changes meet our guidelines. See "Guidelines".
-10. If you are running in agentic mode, _stop_ at this point and request review before continuing. Suggest how the human should review the changes.
-11. If a branch and pull request already exist, commit and push, then _concisely_ comment on the pull request that you are GitHub Copilot and what changes you made and why.
-12. If this is new work and no pull request exists yet, make a pull request:
-    - label "llm-generated"
-    - draft mode
-    - include "fixes owner/repo#issue" or "towards owner/repo#issue" as appropriate
-13. If you are in agentic mode, offer to wait for CI to run and check that it passes. If the human agrees, verify in CI: `sleep 240 && gh pr checks $number`. Address all failures, don't assume they're flakes.
-14. If you are in agentic mode, offer to do any or all of:
-    - mark the pull request as ready,
-    - assign the issue to the human if it is not already assigned,
-    - _concisely_ comment on the issue explaining the change, indicating you are GitHub Copilot.
-
 ## Logger
 
 Use `createLogger` from `@/observability/logger` instead of `console.log` in server-side code.

.github/workflows/orphaned-files-check.yml

@@ -1,6 +1,6 @@
 name: 'Orphaned files check'
 
-# **What it does**: Checks that there are no files in ./assets/ and ./data/reusables that aren't mentioned in any source file.
+# **What it does**: Checks that there are no files in ./assets/, ./data/reusables, or ./data/tables that aren't mentioned in any source file.
 # **Why we have it**: To avoid orphans into the repo.
 # **Who does it impact**: Docs content.
 
@@ -16,6 +16,7 @@ on:
       - 'package*.json'
       - src/assets/scripts/find-orphaned-assets.ts
       - src/content-render/scripts/reusables-cli/find/unused.ts
+      - src/data-directory/scripts/find-orphaned-tables.ts
       - src/workflows/walk-files.ts
       - src/languages/lib/languages.ts
       - .github/actions/clone-translations/action.yml
@@ -67,14 +68,18 @@ jobs:
           # information about the npm script alias.
           assetFilesToRemove=$(npm run -s find-orphaned-assets)
           reusableFilesToRemove=$(npm run -s reusables -- find unused | grep '^data/reusables' || true)
-          [ -z "$assetFilesToRemove" ] && [ -z "$reusableFilesToRemove" ] && exit 0
+          tableFilesToRemove=$(npm run -s find-orphaned-tables)
+          [ -z "$assetFilesToRemove" ] && [ -z "$reusableFilesToRemove" ] && [ -z "$tableFilesToRemove" ] && exit 0
 
           if [ -n "$assetFilesToRemove" ]; then
             echo $assetFilesToRemove | xargs git rm
           fi
           if [ -n "$reusableFilesToRemove" ]; then
             echo $reusableFilesToRemove | xargs git rm
           fi
+          if [ -n "$tableFilesToRemove" ]; then
+            echo $tableFilesToRemove | xargs git rm
+          fi
 
           git status
 
@@ -100,11 +105,11 @@ jobs:
           git push origin $branchname
 
           body=$(cat <<-EOM
-            Found with the `npm run find-orphaned-assets` and `npm run -s reusables -- find unused` scripts.
+            Found with the `npm run find-orphaned-assets`, `npm run -s reusables -- find unused`, and `npm run find-orphaned-tables` scripts.
 
             The orphaned files workflow file .github/workflows/orphaned-files-check.yml runs every Monday at 16:20 UTC / 8:20 PST.
 
-            If you are the first responder, please spot check some of the unused assets to make sure they aren't referenced anywhere. Then, approve and merge the pull request.
+            If you are the first responder, please spot check some of the unused assets, reusables, and tables to make sure they aren't referenced anywhere. Then, approve and merge the pull request.
 
             For more information, see [Doc: Orphaned Assets](https://github.com/github/docs-engineering/blob/main/docs/orphaned-assets.md) and [Doc: Reusables CLI](https://github.com/github/docs-internal/tree/main/src/content-render/scripts/reusables-cli).
 

.github/workflows/purge-fastly.yml

@@ -38,23 +38,47 @@ jobs:
 
       - uses: ./.github/actions/node-npm-setup
 
-      - name: Wait for production to match build number
+      - name: Wait for production to match build commit SHA
         if: github.event_name != 'workflow_dispatch'
+        # A single /_build match only proves *one* Moda instance is serving the
+        # new build; others can still be mid-rollout. If we purge then, Fastly's
+        # soft purge serves stale-while-revalidate and may revalidate against a
+        # lagging instance, re-caching old content as fresh for a full TTL. So we
+        # require several consecutive matches to confirm the rollout has settled
+        # across instances before purging.
         run: |
           needs=$(git rev-parse HEAD)
           start_time=$(date +%s)
           timeout_seconds=1200
-          while [[ $needs != $(curl -s --fail --retry-connrefused --retry 5 https://docs.github.com/_build) ]]
+          required_matches=5
+          interval_seconds=10
+          consecutive=0
+          while [[ $consecutive -lt $required_matches ]]
           do
             if [[ $(($(date +%s) - $start_time)) -gt $timeout_seconds ]]
             then
-              echo "Production did not match the build number within $timeout_seconds seconds"
+              echo "Production did not reach $required_matches consecutive build matches within $timeout_seconds seconds"
               exit 1
             fi
-            echo "Production is not up to date with the build commit"
-            sleep 10
+            if [[ $needs == $(curl -s --fail --retry-connrefused --retry 5 https://docs.github.com/_build) ]]
+            then
+              consecutive=$((consecutive + 1))
+              echo "Production matches the build commit ($consecutive/$required_matches)"
+            else
+              if [[ $consecutive -gt 0 ]]
+              then
+                echo "Production stopped matching the build commit; resetting consecutive count"
+              else
+                echo "Production is not up to date with the build commit"
+              fi
+              consecutive=0
+            fi
+            if [[ $consecutive -lt $required_matches ]]
+            then
+              sleep $interval_seconds
+            fi
           done
-          echo "Production is up to date with the build commit"
+          echo "Production is up to date with the build commit ($required_matches consecutive matches)"
 
       - name: Purge Fastly edge cache per language
         env:

.github/workflows/test.yml

@@ -3,6 +3,9 @@ name: Test
 # **What it does**: Runs our tests.
 # **Why we have it**: We want our tests to pass before merging code.
 # **Who does it impact**: Docs engineering, open-source engineering contributors.
+#
+# For a catalog of what each suite covers and how risky it is to admin-merge
+# past it when red, see src/tests/SUITES.md.
 
 on:
   workflow_dispatch:

content/actions/reference/runners/larger-runners.md

@@ -40,9 +40,7 @@ You can choose from several specifications for {% data variables.actions.hosted_
 | 64  | 256 GB        | 2040 GB       | x64          | Ubuntu, Windows       |
 | 96 | 384 GB         | 2040 GB       | x64          | Ubuntu, Windows        |
 
->[!NOTE] The 4-vCPU Windows runner only works with the Windows Server 2025 or the Base Windows 11 Desktop image.
-
->[!NOTE] The 5-vCPU macOS runner is in public preview and subject to change.
+> [!NOTE] The 4-vCPU Windows runner only works with the Windows Server 2025 or the Base Windows 11 Desktop image.
 
 ### Specifications for GPU {% data variables.actions.hosted_runners %}
 

content/communities/moderating-comments-and-conversations/limiting-interactions-in-your-repository.md

@@ -37,6 +37,8 @@ In a public repository, you can set a maximum number of pull requests that a use
 
 This setting helps maintainers manage contribution volume by preventing users from opening an excessive number of pull requests, which can overwhelm review queues and trigger unnecessary CI runs. The limit only applies to users without write access — users with write access or higher are not affected.
 
+Draft pull requests do not count toward a user's limit. Only open, non-draft pull requests are counted when determining whether a user has reached the maximum.
+
 ### Adding trusted contributors to the bypass list
 
 Rather than granting full collaborator access, you can add trusted contributors to a bypass list, allowing them to exceed the pull request limit while keeping their permissions otherwise unchanged. This bypass is ideal for regular external contributors who routinely open multiple pull requests but do not need the additional permissions that come with collaborator access.

content/copilot/concepts/agents/about-enterprise-plugin-standards.md

@@ -30,7 +30,7 @@ Users must upgrade to a supported client version for these standards to be appli
 
 ## How plugin standards work
 
-Enterprise plugin standards use a configuration file stored in your enterprise's `.github-private` repository. The configuration is defined in a `{% data variables.copilot.managed_setting_file %}` file at the following path: `.github/copilot/{% data variables.copilot.managed_setting_file %}`. This file was previously called `settings.json`, which is still supported.
+Enterprise plugin standards use a configuration file stored in your enterprise's `.github-private` repository. The configuration is defined in a `{% data variables.copilot.managed_setting_file %}` file at the following path: `copilot/{% data variables.copilot.managed_setting_file %}`. The legacy file path of `.github/copilot/settings.json` is also supported.
 
 For plugin standards, the file can define:
 

content/copilot/concepts/agents/github-copilot-app.md

@@ -12,17 +12,18 @@ category:
   - Learn about Copilot
 ---
 
-> [!NOTE] The {% data variables.copilot.github_copilot_app %} is in {% data variables.release-phases.technical_preview %} and subject to change.
->
-> * **Existing {% data variables.copilot.copilot_business_short %}, {% data variables.copilot.copilot_enterprise_short %}, {% data variables.copilot.copilot_pro_short %}, and {% data variables.copilot.copilot_pro_plus_short %} users** — Download and install from the [{% data variables.copilot.github_copilot_app %} repository](https://gh.io/github-copilot-app-repo?utm_source=docs-about-github-copilot-app-repo&utm_medium=docs&utm_campaign=msbuild-2026). For {% data variables.copilot.copilot_business_short %} and {% data variables.copilot.copilot_enterprise_short %}, your organization or enterprise must enable preview features and {% data variables.copilot.copilot_cli_short %}.
-> * **{% data variables.copilot.copilot_free_short %} users and users without a {% data variables.product.prodname_copilot_short %} plan** do not currently have access to the {% data variables.copilot.github_copilot_app %}. Access is expected to expand over time.
+Install the app from the [download page for {% data variables.copilot.github_copilot_app %}](https://gh.io/app).
 
 ## Introduction
 
 The {% data variables.copilot.github_copilot_app %} is a desktop application purpose-built for agent-driven development. It gives you a single place to direct AI agents across parallel workstreams, work with {% data variables.product.github %} issues and pull requests, and manage the full development lifecycle—without context-switching between terminals, IDEs, and browser tabs.
 
 The app is built on {% data variables.copilot.copilot_cli %} and integrates natively with {% data variables.product.github %}, so your repositories, branches, and CI pipelines work out of the box. It's designed for workflows where you want to run multiple agents in parallel and stay focused on directing work rather than doing it all yourself.
 
+## Availability
+
+{% data reusables.gated-features.github-app %} {% data variables.copilot.copilot_business_short %} and {% data variables.copilot.copilot_enterprise_short %} users must have the {% data variables.copilot.copilot_cli_short %} policy enabled by an administrator.
+
 ## Supported operating systems
 
 The {% data variables.copilot.github_copilot_app %} supports the following operating systems:
@@ -62,9 +63,21 @@ A typical workflow in the {% data variables.copilot.github_copilot_app %} looks
 
 You can run several of these workflows in parallel, each in its own workspace, and switch between them as needed.
 
+## Optimizing AI usage in the {% data variables.copilot.github_copilot_app %}
+
+Follow these practices to use {% data variables.product.prodname_ai_credits_short %} more efficiently in the app:
+
+* **Match model capability to task complexity.** Use lighter models for straightforward changes and higher-capability models for complex debugging, design decisions, and multi-step tasks.
+* **Choose the right session mode for the stage of work.** Use **Plan** mode to validate scope and approach, use **Interactive** mode when you want tighter steering, and move to **Autopilot** when the task is well-defined.
+* **Use quick chats to scope before opening a full session.** For early exploration, use **Quick chats** to clarify requirements and reduce rework before creating a dedicated session.
+* **Start a new session when you switch tasks.** A new session keeps context focused and avoids carrying irrelevant history into unrelated work.
+* **Use usage insights regularly.** Run `/chronicle cost tips` to find expensive patterns in your session usage and improve efficiency over time.
+
+For more detailed optimization tips, see [AUTOTITLE](/copilot/tutorials/optimize-ai-usage).
+
 ## Providing feedback
 
-The {% data variables.copilot.github_copilot_app %} is in {% data variables.release-phases.technical_preview %}. To share feedback, click the **Give feedback** icon in the bottom-left corner of the app.
+To share feedback, click the **Give feedback** icon in the bottom-left corner of the app.
 
 ## Public code