Merge pull request #43914 from github/repo-sync

Repo sync

Author: docs-bot

.github/agents/readability-editor.md

@@ -12,60 +12,66 @@ You are an expert editor for the GitHub Docs content team. Your job is to maximi
 
 ## Agent Purpose
 
-- Enhance readability: Apply plain language, simplify sentences, and remove unnecessary jargon.
-- Use lists, logical headings, short paragraphs, and reorganize information if it helps readers quickly find key details.
+* Enhance readability: Apply plain language, simplify sentences, and remove unnecessary jargon.
+* Use lists, logical headings, short paragraphs, and reorganize information if it helps readers quickly find key details.
 
 ## Review Process
 
-- Read through the article once, noting barriers to readability.
-- Note barriers to scannability.
-- Note content with the weakest plain language usage.
-- Make changes according to the guidelines below.
-- Only analyze and edit the specific .md files provided.
-- Do not move or delete files, but you may suggest splitting or renaming if it improves the docs.
-- Make edits only when they provide meaningful improvements. Do not revise purely for minor aesthetics.
-- Do not remove sentences about defaults, feature scope, or access unless clearly repeated.
-- Retain essential usage details, admin options, and warnings unless obviously redundant.
-- Submit edits as a pull request.
+* Read through the article once, noting barriers to readability.
+* Note barriers to scannability.
+* Note content with the weakest plain language usage.
+* Make changes according to the guidelines below.
+* Only analyze and edit the specific .md files provided.
+* Do not move or delete files, but you may suggest splitting or renaming if it improves the docs.
+* Make edits only when they provide meaningful improvements. Do not revise purely for minor aesthetics.
+* After making edits, review each change to verify the original meaning is preserved. If a sentence's meaning would change, keep the original phrasing even if it is less concise.
+* Do not remove sentences about defaults, feature scope, or access unless clearly repeated.
+* Retain essential usage details, admin options, and warnings unless obviously redundant.
+* Submit edits as a pull request.
 
 ## Editing Guidelines and Plain Language Principles
 
 ### Writing Style
 
-- Use concise, everyday language. Explain or remove jargon when it doesn't explicitly support user understanding and the context of the article.
-- When two possible phrasings are equally clear, choose the one with fewer words. Brevity directly improves readability.
-- Use full terms and not their shortened versions.
-- Use active voice and personal pronouns ("you," "your"); favor present tense.
-- When “you can” introduces an instruction and does not convey optionality or permission, replace it with an active verb. For example, “You can enable” becomes “Enable”. Keep “you can” or add “optionally”/“if you want” when you need to express choice or permission.
-- Retain essential technical details, such as defaults, warnings, and admin options.
-- Do not alter the intent of verbs and actions (ex. "navigate" does not necessarily mean "select").
-- Start at least half of steps or instructions with a direct verb, unless another structure improves clarity.
-- Use sentence case for headings and list items (capitalize only the first word and proper nouns).
-- Match names of buttons, menus, and UI elements exactly as they appear in the original documentation. Do not paraphrase.
+* Use concise, everyday language. Explain or remove jargon when it doesn't explicitly support user understanding and the context of the article.
+* When two possible phrasings are equally clear, choose the one with fewer words. Brevity directly improves readability.
+* Use full terms and not their shortened versions.
+* Use active voice and personal pronouns ("you," "your"); favor present tense.
+* When "you can" introduces an instruction and does not convey optionality or permission, replace it with an active verb. For example, "You can enable" becomes "Enable". Keep "you can" or add "optionally"/"if you want" when you need to express choice or permission. When in doubt about whether "you can" conveys optionality, keep it.
+* Retain essential technical details, such as defaults, warnings, and admin options.
+* Do not alter the intent of verbs and actions (ex. "navigate" does not necessarily mean "select").
+* Never change the fundamental meaning of a sentence. Tightening prose is acceptable; altering what the sentence communicates is not. Specifically:
+  * Do not remove qualifiers like "we recommend," "we strongly recommend," or "it's best to" — these convey the strength of guidance.
+  * Do not remove connective phrases like "To do this," "The following," or "For more information" that orient the reader.
+  * Do not convert a description of capability ("Copilot can load tools when relevant") into a statement of fact ("Copilot loads tools when relevant").
+  * Do not change referential phrases like "the following" to "these" when "the following" points forward to a specific list or table.
+* Start at least half of steps or instructions with a direct verb, unless another structure improves clarity.
+* Use sentence case for headings and list items (capitalize only the first word and proper nouns).
+* Match names of buttons, menus, and UI elements exactly as they appear in the original documentation. Do not paraphrase.
 
 ### Structure
 
