Merge branch 'main' into patch-1

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/dependabot.yml

@@ -18,8 +18,6 @@ updates:
     ignore:
       # Because this is so dependent on the remote server we use
       - dependency-name: '@elastic/elasticsearch'
-      # Because whatever we have needs to match what @primer/react also uses
-      - dependency-name: 'styled-components'
       - dependency-name: '*'
         update-types:
           ['version-update:semver-patch', 'version-update:semver-minor']

.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
@@ -95,17 +95,23 @@ Examples:
 
 ## Versioning
 
-Avoid `{% ifversion fpt %}`, `{% ifversion ghec %}`, and `{% ifversion fpt or ghec %}` in content files whenever possible. Instead of suggesting or adding version-gating within an article:
+Follow one of these sets of instructions, depending on how articles are versioned in the frontmatter. Articles may be versioned for FPT and GHEC, for GHES only, or for all three. Articles may also be versioned using feature-based versioning defined in `data/features`. Feature-based versioning allows centralized control of when content appears for specific GHES releases.
 
-* Write content that applies to all versions the article is versioned for
-* If content is truly version-specific, consider whether it is low-harm to show it to all readers (e.g., an enterprise-only row in a reference table)
-* Only use `{% ifversion %}` as a last resort when content would be actively misleading for readers on a different version
+### FPT/GHEC-only articles
 
-**FPT and GHEC content**: When dotcom content applies to both products, version the page for `fpt` and `ghec` in the frontmatter. Do NOT use in-article Liquid versioning. Do NOT suggest adding `{% ifversion fpt or ghec %}` blocks as a fix for content that mentions a dotcom-only feature. Instead, suggest rewriting the content using the alternatives to inline versioning options listed below.
+All articles that are ONLY for FPT and GHEC should be versioned for these versions in the frontmatter.
 
-**GHES content**: If versioning is necessary for GitHub Enterprise Server content, use feature-based versioning (FBV). GHES content should rely on feature flags defined in `data/features/` rather than inline `{% ifversion ghes %}` blocks. Feature flags allow centralized control of when content appears for specific GHES releases.
+For such content, DO NOT use in-article Liquid versioning such as `{% ifversion fpt %}`, `{% ifversion ghec %}`, and `{% ifversion fpt or ghec %}`.
 
-### Alternatives to inline versioning
+### GHES-only articles
+
+All articles that are ONLY for GitHub Enterprise Server (GHES) should be versioned in the frontmatter using feature-based versioning defined in `data/features/`. 
+
+### 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.
+
+#### Check in-article versioning is required
 
 Before resorting to in-article versioning, first consider whether the content is actually different across versions. Often procedures can be simplified to work at both levels.
 
@@ -127,26 +133,6 @@ Use these strategies instead of `{% ifversion %}`, depending on the level of con
 * End list items with "({% data variables.product.prodname_ghe_cloud %} only)", "({% data variables.product.prodname_dotcom_the_website %} only)", etc.
 * Specify if the feature is not available for GHES with "NAME-OF-FEATURE is not available for {% data variables.product.prodname_ghe_server %}", "... (not available in {% data variables.product.prodname_ghe_server %})", etc.
 
-### Example
-
-When documenting a feature that only applies to dotcom (not GHES):
-
-❌ Don't wrap content in version blocks:
-
-```markdown
-{% ifversion fpt or ghec %}
-
-## Immutable subject claims
-
-Repositories created after July 15, 2026 now use an immutable default subject format.
-
-{% endif %}
-```
-
-✅ Do use prose to indicate availability:
-
-```markdown
-## Immutable subject claims
+#### If in-article versioning is required
 
-Repositories created after July 15, 2026 now use an immutable default subject format. This rollout does not include {% data variables.product.prodname_ghe_server %}.
-```
+In-article versioning is required if a block of content in an article is definitely ONLY relevant for GHES, but the article itself is otherwise versioned in the frontmatter for all of FPT, GHEC, and GHES. In this situation, use feature-based versioning (FBV) wherever possible, using `{% ifversion FBV %}` blocks, where FBV is defined in `data/features/`. If it's not possible to use FBV, use {% ifversion ghes %} blocks, which will version the content block for all versions of GHES.

.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,7 +25,7 @@ jobs:
 
     steps:
       - name: Check out repo
-        uses: actions/checkout@8e8c483db84b4bee98b60c0593521ed34d9990e8 # v6.0.1
+        uses: actions/checkout@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0 # v7.0.0
 
       - name: Check team membership
         id: membership_check