Merge branch 'main' into fix-github-pro-upgrade-flow

Author: Sharra-writes

.github/CONTRIBUTING.md

@@ -78,7 +78,7 @@ For complete style guidance, see our [style guide](https://docs.github.com/en/co
 
 <img src="/contributing/images/contribution_cta.png" />
 
-**Make changes in a codespace:** See "[Working in a codespace](https://github.com/github/docs/blob/main/contributing/codespace.md)" for documentation-specific setup.
+**Make changes in a codespace:** See "[Working on GitHub Docs in a codespace](https://docs.github.com/en/contributing/setting-up-your-environment-to-work-on-github-docs/working-on-github-docs-in-a-codespace)" for documentation-specific setup.
 
 **Make changes locally:** 
 1. Fork the repository (see [official forking guide](https://docs.github.com/en/contributing))

.github/agents/driver-writer.md

@@ -0,0 +1,70 @@
+---
+
+name: "Driver-writer"
+description: "Use when writing, editing, or reviewing content for the Driver persona: enterprise administrators, platform engineers, billing managers, security leads, and others who enable developers at scale."
+
+---
+
+# Driver-writer Agent
+
+You are a writing assistant for the GitHub Docs team. You help writers create, edit, and review documentation that serves the **Driver persona**.
+
+A Driver is any GitHub user who supports the work of multiple developers by making changes to GitHub at scale. They remove barriers and enable developers to work efficiently while providing guardrails for compliance and security. Drivers include enterprise administrators, billing managers, application security leads, CI/CD administrators, tech leads, and OS maintainers.
+
+Our team prioritizes **self-serve enterprise customers** that use GitHub Enterprise but are not large enough to get dedicated support from a GitHub sales or success team. These customers rely heavily on documentation to set up and manage their enterprise. When making content decisions, optimize for this audience.
+
+Drivers come from two broad backgrounds, and content should account for both:
+
+* **IT administration**: Expects process and controls based on experience with other enterprise systems. May use terminology from other platforms when searching for information.
+* **Development**: Fewer preconceptions about enterprise administration. May have limited knowledge of best practices for setting up large systems.
+
+## What makes Driver content different
+
+Driver content is distinct from developer-focused (Builder) content in a few key ways. Apply these when writing or editing:
+
+### Frame value in terms of the enterprise, not individual productivity
+
+Builder content connects features to the developer's own workflow. Driver content should connect features to what Drivers care about: compliance, security posture, cost management, developer enablement at scale, and reducing operational risk.
+
+* Instead of: "You can restrict email notifications for your enterprise."
+* Write: "You can prevent your enterprise's information from leaking into personal email accounts."
+
+### Help Drivers make confident decisions
+
+Drivers often face choices with long-lasting, hard-to-reverse consequences (e.g., choosing between EMU and classic authentication, selecting an identity provider, structuring enterprises and organizations). Content should present enough context for the reader to choose confidently: what the tradeoffs are, what most enterprises do, and what cannot be changed later.
+
+### Write for people who manage GitHub, not people who use it to code
+
+Drivers are configuring, monitoring, and governing, not writing code. They are less likely to want code examples and more likely to need:
+
+* Clear explanations of how settings interact and propagate across an enterprise
+* Guidance on rollout sequence and dependencies between configuration steps
+* Visibility into what their developers will experience as a result of their changes
+
+### Be explicit about policy scope and cascade
+
+When writing about enterprise settings or policies, always clarify what level the setting operates at (enterprise, organization, repository) and how it cascades. Make it clear who controls the setting and whether lower levels can override it. When parallel articles exist for different levels (e.g., enterprise vs. org), keep the structure, terminology, and level of detail consistent between them.
+
+### Flag specific high-risk claims for verification
+
+Driver actions often affect an entire enterprise and can be hard to reverse, so a single inaccurate detail can have outsized consequences: a security gap, a compliance failure, unexpected cost, or an administrator locking themselves out. Do not flag an entire article as high-risk just because of its topic. Instead, identify the specific claims most likely to cause harm if wrong, and call each one out individually for the writer to verify.
+
+Pay closest attention to discrete, checkable claims in these areas:
+
+* Authentication and identity (e.g., specific SAML/SCIM attribute values, SSO setup steps)
+* Security and compliance policy behavior and enforcement
+* Billing, licensing, and spending controls (specific numbers, thresholds, what counts toward usage)
+* Irreversible or enterprise-wide configuration steps
+* Exact permission or role requirements for an action
+
+For example, in an article about configuring SSO, do not say "verify this entire article." Instead, flag the specific risky claims, e.g.: "Step 6 says to set the SAML `NameID` to the user's email. Confirm the exact required attribute with the identity team, since the wrong value will block all sign-ins."
+
+## Driver user journey
+
+Drivers move through these phases with GitHub. Content should meet them where they are:
+
+* **Evaluate**: Researching tools that add value for the team.
+* **Onboard**: Understanding best practices to configure the enterprise. Relying on documentation before reaching out to people.
+* **Adopt**: Monitoring rollout, managing licenses, evaluating ROI.
+* **Optimize**: Monitoring data, auditing configuration for efficiency.
+* **Sustain**: Promoting best practices, making minimal configuration changes.

.github/instructions/content-guidelines.instructions.md

@@ -0,0 +1,60 @@
+---
+applyTo: "content/**,data/reusables/**"
+---
+
+# Content guidelines for docs.github.com
+
+**When to use**: Writing, editing, or reviewing documentation articles and reusable prose. These are strategic content rules: what to write and how to focus an article.
+
+When asked to work on one part of a larger article, read the whole article first so you can judge whether it meets these guidelines as a whole.
+
+**How to apply these guidelines**: Treat them as strategic suggestions to weigh per article, not mechanical rules to enforce. The right emphasis depends on the article's content type (procedural, conceptual, or reference), so use judgment and stay silent when a guideline does not cleanly apply, rather than flagging or rewriting reflexively.
+
+## Keep only essential content
+
+The strategic priority is simplification: create less content and remove content that is not essential, so readers can navigate higher-value content more easily. Flag content to trim or remove by asking:
+
+* Does it serve a large or high-value audience, rather than an edge case the company does not prioritize?
+* Does it help people use GitHub the way we want them to, rather than documenting every possible use?
+* Would a typical internet user figure this out on their own by exploring the UI?
+* Is the information presented at the moment the reader actually needs it?
+
+## Intros: pull people in
+
+This section applies mainly to the `intro` frontmatter field and, for conceptual articles, section openings.
+
+* Open with the value the reader gets, and the product that delivers it, rather than a restatement of the task or a bare feature name. Technical detail is not bad and belongs in the article; it just should not be the first thing the reader sees when a value-led opening is possible.
+* Do not repeat the wording of the title.
+* Do not start with "Learn how to..."; it buries the value.
+* When conceptual and procedural articles cover the same topic, differentiate them through sentence structure. Conceptual describes what the thing is and why it matters ("{% data variables.product.prodname_copilot %} is an AI coding assistant that helps you write code faster."). Procedural describes what the reader will do and the value they get ("Start using {% data variables.product.prodname_copilot %} to write code faster.").
+
+Examples of strong intros by content type:
+
+* **Conceptual** ("Larger runners"): "Organize and govern your workflows with larger runners using runner groups, concurrency policies, and granular access controls."
+* **Procedural** ("Running jobs on larger runners"): "Route jobs to the right machines by using runner groups and workflow labels."
+* **Reference** ("Supported AI models in {% data variables.product.prodname_copilot %}"): "Identify which AI models are supported in {% data variables.product.prodname_copilot %} for each client and plan."
+
+## Drive people to the product
+
+* Every article should move the reader to try or use the product, directly or indirectly. Even reference articles do this: readers consult them in order to use the product, so the support is built in and a separate CTA is often unnecessary.
+* Only include a CTA link when it genuinely makes the reader's task easier, for example by saving them the time of navigating to a settings page themselves. Do not force a CTA; if none would genuinely help the reader, do not add one. Avoid turning articles into clickbait.
+* A CTA can take several forms, for example a direct link to the relevant product or feature, a Copilot prompt the reader can run, or a link to start a free trial.
+* Only link to a URL that is the same for everyone on that version. Do not add a CTA when the in-product URL must include an enterprise, organization, or repository name (for example, `https://github.com/ORG/REPO/settings/copilot/code_review`), because the link cannot be made to work for all readers.
+* Procedural articles: include a CTA wherever one genuinely helps, as directly as possible.
+* Conceptual articles: point the reader to exactly one clear next step, usually a link to the related procedure (for example, an "About pull requests" article points to "Creating a pull request"). Place it where the reader is ready to act, typically at the end of the article.
+
+## Energy and tone
+
+These apply to the prose in an article (intros and explanatory text), not to structural elements like tables, procedural steps, or code.
+
+* Lead with value and real-life impact over technical detail.
+* Connect features to the reader's real-life problems to generate genuine interest.
+* Use plain, friendly, approachable language. Avoid marketing jargon, buzzwords, and inflated adjectives.
+
+## Scannability
+
+* Give each article exactly one purpose, regardless of content type. That purpose may be physical (e.g., enabling a setting), conceptual (e.g., building a mental model of what a feature does and why it matters, choosing between two options), or referential (e.g., determining which AI models are available to the reader). Include only information central to that purpose for most readers.
+* Write for the one reader scenario the article targets, for example a particular deployment configuration (GHEC with EMUs vs. Classic) or a particular type of reader (an open source maintainer vs. an enterprise developer). When the article has a content design plan, target the audience it identifies rather than inventing one; for small edits without a plan, follow the audience the existing article is clearly written for. Do not branch content to serve multiple audiences; readers in other scenarios can adapt the guidance. The exception is version differences: when in-article `{% ifversion %}` branching is genuinely required (see the versioning rules in `content.instructions.md`), it is not a scannability violation.
+* Ruthlessly minimize links. Only link when you actively want most readers to follow it in the ideal scenario. No "just in case" links. Links that build a logical user journey are exactly the kind to keep, for example a Prerequisites link that sends the reader to setup they need first, or a Next steps link that points them to the natural follow-on task.
+* Ruthlessly minimize alerts (notes, tips, warnings): more than one per article should be exceptional, and crowding several into one section is worse than spreading them out. Keep each to 1-2 sentences. Don't open an article or section with an alert unless the reader needs it before the surrounding content. Prefer folding a useful alert into the prose over deleting it, but first apply this test: if the reader must actually notice it to use the page correctly, keep it as an alert (don't fold or count it), since folding defeats its purpose. This covers, for example, critical warnings, plan or availability constraints, public preview notices, and cues that orient the reader to how the page works or which content applies to them.
+* Prefer short sentences and paragraphs, generous white space, and formatting like bold and tables to highlight key information. Use a table only for genuinely complex data that belongs in a tabular format; do not add a table that repeats information already stated more clearly in prose.

.github/instructions/content.instructions.md

@@ -1,5 +1,5 @@
 ---
-applyTo: "content/**,data/**,**/*.md"
+applyTo: "content/**,data/**"
 ---
 
 # Copilot content instructions for docs.github.com
@@ -16,6 +16,14 @@ Before committing content changes, always:
 3. **Verify [AUTOTITLE] links** point to existing articles
 4. **Run tests** on changed content: `npm run test -- src/content-render/tests/render-changed-and-deleted-files.ts`
 
+## Accuracy and flagging uncertainty
+
+AI assistants can produce plausible but incorrect information. To protect readers and writers:
+
+* Never fabricate product behavior, settings, permissions, API parameters, or limits. If you cannot verify a detail from the source material or the product itself, say so instead of guessing.
+* Flag uncertainty at the level of the specific claim, not the whole article. Identify the individual sentence, step, value, or setting you are unsure about, rather than labeling an entire article as "needs review."
+* After writing or editing, give the writer a checklist of each specific claim to verify, noting where it appears (the exact step or sentence) and why it needs checking. Prioritize claims where being wrong could have serious consequences, such as security, authentication, permissions, billing, or any irreversible action, and recommend confirming those with the relevant product or engineering team.
+
 ## Bullet lists
 
 The bulleted points in a bullet list should always be denoted in Markdown using an asterisk, not a hyphen.
@@ -107,6 +115,17 @@ For such content, DO NOT use in-article Liquid versioning such as `{% ifversion
 
 All articles that are ONLY for GitHub Enterprise Server (GHES) should be versioned in the frontmatter using feature-based versioning defined in `data/features/`. 
 
+### Versioning for GHES content: always use feature-based versioning
+
+If content is intended to ship to GitHub Enterprise Server, use **feature-based versioning (FBV)**.
+
+* Do **not** suggest removing GHES frontmatter versioning or hardcode version strings (for example, `free-pro-team@latest`) just to make links or tests pass.
+* If CI fails because a GHES link cannot be built, treat that as a versioning mismatch—not a signal to de-scope GHES.
+* Add or reuse the appropriate feature flag in `data/features/`. Use it in `versions.feature` frontmatter when an article's availability follows the feature, and use Liquid conditionals only for version-specific blocks within a broader article.
+* Keep frontmatter and in-article versioning aligned so links render for every supported version.
+
+For guidance, see [About feature-based versioning](https://docs.github.com/en/contributing/writing-for-github-docs/versioning-documentation#about-feature-based-versioning).
+
 ### FPT, GHEC, GHES articles
 
 All articles that are versioned for all of FPT, GHEC, and GHES in the frontmatter MAY require certain blocks of content to be versioned using in-article Liquid versioning. Before recommending this, check if this is really the case.

.github/instructions/style-guide-summary.instructions.md

@@ -1,5 +1,5 @@
 ---
-applyTo: "content/**,data/**,**/*.md"
+applyTo: "content/**,data/**"
 ---
 
 # Concise style guide for docs.github.com

.github/workflows/all-documents.yml

@@ -20,7 +20,7 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: Check out repo
-        uses: actions/checkout@8e8c483db84b4bee98b60c0593521ed34d9990e8 # v6.0.1
+        uses: actions/checkout@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0 # v7.0.0
 
       - uses: ./.github/actions/node-npm-setup
 

.github/workflows/article-api-docs.yml

@@ -22,7 +22,7 @@ jobs:
     if: github.repository == 'github/docs-internal' || github.repository == 'github/docs'
     steps:
       - name: Checkout
-        uses: actions/checkout@8e8c483db84b4bee98b60c0593521ed34d9990e8 # v6.0.1
+        uses: actions/checkout@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0 # v7.0.0
 
       - uses: ./.github/actions/node-npm-setup
 

.github/workflows/auto-add-ready-for-doc-review.yml

@@ -25,13 +25,20 @@ jobs:
 
     steps:
       - name: Check out repo
-        uses: actions/checkout@8e8c483db84b4bee98b60c0593521ed34d9990e8 # v6.0.1
+        uses: actions/checkout@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0 # v7.0.0
+
+      - name: Generate GitHub App token
+        id: app-token
+        uses: actions/create-github-app-token@bcd2ba49218906704ab6c1aa796996da409d3eb1 # v3.2.0
+        with:
+          app-id: ${{ secrets.DOCS_BOT_APP_ID }}
+          private-key: ${{ secrets.DOCS_BOT_APP_PRIVATE_KEY }}
 
       - name: Check team membership
         id: membership_check
         uses: actions/github-script@3a2844b7e9c422d3c10d287c895573f7108da1b3 # v9.0.0
         with:
-          github-token: ${{ secrets.DOCS_BOT_PAT_BASE }}
+          github-token: ${{ steps.app-token.outputs.token }}
           script: |
             try {
               await github.rest.teams.getMembershipForUserInOrg({
@@ -48,7 +55,7 @@ jobs:
       - name: Add ready-for-doc-review label
         if: steps.membership_check.outputs.result == 'false'
         env:
-          GITHUB_TOKEN: ${{ secrets.DOCS_BOT_PAT_BASE }}
+          GITHUB_TOKEN: ${{ steps.app-token.outputs.token }}
           PR_URL: ${{ github.event.pull_request.html_url }}
         run: |
           gh pr edit $PR_URL --add-label ready-for-doc-review

.github/workflows/benchmark-pages.yml

@@ -21,7 +21,7 @@ jobs:
       ISSUE_REPO: github/docs-engineering
     steps:
       - name: Checkout
-        uses: actions/checkout@8e8c483db84b4bee98b60c0593521ed34d9990e8 # v6.0.1
+        uses: actions/checkout@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0 # v7.0.0
         with:
           persist-credentials: 'false'
       - name: Generate GitHub App token