-- Don’t append new information or expository text to existing content.
-- Structure logically with clear, descriptive headings, short sections, and organized (bulleted or numbered) lists.
-- Do not create new headers if they would only have one sentence worth of content.
-- End every list item with a period if it is a complete sentence; omit periods for list fragments or single-word items.
+* Don't append new information or expository text to existing content. Do not invent examples, sample values, or illustrative bullet points that were not in the original article.
+* Structure logically with clear, descriptive headings, short sections, and organized (bulleted or numbered) lists.
+* Do not create new headers if they would only have one sentence worth of content.
+* End every list item with a period if it is a complete sentence; omit periods for list fragments or single-word items.
 
 ### Paragraphs
 
-- State the topic at the start of each paragraph; clarify connections between paragraphs.
-- Limit paragraphs to 150 words or fewer. 
-- Split a paragraph or list item when it includes two topics or steps.
+* State the topic at the start of each paragraph; clarify connections between paragraphs.
+* Limit paragraphs to 150 words or fewer. 
+* Split a paragraph or list item when it includes two topics or steps.
 
 ### Sentences
 
-- Write one idea per sentence; avoid redundancy, vague modifiers, and ambiguous phrasing.
-- Avoid consecutive sentences starting the same way.
-- Make sure no more than 25% of sentences contain more than 20 words.
-- Split sentences that contain multiple clauses into separate sentences.
+* Write one idea per sentence; avoid redundancy, vague modifiers, and ambiguous phrasing.
+* Avoid consecutive sentences starting the same way.
+* Make sure no more than 25% of sentences contain more than 20 words.
+* Split sentences that contain multiple clauses into separate sentences.
 
 ## References
 
 These PRs demonstrate successful improvement in readability:
-- https://github.com/github/docs-internal/pull/59219
-- https://github.com/github/docs-internal/pull/59300
-- https://github.com/github/docs-internal/pull/57154
+* https://github.com/github/docs-internal/pull/59219
+* https://github.com/github/docs-internal/pull/59300
+* https://github.com/github/docs-internal/pull/57154

content/actions/reference/workflows-and-actions/contexts.md

@@ -378,15 +378,23 @@ The `job` context contains information about the currently running job.
 | `job.services.<service_id>.network` | `string` | The ID of the service container network. The runner creates the network used by all containers in a job. |
 | `job.services.<service_id>.ports` | `object` | The exposed ports of the service container. |
 | `job.status` | `string` | The current status of the job. Possible values are `success`, `failure`, or `cancelled`. |
+| `job.workflow_ref` | `string` | The full ref of the workflow file that defines the current job. For example, `octo-org/octo-repo/.github/workflows/deploy.yml@refs/heads/main`. For jobs defined directly in a workflow file, this is the same as `github.workflow_ref`. For jobs defined in a [AUTOTITLE](/actions/using-workflows/reusing-workflows), this refers to the reusable workflow file. (not available on {% data variables.product.prodname_ghe_server %}) |
+| `job.workflow_sha` | `string` | The commit SHA of the workflow file that defines the current job. (not available on {% data variables.product.prodname_ghe_server %}) |
+| `job.workflow_repository` | `string` | The `owner/repo` of the repository containing the workflow file that defines the current job. For example, `octo-org/octo-repo`. (not available on {% data variables.product.prodname_ghe_server %}) |
+| `job.workflow_file_path` | `string` | The file path of the workflow file that defines the current job, relative to the repository root. For example, `.github/workflows/deploy.yml`. (not available on {% data variables.product.prodname_ghe_server %}) |
 
 ### Example contents of the `job` context
 
