Merge pull request #45028 from github/repo-sync

Repo sync

Author: docs-bot

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

assets/images/help/copilot/copilot-sdk/features-agent-loop-diagram-1.png

@@ -7,3 +7,21 @@ secrets:
     playbook: ''
     externally_usable: true
     kind: latest_at_deployment_start
+  DOCS_BOT_APP_CLIENT_ID:
+    owner: docs-engineering
+    type: github_app
+    externally_usable: false
+    playbook: ''
+    kind: latest_at_deployment_start
+  DOCS_BOT_APP_ID:
+    owner: docs-engineering
+    type: github_app
+    externally_usable: false
+    playbook: ''
+    kind: latest_at_deployment_start
+  DOCS_BOT_APP_PRIVATE_KEY:
+    owner: docs-engineering
+    type: github_app
+    externally_usable: false
+    playbook: ''
+    kind: latest_at_deployment_start

assets/images/help/copilot/copilot-sdk/features-agent-loop-diagram-2.png

@@ -25,15 +25,23 @@ Each budget has a type and a scope that define which paid use contributes to spe
 
 * **Type**: Defines which metered product or SKU is measured.
 * **Scope**: Defines whether the budget applies to the whole account, or to a subset of repositories, organizations, cost centers (enterprise only), or users. User-scoped budgets are currently only supported for {% data variables.product.prodname_copilot_short %} {% data variables.product.prodname_ai_credits_short %}, and have three scopes:
+
   * **Universal**: applies to all licensed users by default
   * **Cost center user-level**: applies to every user in a cost center
   * **Individual**: overrides the above for specific users
 
