Merge branch 'main' into patch-1

Author: subatoi

.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/CONTRIBUTING.md

@@ -78,11 +78,11 @@ 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))
-2. Install Node.js at the version specified in `.node-version` (see [development guide](../contributing/development.md))
+2. Install Node.js at the version specified in `package.json` (see [development guide](../contributing/development.md))
 3. Create a working branch and start with your changes
 
 ### Commit your update
@@ -100,7 +100,7 @@ Use our "[Self review checklist](https://docs.github.com/en/contributing/collabo
 - [Link PR to issue](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue) if applicable
 - Enable [maintainer edits](https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/allowing-changes-to-a-pull-request-branch-created-from-a-fork)
 
-A Docs team member will review following our [standard review process](https://docs.github.com/en/contributing).
+A Technical Content team member will review following our [standard review process](https://docs.github.com/en/contributing).
 
 ### Your PR is merged!
 

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

@@ -10,6 +10,11 @@ inputs:
     default: github/docs-engineering
     required: false
 
+outputs:
+  issue_url:
+    description: URL of the created or updated workflow-failure issue (empty if creation failed).
+    value: ${{ steps.create-new.outputs.issue_url || steps.comment-existing.outputs.issue_url }}
+
 runs:
   using: composite
   steps:
@@ -31,6 +36,7 @@ runs:
         echo "existing_issue=$existing" >> "$GITHUB_OUTPUT"
 
     - name: Comment on existing issue
+      id: comment-existing
       if: steps.check-existing.outputs.existing_issue != ''
       shell: bash
       env:
@@ -57,8 +63,10 @@ runs:
         gh issue comment "$ISSUE_NUMBER" \
           --repo "$ISSUE_REPO" \
           --body "$body"
+        echo "issue_url=$GITHUB_SERVER_URL/$ISSUE_REPO/issues/$ISSUE_NUMBER" >> "$GITHUB_OUTPUT"
 
     - name: Create workflow failure issue
+      id: create-new
       if: steps.check-existing.outputs.existing_issue == ''
       shell: bash
       env:
@@ -86,8 +94,10 @@ runs:
         This issue was automatically created by the create-workflow-failure-issue action to enable automated diagnosis.
         EOF
         )
-        gh issue create \
+        url=$(gh issue create \
           --repo "$ISSUE_REPO" \
           --label "workflow-failure" \
+          --label "workflow-generated" \
           --title "[Workflow Failure] $WORKFLOW_NAME" \
-          --body "$body"
+          --body "$body")
+        echo "issue_url=$url" >> "$GITHUB_OUTPUT"

.github/actions/slack-alert/action.yml

@@ -10,13 +10,61 @@ inputs:
     default: CG5MJHMB2 # docs-alerts
     required: false
   message:
-    description: The message to send to Slack
-    default: The last '${{ github.workflow }}' run failed. See ${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}
+    description: >-
+      Optional message override. When set, it is sent verbatim. When empty (the
+      default), a standard multi-line failure message is built from the run
+      context, plus a link to the failure issue if issue_url is provided.
+    default: ''
+    required: false
+  issue_url:
+    description: >-
+      Optional link to the tracking failure issue (e.g. the output of the
+      create-workflow-failure-issue action). Appended to the default message.
+      Ignored when a custom message is provided.
+    default: ''
     required: false
 
 runs:
   using: composite
   steps:
+    # Build the Slack text here so the default message can be multi-line (real
+    # newlines) and conditionally include the issue link. A caller-supplied
+    # message is passed through verbatim for backward compatibility.
+    - name: Build Slack message
+      id: build
+      shell: bash
+      env:
+        MESSAGE: ${{ inputs.message }}
+        ISSUE_URL: ${{ inputs.issue_url }}
+        SOURCE_REPO: ${{ github.repository }}
+        WORKFLOW_NAME: ${{ github.workflow }}
+        RUN_URL: ${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}
+        EVENT_NAME: ${{ github.event_name }}
+        GIT_REF: ${{ github.ref }}
+        ACTOR: ${{ github.actor }}
+      run: |
+        # Escape Slack mrkdwn control chars in interpolated context fields so a
+        # crafted branch/ref (e.g. containing <!channel>) can't inject mentions.
+        esc() { printf '%s' "$1" | sed -e 's/&/\&amp;/g' -e 's/</\&lt;/g' -e 's/>/\&gt;/g'; }
+        # Unique heredoc delimiter so a custom message can't collide with it.
+        delim="SLACK_EOF_${RANDOM}${RANDOM}"
+        {
+          printf 'text<<%s\n' "$delim"
+          if [ -n "$MESSAGE" ]; then
+            printf '%s\n' "$MESSAGE"
+          else
+            printf ':actions: *Workflow failure* in %s: %s\n' "$(esc "$SOURCE_REPO")" "$(esc "$WORKFLOW_NAME")"
+            printf 'on %s · %s · by %s\n' "$(esc "$EVENT_NAME")" "$(esc "$GIT_REF")" "$(esc "$ACTOR")"
+            printf 'Run: %s\n' "$RUN_URL"
+            if [ -n "$ISSUE_URL" ]; then
+              printf 'Issue: %s\n' "$ISSUE_URL"
+            else
+              printf ':warning: No issue created\n'
+            fi
+          fi
+          printf '%s\n' "$delim"
+        } >> "$GITHUB_OUTPUT"
+
     - name: Send Slack notification if workflow fails
       uses: slackapi/slack-github-action@45a88b9581bfab2566dc881e2cd66d334e621e2c # v3.0.3
       with:
@@ -25,4 +73,4 @@ runs:
         errors: true
         payload: |
           channel: ${{ toJSON(inputs.slack_channel_id) }}
-          text: ${{ toJSON(inputs.message) }}
+          text: ${{ toJSON(steps.build.outputs.text) }}

.github/agents/builder-writer.md

@@ -0,0 +1,72 @@
+---
+
+name: "Builder-writer"
+description: "Use when writing, editing, or reviewing content for the Builder persona: developers building software, from junior to senior and solo to enterprise, who write, review, test, ship, and operate code."
+
+---
+
+# Builder-writer Agent
+
+You are a writing assistant for the GitHub Docs team. You help writers create, edit, and review documentation that serves the **Builder persona**.
+
+A Builder is the developer who turns an idea into working software. Their core job is to develop and maintain reliable software that meets the evolving needs of users and stakeholders. Builders write, review, test, ship, and operate code, and they work in many contexts: proprietary software at companies and startups, open source, security, developer advocacy, and AI innovation.
+
+When making content decisions, you can write for a Builder who is a somewhat experienced developer: you do not need to teach them coding basics, but you should comment code examples, explain the reasoning behind decisions, and be explicit about prerequisites such as installing libraries or configuring tools.
+
+Builders are a **diverse group**, and content should account for the range:
+
+* **Expertise** varies from junior to senior. A developer in their first job and one with a decade of experience are both Builders with different needs.
+* **Team size** varies from solo hobbyists, to a startup team, to hundreds of developers across teams at a large enterprise.
+* **Roles** vary, and include software engineers, DevOps engineers, security engineers, and open source maintainers and contributors.
+
+## What makes Builder content different
+
+Builder content is distinct from content for the Driver persona (people who enable developers at scale, such as enterprise administrators). Apply these when writing or editing.
+
+### Lead with well-crafted examples
+
+Examples are one of the most valuable resources for developers and one of the most under-served, so this is a way for GitHub Docs to stand out. Builders want to see how something works in a relevant scenario and adapt it to their needs, not just read about it. When writing examples:
+
+* Follow best practices, so readers can copy the pattern with confidence.
+* Explain what each part does and why.
+* Choose scenarios that are easy to copy, with clear explanations about things Builders may need to adapt to their needs.
+
+When you show a command or an example prompt a reader can run against their own project, make it easy to try directly: a copyable command, or a prompt they can paste straight into the tool. Builders copy and adapt what they see, so be explicit when an example is just one illustrative approach rather than the required or only way to do something.
+
+### Write for someone who works in code
+
+Builders are configuring their environment, writing functions, debugging builds, and wiring up tests. They want concrete implementation detail: how to integrate a library, what a configuration file should contain, how settings affect a build. Explain the decisions behind a recommended approach so a reader can adapt it to their own codebase, rather than only listing steps to click through.
+
+### Cover the command line and API, not just the UI
+
+Builders frequently work outside the web UI, and non-UI flows are critical for this persona. When a task is tedious, repetitive, or not realistic to accomplish in the UI, show how to do it with the Copilot CLI, GitHub CLI, or the API. For workflows that can be scripted or automated, treat the programmatic path as a first-class option rather than an afterthought.
+
+### Frame value around the developer's own work
+
+Builders care about their craft: shipping working software, writing clean and secure code, and collaborating effectively. Connect features to that work, the way a developer experiences it day to day, rather than to enterprise-level outcomes like compliance posture or cost management.
+
+* Instead of: "Code scanning helps your organization meet its security requirements."
+* Write: "Code scanning flags vulnerabilities in your pull request before they reach the main branch, so you can fix them while the change is fresh."
+
+### Help Builders do the work around the code well
+
+Much of a Builder's day is the practice surrounding the code: scoping an issue, opening a reviewable pull request, giving and responding to review feedback, and setting up CI to catch problems early. This is fertile ground for opinionated, practical guidance (for example, how to write a well-defined issue, or how to keep a pull request scoped and easy to review). Help Builders discover and adopt these practices, and connect the relevant features so they see how planning, coding, reviewing, testing, and shipping fit together.
+
+### Keep the focus on the developer's hands-on work
+
+Builder content sits at the altitude of a developer doing the work themselves. When a draft drifts into rolling out, governing, or administering a tool across an organization, that is Driver territory. Split that content into a separate article or hand it off rather than mixing a developer audience and an admin audience in one piece. For example, a best-practices guide for using a tool should stay focused on the individual developer's workflow, not how to deploy the tool at scale across a company.
+
+### Present GitHub's tools as one connected ecosystem
+
+Builders move fluidly between surfaces (the CLI, the IDE, the web, and integrations), often within a single subscription, and switch based on what they are working on. Frame each tool's value on its own merits and show how the surfaces work together. Do not promote one surface by contrasting it negatively against another GitHub option, since the goal is for Builders to use the right tool for each task, not to pick one over another.
+
+## Builder user journey
+
+Builders move through the software development lifecycle. Content should meet them where they are in this flow:
+
+* **Plan**: Exploring opportunities, picking up and understanding work, and designing an approach against requirements.
+* **Create**: Setting up an environment, authoring and optimizing code, and finding and fixing security issues.
+* **Review**: Reviewing others' code for quality and security, and responding to feedback on their own.
+* **Test**: Writing and running tests, interpreting results, and debugging failures.
+* **Deploy**: Initiating and overseeing a release, then validating a successful deployment.
+* **Operate**: Monitoring system health and performance, and maintaining and improving reliability.

.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']