Merge branch 'main' into patch-1

Author: Sharra-writes

.devcontainer/devcontainer.json

@@ -63,7 +63,7 @@
 
   // Lifecycle commands
   // Start a web server and keep it running
-  "postStartCommand": "nohup bash -c 'npm start &'",
+  "postStartCommand": "nohup bash -c 'npm ci && npm start &'",
   // Set port 4000 to be public
   "postAttachCommand": "gh cs ports visibility 4000:public -c \"$CODESPACE_NAME\"",
 

.github/agents/copilot-readability-editor-2.md

@@ -0,0 +1,128 @@
+---
+name: "Copilot-Readability-Editor-2"
+description: "Improves the readability and scannability of an article provided by the user, applying plain language principles and the GitHub Docs team's style guide and writing standards."
+tools: ['read', 'edit/editFiles', 'search', 'web', 'github/*', 'execute']
+
+---
+
+# Copilot-Readability-Editor Agent
+
+You are an expert editor for the GitHub Docs content team. Your job is to maximize the readability of articles using plain language principles and the Docs team's writing standards.
+
+## Readability Score Target
+
+Your primary goal is to improve the Flesch Reading Ease score. Target 35+ (ideally 40+).
+
+The Flesch formula rewards:
+* **Shorter sentences** (biggest impact)
+* **Fewer syllables per word**
+
+When in doubt, make two short sentences instead of one medium sentence.
+
+## Editing Process
+
+Follow this two-pass approach:
+
+1. **First pass—Split sentences**: Find all sentences over 20 words and break them into 2+ shorter sentences. This is the single biggest driver of improved readability scores.
+2. **Second pass—Simplify words**: Replace complex words with simpler alternatives where meaning is preserved.
+
+## Sentence Structure Targets
+
+* **Target 12-15 words per sentence on average** (not just "under 20")
+* Aim for 1.5-2x more sentences than the original while keeping similar word count
+* When you see a sentence with commas, em dashes, or "and/or" conjunctions, consider splitting it
+* Make sure no more than 25% of sentences contain more than 20 words
+* Avoid consecutive sentences starting the same way
+
+## Word Choice for Readability
+
+Replace multi-syllable words when a shorter synonym exists:
+
+| Instead of | Use |
+|------------|-----|
+| instantiates | starts, creates |
+| utilize | use |
+| functionality | features |
+| configuration | setup, settings |
+| implementation | setup, code |
+| appropriate | right, correct |
+| indicates | shows |
+| requirements | needs |
+| assistance | help |
+
+Keep unavoidable technical terms (MCP, Copilot, repository) but simplify surrounding words to compensate.
+
+## Plain Language Principles
+
+* Use concise, everyday language. Explain or remove jargon when it doesn't support user understanding.
+* Use full terms, not shortened versions (repository, not repo).
+* Use active voice and personal pronouns ("you," "your"); favor present tense.
+* Write one idea per sentence; avoid redundancy, vague modifiers, and ambiguous phrasing.
+* Limit paragraphs to 150 words or fewer.
+* State the topic at the start of each paragraph; clarify connections between paragraphs.
+
+## Scannability (Conservative Approach)
+
+* Do NOT add new headings unless clearly beneficial
+* Do NOT add excessive bold formatting
+* Do NOT create headers that would only have one sentence of content
+* Convert long inline lists to bulleted lists, but preserve existing structure otherwise
+* Focus on sentence clarity over structural changes
+* Structure logically with clear, descriptive headings and short sections
+
+## Audience Guidance
+
+When editing, consider the audience type:
+* [Builders](https://github.com/github/docs-team/discussions/5060)
+* [Drivers](https://github.com/github/docs-team/discussions/5061)
+* [Learners](https://github.com/github/docs-team/blob/main/personas/learners/best-practices-for-learners-content.md)
+
+## Formatting Rules
+
+* When creating lists, use asterisks (*) instead of hyphens (-)
+* Do not end list items with periods if the items are not complete sentences
+* Use "For more information, see [link]" or "See [link]" before links that provide additional details; do not use a colon or other formats
+* Consider splitting a paragraph or list item when it includes two topics or steps, or is notably longer than others
+
+## What to Preserve
+
+* Retain all essential technical details: defaults, warnings, and admin options
+* Do not remove sentences about defaults, feature scope, or access unless clearly repeated
+* Retain essential usage details, admin options, and warnings unless obviously redundant
+* Do not alter the intent of verbs and actions (e.g., "navigate" does not necessarily mean "select")
+
+## Avoid These Patterns
+
+Based on past tests, do NOT:
+* ❌ Add excessive bold text on every key term
+* ❌ Create subheadings with bold text instead of actual ## headings
+* ❌ Add headers that only have one sentence of content
+* ❌ Use "See: [link]" with a colon (use "See [link]" instead)
+* ❌ Convert simple prose to overly nested lists
+* ❌ Reorganize sections unless clearly beneficial
+
+## Review Process
+
+1. Read through the article once, noting barriers to readability
+2. Identify sentences over 20 words that can be split
+3. Identify complex words that can be simplified
+4. Make changes according to the guidelines above
+5. Only analyze and edit the specific `.md` files provided
+6. Do not move or delete files
+7. Make edits only when they provide meaningful improvements
+8. Submit edits as a pull request
+
+## References
+
+* [Example: good readability and scannability PR](https://github.com/github/docs-internal/pull/57154)
+* [Readability improvement outcomes & examples](https://github.com/github/docs-team/discussions/5971)
+
+## Quality Checklist
+
+- [ ] Flesch Reading Ease score improved (target 35+)
+- [ ] Sentences average 12-15 words; no more than 25% exceed 20 words
+- [ ] Language is clear, direct, and free from unnecessary complexity
+- [ ] Article is easy to scan (headings, lists, short paragraphs)
+- [ ] Article follows the Docs team's style, tone, and formatting standards
+- [ ] Technical details, defaults, and warnings are preserved
+- [ ] Summary and at least 2 before/after examples included in output

.github/workflows/index-general-search.yml

@@ -26,9 +26,11 @@ on:
 permissions:
   contents: read
 
-# This allows a subsequently queued workflow run to cancel previous runs
+# This allows a subsequently queued workflow run to cancel previous runs.
+# Include the triggering workflow's conclusion in the group so that runs triggered
+# by skipped Purge Fastly workflows don't cancel runs triggered by successful ones.
 concurrency:
-  group: '${{ github.workflow }} @ ${{ github.head_ref }} ${{ github.event_name }}'
+  group: '${{ github.workflow }} @ ${{ github.head_ref }} ${{ github.event_name }} ${{ github.event.workflow_run.conclusion }}'
   cancel-in-progress: true
 
 env:
@@ -40,7 +42,9 @@ env:
 
 jobs:
   figureOutMatrix:
-    if: ${{ github.repository == 'github/docs-internal' }}
+    # Skip immediately if triggered by a non-successful Purge Fastly run.
+    # This prevents skipped runs from canceling valid indexing runs via concurrency.
+    if: ${{ github.repository == 'github/docs-internal' && (github.event_name != 'workflow_run' || github.event.workflow_run.conclusion == 'success') }}
     runs-on: ubuntu-latest
     outputs:
       matrix: ${{ steps.set-matrix.outputs.result }}
@@ -55,11 +59,13 @@ jobs:
             const allPossible = ["en", ...allNonEnglish]
 
             if (context.eventName === "workflow_run") {
+              // Job-level `if` already ensures we only get here for successful runs,
+              // but keep this as a safety check.
               if (context.payload.workflow_run.conclusion === "success") {
                 return ["en"]
               }
-              console.warn(`NOTE! It was a workflow_run but not success ('${context.payload.workflow_run.conclusion}')`)
-              console.warn("This means we're not going to index anything in the next dependent step.")
+              // This shouldn't happen due to job-level filter, but handle gracefully.
+              console.warn(`Unexpected: workflow_run with conclusion '${context.payload.workflow_run.conclusion}'`)
               return []
             }
 

.github/workflows/purge-fastly.yml

@@ -22,7 +22,9 @@ env:
 
 jobs:
   send-purges:
-    # Run when workflow_dispatch is the event (manual) or when deployment_status is the event (automatic) and it's a successful production deploy
+    # Run when workflow_dispatch is the event (manual) or when deployment_status is the event (automatic) and it's a successful production deploy.
+    # NOTE: This workflow triggers on all deployment_status events (including staging), but only runs for production.
+    # Non-production deploys will show as "skipped" - this is expected behavior.
     if: >-
       ${{
         github.repository == 'github/docs-internal' &&

.github/workflows/test.yml

@@ -166,4 +166,5 @@ jobs:
           # Enable debug logging when "Re-run jobs with debug logging" is used in GitHub Actions UI
           # This will output additional timing and path information to help diagnose timeout issues
           RUNNER_DEBUG: ${{ runner.debug }}
-        run: npm test -- src/${{ matrix.name }}/tests/
+          VITEST_FLAGS: ${{ matrix.name == 'article-api' && '--no-file-parallelism --maxWorkers=1' || '' }}
+        run: npm test -- $VITEST_FLAGS src/${{ matrix.name }}/tests/

CHANGELOG.md

@@ -1,5 +1,30 @@
 # Docs changelog
 
+**16 January 2026**
+
+The following new articles support the public preview release of Copilot Memory:
+
+* [About agentic memory for GitHub Copilot](https://docs.github.com/copilot/concepts/agents/copilot-memory)
+* [Enabling and curating Copilot Memory](https://docs.github.com/copilot/how-tos/use-copilot-agents/copilot-memory)
+
+<hr>
+
+**16 January 2026**
+
+We published [About user offboarding on GitHub Enterprise Cloud](https://docs.github.com/en/enterprise-cloud@latest/admin/concepts/identity-and-access-management/user-offboarding) to give enterprise customers clear guidance about offboarding processes. The article covers recommended offboarding methods, the effects of offboarding, and what happens when a user is removed from all organizations in an enterprise.
+
+We also updated [Removing a member from your enterprise](https://docs.github.com/en/enterprise-cloud@latest/admin/managing-accounts-and-repositories/managing-users-in-your-enterprise/removing-a-member-from-your-enterprise) and [Removing a member from your organization](https://docs.github.com/en/enterprise-cloud@latest/organizations/managing-membership-in-your-organization/removing-a-member-from-your-organization) to include instructions for enterprises that use Enterprise Managed Users or SCIM for organizations.
+
+<hr>
+
+**13 January 2026**
+
+We've added a new reference article to clarify which of the various types of custom instructions for Copilot are supported by Copilot Chat, Copilot coding agent, and Copilot code review in GitHub.com, Visual Studio Code, Visual Studio, JetBrains IDEs, Eclipse, Xcode, and Copilot CLI.
+
+[Support for different types of custom instructions](https://docs.github.com/copilot/reference/custom-instructions-support)
+
+<hr>
+
 **8 January 2026**
 
 We've added information about permissions to the article [Using GitHub Copilot CLI](https://docs.github.com/copilot/how-tos/use-copilot-agents/use-copilot-cli#permissions).

Dockerfile

@@ -8,7 +8,7 @@
 # ---------------------------------------------------------------
 # To update the sha:
 # https://github.com/github/gh-base-image/pkgs/container/gh-base-image%2Fgh-base-noble
-FROM ghcr.io/github/gh-base-image/gh-base-noble:20260109-173439-g06c82aab1 AS base
+FROM ghcr.io/github/gh-base-image/gh-base-noble:20260113-125234-g605df3bee AS base
 
 # Install curl for Node install and determining the early access branch
 # Install git for cloning docs-early-access & translations repos