-For more information about how user-level budgets work and how they interact with other budget controls, see [AUTOTITLE](/copilot/concepts/billing/budgets-for-usage-based-billing).
+For {% data variables.product.prodname_copilot_short %}, cost centers can also have included usage controls, which cap how much of the shared {% data variables.product.prodname_ai_credits_short %} pool a cost center can use before metered usage begins. This is a separate control from the budgets and the included usage alerts described below. See [AUTOTITLE](/copilot/concepts/billing/budgets-for-usage-based-billing#included-usage-controls-for-cost-centers).
+
+## Roles and access for budgets
+
+Enterprise owners and billing managers can create and edit enterprise and cost center budgets, and they receive budget alerts by default. Organization owners can set budgets for their own organization, and personal account owners can set budgets for their own account. Each of these roles can view usage for the scopes they manage.
 
 ## Budget alerts
 
-You can enable alerts for budgets to receive emails when usage reaches 75%, 90%, and 100% of the budget amount. Emails are sent to account owners and billing managers by default. Additional recipients can be added as needed.
+You can enable alerts for budgets to be notified when usage reaches 75%, 90%, and 100% of the budget amount. Alerts are shown in the {% data variables.product.github %} UI and sent by email. By default, alerts go to account owners and billing managers, and you can add additional recipients as needed. Budget alerts are available for budgets scoped to your enterprise, a cost center, an organization, or a repository.
+
+> [!NOTE]
+> Alerting for user-level budgets is not consistently available in all scenarios. Don't rely on user-level budget alerts as your only signal, also monitor usage at the cost center or enterprise level.
 
 ## Included usage alerts
 

config/moda/secrets/ci/secrets.yml

@@ -29,10 +29,19 @@ To get started with cost centers, see [AUTOTITLE](/billing/tutorials/control-cos
 
 For more details, see [AUTOTITLE](/billing/reference/cost-center-allocation).
 
+## Controlling included usage
+
+For cost centers that contain {% data variables.product.prodname_copilot_short %} licenses, you can apply included usage controls in addition to budgets.
+
+{% data reusables.billing.included-usage-controls %}
+
+This is separate from a cost center budget, which caps metered charges only after the shared pool of {% data variables.product.prodname_ai_credits_short %} is exhausted. For more information, see [AUTOTITLE](/copilot/concepts/billing/budgets-for-usage-based-billing#included-usage-controls-for-cost-centers).
+
 ## Cost center limitations
 
 * The maximum number of active cost centers per enterprise is 500.
 * The maximum number of resources per cost center is 25,000.
 * A maximum of 50 resources can be added to or removed from a cost center at a time.
 * Azure subscriptions can only be added to or removed from cost centers through the UI.
 * Outside collaborators or unaffiliated users can only be added to cost centers via the cost center API. For more information, see [AUTOTITLE](/billing/tutorials/control-costs-at-scale#add-resources-to-the-cost-center).
+* You can't set different budgets for teams within the same cost center. A budget applies to the whole cost center, so if two teams need separate budgets, create a separate cost center for each. Separate cost centers can share the same Azure billing identity.

content/billing/concepts/budgets-and-alerts.md

@@ -36,7 +36,8 @@ When you create a cost center, you can add **organizations**, **repositories**,
 1. If your account is billed to Azure, you have the option to add an Azure ID. Your credentials will be verified against Azure to ensure the Azure IDs associated to your account are available.
 1. Under **Resources**, select the organizations, repositories, users, and/or enterprise teams that will be a part of the cost center.
 
-   >[!NOTE] A resource (organization, repository, or user) can only be assigned to one cost center at a time. If you add a resource that belongs to a different cost center, it will be moved to the new cost center and you will be notified.
+   > [!NOTE]
+   > A resource (organization, repository, user, or enterprise team) can only be assigned to one cost center at a time. If you add a resource that belongs to a different cost center, it will be moved to the new cost center and you will be notified.
 
 {% data reusables.billing.cost-center-create-button %}
 

content/billing/concepts/cost-centers.md

@@ -149,6 +149,11 @@ You can edit or delete a budget at any time, but you cannot change the scope of
 1. In the list of budgets, click {% octicon "kebab-horizontal" aria-label="View actions" %} next to the budget you want to edit, and click **{% octicon "pencil" aria-hidden="true" aria-label="pencil" %} Edit** or **{% octicon "trash" aria-hidden="true" aria-label="trash" %} Delete**.
 1. Follow the prompts.
 
+### Controlling included usage for a cost center
+
+Budgets cap metered charges after the shared pool of {% data variables.product.prodname_ai_credits_short %} is exhausted. To cap how much of the pool a cost center can use **before** the metered phase, use an included usage control. {% data variables.product.github %} sets the cap automatically based on the licenses assigned to the cost center, and you choose whether members are blocked or roll into paid overage when the cap is reached. See [AUTOTITLE](/copilot/concepts/billing/budgets-for-usage-based-billing#included-usage-controls-for-cost-centers) and [AUTOTITLE](/billing/concepts/cost-centers).
+> [!NOTE]
+> Enabling included usage controls does not retroactively redistribute the shared {% data variables.product.prodname_ai_credits_short %} enterprise pool. After the setting is enabled, users in the cost center share only the included {% data variables.product.prodname_ai_credits_short %} funded by licenses attributed to that cost center. When the setting is disabled, users in the cost center can continue drawing from the shared enterprise pool.
 ## Next steps
 
 For {% data variables.product.prodname_copilot_short %}-specific budget guidance under usage-based billing, including user-level budgets and configuration scenarios, see [AUTOTITLE](/copilot/concepts/billing/budgets-for-usage-based-billing) and [AUTOTITLE](/copilot/tutorials/budgets/optimizing-your-budget-configuration).

content/billing/how-tos/products/use-cost-centers.md

@@ -106,7 +106,7 @@ Create one budget for each product, SKU, or group of SKUs that you want to contr
 
 ### Review existing budgets for conflicts
 
-After creating your cost center budgets, check existing enterprise-wide budgets to ensure they don't conflict with or override your new cost center budgets.
+After creating your cost center budgets, check existing enterprise-wide budgets to ensure they don't conflict with or override your new cost center budgets. When budgets overlap, the most restrictive one applies, so a low budget at a higher scope can block a cost center before its own budget is reached.
 
 Navigate to the "Budgets and alerts" page. You'll see two lists of budgets:
 
@@ -121,6 +121,14 @@ Review whether any enterprise budgets apply to the same products or SKUs as your
 
 Filter the other budgets list to show a scope of **Cost Centers**. You should see your new cost center with a row for each budget you created. Initially, usage will be near zero, but within a few days you'll see costs accumulating as users and repositories consume products beyond the allowance in their plan.
 
+### Troubleshooting budget conflicts
+
+Keep these limits in mind as you combine budgets across scopes:
+
+* **Budgets overlap, and the most restrictive one applies.** A user can be covered by an individual, cost center, organization, and enterprise budget at the same time. Whichever has the least headroom remaining blocks them first. If someone is blocked unexpectedly, review every scope that applies to them. For the full evaluation order, see [AUTOTITLE](/copilot/concepts/billing/budgets-for-usage-based-billing).
+* **You can't set different budgets for teams in the same cost center.** A budget applies to the whole cost center, not to teams within it. If two teams need separate budgets, create a separate cost center for each. Separate cost centers can still share the same Azure billing identity.
+* **Budgets don't add up across levels.** An enterprise budget isn't the sum of your cost center budgets, and raising one doesn't raise another. When you change a budget at one level, reconcile the totals at the others yourself.
+
 ## 4. Create a cost center with the REST API
 
 Now that you understand how to create cost centers in the user interface, you can explore the REST API to see how cost centers can be created programmatically. Understanding the API helps you evaluate whether automation would benefit your organization.

content/billing/how-tos/set-up-budgets.md

@@ -46,6 +46,12 @@ When a cost center's budget is exhausted, only users in that cost center are blo
 > [!NOTE]
 > A cost center budget is different from a cost center user-level budget. A cost center budget caps the team's **total metered charges** after the pool is exhausted. A cost center user-level budget caps **each member's individual consumption** across both the pool and metered phases, the same way other user-level budgets do. You can apply both to the same cost center.
 
+### Included usage controls for cost centers
+
+{% data reusables.billing.included-usage-controls %}
+
+Unlike a cost center budget, which caps metered charges only after the shared pool of {% data variables.product.prodname_ai_credits_short %} is exhausted, an included usage control limits how much of the pool a cost center can draw **before** the metered phase begins. To enable it, see [AUTOTITLE](/billing/how-tos/set-up-budgets).
+
 ### Organization budget
 
 An organization budget caps metered charges for users who receive their {% data variables.product.prodname_copilot_short %} license through that organization. Like cost center budgets, it is only active after the shared pool is exhausted.