Merge branch 'github:main' into main

Author: cometacosin

.devcontainer/devcontainer.json

@@ -59,11 +59,13 @@
   },
 
   // Lifecycle commands
-  "onCreateCommand": "npm ci",
+  // Install dependencies then install Copilot CLI
+  "onCreateCommand": "npm ci && npm install -g @github/copilot@prerelease",
+  // Start a web server and keep it running
   "postStartCommand": "nohup bash -c 'npm start &'",
-  // Set the port to be public
+  // Set port 4000 to be public
   "postAttachCommand": "gh cs ports visibility 4000:public -c \"$CODESPACE_NAME\"",
-
+  
   // Comment out connect as root instead. More info: https://aka.ms/vscode-remote/containers/non-root.
   "remoteUser": "node",
 

.github/CODEOWNERS

@@ -12,6 +12,3 @@ 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
-
-# RAI - CELA
-data/reusables/rai/** @github/legal-product

.github/CONTRIBUTING.md

@@ -2,86 +2,113 @@
 
 Thank you for investing your time in contributing to our project! Any contribution you make will be reflected on [docs.github.com](https://docs.github.com/en) :sparkles:.
 
+**📖 For comprehensive contribution guidance, please visit our official documentation at [docs.github.com/en/contributing](https://docs.github.com/en/contributing). This is our canonical source for all contribution processes and policies.**
+
 Read our [Code of Conduct](./CODE_OF_CONDUCT.md) to keep our community approachable and respectable.
 
-In this guide you will get an overview of the contribution workflow from opening an issue, creating a PR, reviewing, and merging the PR.
+This guide provides repository-specific information to supplement the official contribution documentation. For detailed processes, policies, and best practices, always refer to [docs.github.com/en/contributing](https://docs.github.com/en/contributing).
 
-Use the table of contents icon <img alt="Table of contents icon" src="/contributing/images/table-of-contents.png" width="25" height="25" /> on the top left corner of this document to get to a specific section of this guide quickly.
+Use the table of contents icon <img alt="Table of contents icon" src="/contributing/images/table-of-contents.png" width="25" height="25" /> in the top corner of this document to get to a specific section of this guide quickly.
 
 ## New contributor guide
 
-To get an overview of the project, read the [README](../README.md) file. Here are some resources to help you get started with open source contributions:
+**Start here:** Visit [docs.github.com/en/contributing](https://docs.github.com/en/contributing) for complete contributor onboarding and guidelines.
+
+For repository-specific setup, read the [README](../README.md) file. The official docs site also provides these helpful resources:
 
 - [Finding ways to contribute to open source on GitHub](https://docs.github.com/en/get-started/exploring-projects-on-github/finding-ways-to-contribute-to-open-source-on-github)
 - [Set up Git](https://docs.github.com/en/get-started/git-basics/set-up-git)
 - [GitHub flow](https://docs.github.com/en/get-started/using-github/github-flow)
 - [Collaborating with pull requests](https://docs.github.com/en/github/collaborating-with-pull-requests)
 
+## Contribution types and what we're looking for
 
-## Getting started
+Content we accept:
+* Technical and grammatical corrections
+* Typo fixes
+* Expanded explanations of existing products or features, when the expansion has a compelling reason
+* New content filling important gaps in our documentation. For example, [this pull request](https://github.com/github/docs/pull/38048) added a useful section on security hardening for GitHub Actions.
 
-To navigate our codebase with confidence, see [the introduction to working in the docs repository](/contributing/README.md) :confetti_ball:. For more information on how we write our markdown files, see "[Using Markdown and Liquid in GitHub Docs](https://docs.github.com/en/contributing/writing-for-github-docs/using-markdown-and-liquid-in-github-docs)."
+Content we do not currently accept:
+* Edits purely for tone, readability, or efficiency
+* Topics that are too niche or a matter of personal preference
+* Changes to the underlying site and workflows
 
-Check to see what [types of contributions](/contributing/types-of-contributions.md) we accept before making changes. Some of them don't even require writing a single line of code :sparkles:.
+These are general guidelines, but if you’re not sure what category your proposed change would fall under, feel free to open an issue to discuss it with us!
 
-### Issues
+## Getting started
 
-#### Create a new issue
+📚 **Primary resource:** [docs.github.com/en/contributing](https://docs.github.com/en/contributing) contains our complete contribution workflow and policies.
 
-If you spot a problem with the docs, [search if an issue already exists](https://docs.github.com/en/github/searching-for-information-on-github/searching-on-github/searching-issues-and-pull-requests#search-by-the-title-body-or-comments). If a related issue doesn't exist, you can open a new issue using a relevant [issue form](https://github.com/github/docs/issues/new/choose).
+For repository-specific information:
+- See [the introduction to working in the docs repository](/contributing/README.md) :confetti_ball:
+- Check our [types of contributions](/contributing/types-of-contributions.md) we accept
+- Review our markdown style guidelines in the `/contributing` directory
 
-#### Solve an issue
+### Writing style guidelines
 
-Scan through our [existing issues](https://github.com/github/docs/issues) to find one that interests you. You can narrow down the search using `labels` as filters. See "[Label reference](https://docs.github.com/en/contributing/collaborating-on-github-docs/label-reference)" for more information. As a general rule, we don’t assign issues to anyone. If you find an issue to work on, you are welcome to open a PR with a fix.
+When contributing content, please follow these key principles from our [style guide](https://docs.github.com/en/contributing/style-guide-and-content-model/style-guide):
 
-### Make Changes
+- **Clarity and simplicity**: The goal of our writing style is clarity and simplicity.
+- **Meaning over grammar**: Grammatical correctness is important, but not as important as clarity and meaning.
+- **Second person**: The docs use second-person ("you") to communicate directly with readers.
+- **Inclusive language**: Use inclusive language by not assuming gender or ability level, and by avoiding slang and idioms.
+- **Accessible technical language**: Jargon is sometimes necessary, but don't assume every reader has your technical expertise.
+- **Active voice**: Use active voice wherever possible. Active voice means avoiding "be" verbs like "is" or "are" when you can, but also choosing more dynamic verbs to get your point across. "Press (a key)" is less dynamic than "tap (a key)," for example.
+- **Clear terminology**: Avoid technical abbreviations like "repo" and "PR," and Latin abbreviations like "i.e." and "e.g."
 
-#### Make changes in the UI
+For complete style guidance, see our [style guide](https://docs.github.com/en/contributing/style-guide-and-content-model/style-guide).
 
-Click **Make a contribution** at the bottom of any docs page to make small changes such as a typo, sentence fix, or a broken link. This takes you to the `.md` file where you can make your changes and [create a pull request](#pull-request) for a review.
+### Issues
+
+**For detailed issue guidelines, see [docs.github.com/en/contributing](https://docs.github.com/en/contributing).**
 
- <img src="/contributing/images/contribution_cta.png" />
+#### Repository-specific notes:
+- Search [existing issues](https://github.com/github/docs/issues) before creating new ones
+- Use our [label reference](https://docs.github.com/en/contributing/collaborating-on-github-docs/label-reference) to categorize appropriately
+- Follow the issue templates provided in this repository
 
-#### Make changes in a codespace
+### Make Changes
 
-For more information about using a codespace for working on GitHub documentation, see "[Working in a codespace](https://github.com/github/docs/blob/main/contributing/codespace.md)."
+**Complete change guidelines are available at [docs.github.com/en/contributing](https://docs.github.com/en/contributing).**
 
-#### Make changes locally
+#### Repository-specific options:
 
-1. Fork the repository.
-- Using GitHub Desktop:
-  - [Getting started with GitHub Desktop](https://docs.github.com/en/desktop/installing-and-configuring-github-desktop/getting-started-with-github-desktop) will guide you through setting up Desktop.
-  - Once Desktop is set up, you can use it to [fork the repo](https://docs.github.com/en/desktop/contributing-and-collaborating-using-github-desktop/cloning-and-forking-repositories-from-github-desktop)!
+**Make changes in the UI:** Click **Make a contribution** at the bottom of any docs page for small changes like typos or broken links.
 
-- Using the command line:
-  - [Fork the repo](https://docs.github.com/en/github/getting-started-with-github/fork-a-repo#fork-an-example-repository) so that you can make your changes without affecting the original project until you're ready to merge them.
+<img src="/contributing/images/contribution_cta.png" />
 
-2. Install or update to **Node.js**, at the version specified in `.node-version`. For more information, see [the development guide](../contributing/development.md).
+**Make changes in a codespace:** See "[Working in a codespace](https://github.com/github/docs/blob/main/contributing/codespace.md)" for documentation-specific setup.
 
-3. Create a working branch and start with your changes!
+**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))
+3. Create a working branch and start with your changes
 
 ### Commit your update
 
-Commit the changes once you are happy with them. Don't forget to use the "[Self review checklist](https://docs.github.com/en/contributing/collaborating-on-github-docs/self-review-checklist)" to speed up the review process :zap:.
+Follow the guidelines at [docs.github.com/en/contributing](https://docs.github.com/en/contributing) for commit best practices. 
+
+Use our "[Self review checklist](https://docs.github.com/en/contributing/collaborating-on-github-docs/self-review-checklist)" before committing.
 
 ### Pull Request
 
-When you're finished with the changes, create a pull request, also known as a PR.
-- Fill the "Ready for review" template so that we can review your PR. This template helps reviewers understand your changes as well as the purpose of your pull request.
-- Don't forget to [link PR to issue](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue) if you are solving one.
-- Enable the checkbox to [allow 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) so the branch can be updated for a merge.
-Once you submit your PR, a Docs team member will review your proposal. We may ask questions or request additional information.
-- We may ask for changes to be made before a PR can be merged, either using [suggested changes](https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/incorporating-feedback-in-your-pull-request) or pull request comments. You can apply suggested changes directly through the UI. You can make any other changes in your fork, then commit them to your branch.
-- As you update your PR and apply changes, mark each conversation as [resolved](https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/commenting-on-a-pull-request#resolving-conversations).
-- If you run into any merge issues, checkout this [git tutorial](https://github.com/skills/resolve-merge-conflicts) to help you resolve merge conflicts and other issues.
+**Complete pull request (PR) guidelines:** [docs.github.com/en/contributing](https://docs.github.com/en/contributing)
+
+**Repository-specific notes:**
+- Fill the "Ready for review" template
+- [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).
 
 ### Your PR is merged!
 
 Congratulations :tada::tada: The GitHub team thanks you :sparkles:.
 
-Once your PR is merged, your contributions will be publicly visible on the [GitHub docs](https://docs.github.com/en).
+Once merged, your contributions will be visible on [GitHub docs](https://docs.github.com/en). 
 
-Now that you are part of the GitHub docs community, see how else you can [contribute to the docs](/contributing/types-of-contributions.md).
+Continue contributing using our [types of contributions guide](/contributing/types-of-contributions.md) or explore more opportunities at [docs.github.com/en/contributing](https://docs.github.com/en/contributing).
 
 ## Windows
 

.github/actions/get-changed-files/action.yml

@@ -33,6 +33,7 @@ runs:
     - name: Gather changed files
       id: get_changes
       env:
+        INPUT_FILES: ${{ inputs.files }}
         INPUT_HEAD: ${{ inputs.head || github.event.pull_request.head.ref || github.event.merge_group.head_ref ||  github.ref_name }}
         INPUT_OUTPUT_FILE: ${{ inputs.output_file }}
       shell: bash

.github/actions/get-changed-files/get-changed-files.sh

@@ -18,9 +18,8 @@ git fetch --depth=1 origin main
 git fetch --depth=1 origin ${INPUT_HEAD:-HEAD}
 
 # Get diff with status information
-# Find the merge-base (common ancestor) instead of using origin/main directly
 echo "__ running git diff with status __"
-DIFF_OUTPUT=$(git diff --name-status origin/main...origin/${INPUT_HEAD:-HEAD})
+DIFF_OUTPUT=$(git diff --name-status origin/main origin/${INPUT_HEAD:-HEAD})
 
 # Function to extract files by pattern from diff output
 extract_files() {

.github/instructions/all.instructions.md

@@ -0,0 +1,31 @@
+---
+applyTo: "**"
+---
+
+# Copilot instructions for docs.github.com
+
+This repository contains code to run the GitHub Docs site on docs.github.com, as well as the content that the site displays. We write the code in JavaScript and TypeScript, and we write the content primarily in Markdown.
+
+## Creating a pull request
+
+When you create a pull request:
+
+1. **Always** make the first line of the PR description the following (in italics):
+
+   `_Copilot Chat generated this pull request._`
+  
+2. Optionally, you may include a collapsed section summarizing the prompt or discussion with Copilot Chat:
+
+   ```markdown
+   <details><summary>Prompt summary - submitted by @GITHUB-USER-ID</summary>
+  
+   > [Prompt summary text here]
+  
+   </details>
+   ```
+
+   This helps reviewers understand the context and intent behind the automated changes.
+   
+3. Label with "llm-generated". 
+4. If an issue exists, include "fixes owner/repo#issue" or "towards owner/repo#issue" as appropriate. 
+5. Always _escape backticks_ when you use gh cli.

.github/instructions/code.instructions.md

@@ -0,0 +1,63 @@
+---
+applyTo: "src/**,.github/**,config/**,.devcontainer/**,**Dockerfile,package*.json"
+---
+
+# 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.
+
+## Guidelines
+
+- If available, use ripgrep (`rg`) instead of `grep`.
+- Make sure to always _escape backticks_ when using gh cli.
+- All scripts should be listed in `package.json` and use `tsx`.
+- Whenever you create or comment on an issue or pull request, indicate you are an LLM.
+- Be careful fetching full HTML pages off the internet. Prefer to use gh cli whenever possible for github.com. Limit the number of tokens when grabbing HTML.
+- Avoid pull requests with over 300 lines of code changed. When significantly larger, offer to split up into smaller pull requests if possible.
+- All new code should be written in TypeScript and not JavaScript.
+- 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'`
+
+## Tests
+
+We use `vitest` to write unit tests. Tests live in their own files in the `tests` subdirectory of a source (src) directory, e.g. `src/search/tests/api-ai-search.ts`. For integration tests, we can use the mock server in `src/tests/mocks/start-mock-server.ts` to mock external requests. For UI rendering tests, we use `playwright` and write tests in `src/fixtures/tests/playwright-rendering.spec.ts`
+
+- `npm run test`: For all unit tests
+  - You can pass specific paths, e.g. `npm run test -- src/search/tests/ai-search-proxy`
+  - You can add `--silent=false` to include `console.log` debugging.
+- `npm run build && npm run playwright-test -- playwright-rendering`: You need to build for changes outside of the test to be picked up. We use playwright for all rendering and end-to-end tests
+  - You can add `--ui` to keep open `localhost:4000` which can be viewed in a simple browser for debugging UI state.
+- `npm run dev` to start the development server on `localhost:4000`.
+- `ROOT=src/fixtures/fixtures TRANSLATIONS_FIXTURE_ROOT=src/fixtures/fixtures/translations vitest src/fixtures/tests` for tests that involve fixtures.
+
+## Validate
+
+Run the following commands to validate your changes:
+
+- `npm run tsc`
+- `npm run build`
+- `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 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 an LLM 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 an LLM.