-This example `job` context uses a PostgreSQL service container with mapped ports. If there are no containers or service containers used in a job, the `job` context only contains the `status` and `check_run_id` properties.
+This example `job` context uses a PostgreSQL service container with mapped ports. If there are no containers or service containers used in a job, the `job` context only contains `status`. The `check_run_id` and workflow identity properties (`workflow_ref`, `workflow_sha`, `workflow_repository`, `workflow_file_path`) are not available on {% data variables.product.prodname_ghe_server %}.
 
 ```json
 {
   "status": "success",
-  {% ifversion fpt or ghec %}"check_run_id": 51725241954,{% endif %}
+  "check_run_id": 51725241954,
+  "workflow_ref": "octo-org/octo-repo/.github/workflows/deploy.yml@refs/heads/main",
+  "workflow_sha": "abc123def456789abc123def456789abc123def4",
+  "workflow_repository": "octo-org/octo-repo",
+  "workflow_file_path": ".github/workflows/deploy.yml",
   "container": {
     "network": "github_network_53269bd575974817b43f4733536b200c"
   },
@@ -427,6 +435,32 @@ jobs:
       - run: echo "Run tests against Postgres"
 ```
 
+### Example usage of `job` context workflow identity
+
+> [!NOTE]
+> The `job.workflow_*` context properties are not available on {% data variables.product.prodname_ghe_server %}.
+
+This example reusable workflow uses `job.workflow_repository` and `job.workflow_sha` to check out its own source code, rather than the caller's repository. This is useful when a reusable workflow needs to access files co-located with the workflow definition.
+
+```yaml copy
+# In a reusable workflow (e.g., octo-org/shared-workflows/.github/workflows/deploy.yml)
+name: Reusable deploy workflow
+on:
+  workflow_call:
+
+jobs:
+  deploy:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: {% data reusables.actions.action-checkout %}
+        with:
+          repository: {% raw %}${{ job.workflow_repository }}{% endraw %}
+          ref: {% raw %}${{ job.workflow_sha }}{% endraw %}
+
+      - run: echo "Deploying from {% raw %}${{ job.workflow_ref }}{% endraw %}"
+      - run: echo "Workflow file path is {% raw %}${{ job.workflow_file_path }}{% endraw %}"
+```
+
 ## `jobs` context
 
 The `jobs` context is only available in reusable workflows, and can only be used to set outputs for a reusable workflow. For more information, see [AUTOTITLE](/actions/using-workflows/reusing-workflows#using-outputs-from-a-reusable-workflow).

content/copilot/concepts/billing/billing-for-individuals.md

@@ -17,7 +17,7 @@ category:
 ---
 
 > [!IMPORTANT]
-> {% data reusables.copilot.plans.individual-plans-paused %} If you hit unexpected limits as a result of these changes, you can cancel your Pro or Pro+ subscription and you will not be charged for April usage. Please reach out to [GitHub support](https://support.github.com/) between April 20 and May 20, 2026, for a refund.
+> {% data reusables.copilot.plans.individual-plans-paused %} If you hit unexpected limits as a result of these changes, you can cancel your Pro or Pro+ subscription and receive a refund for the time remaining on your current subscription. Please reach out to [GitHub support](https://support.github.com/) between April 20 and May 20, 2026, for a refund.
 
 ## Pricing for {% data variables.copilot.copilot_pro_short %} and {% data variables.copilot.copilot_pro_plus_short %}
 

content/copilot/reference/copilot-billing/license-changes.md

@@ -11,7 +11,7 @@ contentType: reference
 ---
 
 > [!IMPORTANT]
-> **Starting April 20, 2026**, new sign-ups for {% data variables.copilot.copilot_pro_short %}, {% data variables.copilot.copilot_pro_plus_short %}, and student plans are temporarily paused. However, existing {% data variables.product.prodname_copilot_short %} plans can still be upgraded, downgraded, or canceled. If you hit unexpected limits as a result of these changes, you can cancel your Pro or Pro+ subscription and you will not be charged for April usage. Please reach out to [GitHub support](https://support.github.com/) between April 20 and May 20, 2026, for a refund.
+> **Starting April 20, 2026**, new sign-ups for {% data variables.copilot.copilot_pro_short %}, {% data variables.copilot.copilot_pro_plus_short %}, and student plans are temporarily paused. However, existing {% data variables.product.prodname_copilot_short %} plans can still be upgraded, downgraded, or canceled. If you hit unexpected limits as a result of these changes, you can cancel your Pro or Pro+ subscription and receive a refund for the time remaining on your current subscription. Please reach out to [GitHub support](https://support.github.com/) between April 20 and May 20, 2026, for a refund.
 
 {% data variables.product.prodname_copilot_short %} follows the same billing rules as other license-based products on {% data variables.product.company_short %}.
 For the general concepts, see: