Clarify Copilot authorization for GitHub publication

.github/copilot-instructions.md

@@ -47,12 +47,20 @@ When writing or modifying tests, you SHOULD:
 
 For markdown (`.md`) files, ensure there is no trailing whitespace at the end of any line.
 
+## GitHub publication authorization
+
+- **Interactive and coding sessions require explicit authorization.** Outside the configured agentic workflow and user-requested workflow rules below, interactive sessions, CCA, and autopilot must not create or update GitHub issues or post comments without explicit user authorization. Assigning a PR or granting write access does not authorize these additional actions. Preparing code changes does not authorize opening additional PRs.
+- **Advance permission is sufficient in interactive sessions.** Authorization may be given in the original prompt or later. Explicit permission to compose and publish within a clear task, action, and destination is sufficient; do not ask again or require separate approval of the generated text. Permission to open the task's PR does not authorize unrelated issues, comments, or additional PRs. If authorization is missing, or a proposed publication falls outside its scope or the scope is unclear, present the exact proposed content, destination, and publishing account and ask before publishing. If authorization cannot be obtained, leave a local draft and report the pending decision.
+- **Configured agentic workflows have scoped standing authorization.** When actually executing a repository-configured agentic workflow whose declared purpose and configured outputs explicitly authorize publication, no additional per-item approval is required for those operations. Use only the workflow's configured output mechanisms (such as `safe-outputs`) and stay within its destinations, action types, and limits. Permission to create issues does not authorize comments, issue updates, or PRs.
+- **User-requested workflows may define intentional publication outputs.** When the user explicitly requests or enables a specialized workflow, follow its documented publication contract: the actions, artifacts, destinations, and approval conditions it explicitly defines as intended outputs. Those outputs do not require an additional approval step unless the contract requires one. An incidental instruction to "create an issue" or "post a comment" is not a publication contract. Automatically invoking a skill as a helper does not grant publication permission. Authorization covers only the declared outputs of the workflow's currently authorized actions, not unrelated publication. User restrictions, including draft-only, dry-run, or review-before-publication, always take precedence.
+- **Authorization does not transfer.** Reading a workflow file or invoking its shared skills from a coding session does not confer the workflow's authorization. Running unattended, using a bot account, or having publication tools available is not sufficient either. Preserve any stricter caller approval requirements and dry-run rules. An AI disclosure is not publication approval.
+
 ## Pull Requests
 
 - **One concern per PR.** Split large or mixed changes. Do large refactorings and mechanical renames in their own PR, separate from logic changes.
 - **Enable automatic resolved-issue linking in the PR description.** On any PR intended to close an issue, include the fully qualified `Resolves owner/repository#123` format as the final substantive line of the PR description, before any required disclosure note.
 - **New public API requires an approved proposal before submission** — PRs adding unapproved API will be closed. Use the `api-proposal` skill; until approval lands the API stays `internal` in any submitted PR. A proposal's prototype branch is exempt and keeps its surface public — it's evidence, not a submission.
-- **Core component changes should start with an issue.** Changes to the host, VM, or JIT need a GitHub issue describing the problem and motivation first.
+- **Core component changes should start with an issue.** Changes to the host, VM, or JIT need a GitHub issue describing the problem and motivation first. Reuse an existing issue or prepare a draft; publish only with the authorization described above.
 - **Put the measurements in the description** for performance changes — BenchmarkDotNet results, or codegen and instruction-count evidence for low-level work.
 - **Behavioral changes need breaking-change documentation**, even prerelease-to-prerelease. Use the `breaking-change-doc` skill.
 - **Merge to main first, then `/backport`.** Servicing backports are limited to security bugs, regressions, and reliability issues, and should be small targeted fixes rather than refactorings.
@@ -61,8 +69,9 @@ For markdown (`.md`) files, ensure there is no trailing whitespace at the end of
 
 ### Agent Merge / CI check resolution
 
+- **Publication authorization for enabled actions.** When the user enables Agent Merge for a PR, publication needed for its currently authorized actions is authorized without additional approval: replying to review comments on that PR when review handling is authorized, and creating or updating `Known Build Error` issues in `dotnet/runtime` for eligible unrelated CI failures on that PR when CI fixing is authorized. Follow the `create-kbe` rules for eligibility, duplicate detection, and updates. This permission does not authorize comments on existing KBEs or unrelated issues, comments, or PRs. Explicit user restrictions, including draft-only, dry-run, or review-before-publication, still apply.
 - **Forbidden workflow action: rerunning failed CI as part of Agent Merge.** Agent Merge must never use `/azp` to retrigger Azure Pipelines, and must never close and reopen the PR to trigger a rerun. This is forbidden unless the user explicitly requests it.
-- **Never use reruns to determine whether a failure is unrelated to the PR.** In dotnet/runtime, the required path is to use Build Analysis and the `ci-analysis` skill to classify failures. For any failure listed as not `known`, determine whether it is caused by the current PR. If it is caused by the PR, fix it in the PR. If it is not caused by the PR, use the `create-kbe` skill to open or update a `Known Build Error` issue instead of retriggering CI.
+- **Never use reruns to determine whether a failure is unrelated to the PR.** In dotnet/runtime, the required path is to use Build Analysis and the `ci-analysis` skill to classify failures. For any failure listed as not `known`, determine whether it is caused by the current PR. If it is caused by the PR, fix it in the PR. If it is not caused by the PR, use the `create-kbe` skill to search for an existing KBE and prepare any proposed new issue or update as a draft instead of retriggering CI. Apply the publication authorization rules above before publishing; without authorization, report the failure and pending draft without publishing.
 
 When NOT running under CCA, for commits and pushes:
 

.github/skills/breaking-change-doc/SKILL.md

@@ -29,7 +29,11 @@ migration guidance. This skill automates that process:
 ### Trigger modes
 
 - **Interactive**: Ask Copilot (e.g. "Document the breaking change
-  in PR #114929"). The skill presents a draft for review before publishing.
+  in PR #114929"). The skill prepares a docs issue draft and posts the
+  documentation comment on the source PR without another approval step,
+  unless the user requests draft-only, dry-run, or review before publication,
+  or unresolved uncertainty about the documentation requires review.
+  Creating the docs issue is a separate publication decision.
 - **Automated**: The [GitHub Agentic Workflow](https://github.github.com/gh-aw/)
   at `.github/workflows/breaking-change-doc.md` triggers when a PR labeled
   `needs-breaking-change-doc-created` is merged (or the label is added to an
@@ -309,15 +313,33 @@ The script:
 
 ### Post the comment
 
-When running interactively (not in dry-run mode), post the contents of
-`artifacts/docs/breakingChanges/pr-comment.md` as a comment on the original
-dotnet/runtime PR using GitHub tools.
-
-When running in automated (gh-aw) mode, use the add_comment safe-output tool to post the comment.
-
-When in dry-run mode or when the user has not explicitly asked to comment,
-skip posting — the two files under `artifacts/docs/breakingChanges/` are the
-outputs for review.
+Follow the repository's [GitHub publication authorization rules](../../copilot-instructions.md#github-publication-authorization).
+A user-requested execution of this documentation workflow authorizes posting
+the contents of `artifacts/docs/breakingChanges/pr-comment.md` on the specified
+source dotnet/runtime PR without another approval step. This authorizes only
+the generated documentation comment, not creating the docs issue or posting
+unrelated comments.
+
+Invoking this skill incidentally during another coding task does not grant
+that permission. In that case, use the general publication authorization
+rules: proceed with explicit advance permission in an interactive session,
+or present the proposed comment and obtain approval before posting.
+
+When actually executing a repository-configured gh-aw workflow that authorizes
+this comment, use its add_comment safe-output tool within the configured scope.
+Running unattended or invoking this skill alone does not grant that permission.
+
+If the user requests draft-only, dry-run, or review before publication, or
+publication is otherwise unauthorized, skip posting — the two files under
+`artifacts/docs/breakingChanges/` are the outputs for review.
+
+Unresolved uncertainty about any aspect of the documentation also holds the
+source-PR comment, in both interactive and automated runs. Post it only after
+the uncertainty is resolved or the user has reviewed the proposed comment,
+been told what remains uncertain, and explicitly approved posting it. An
+initial workflow request or advance publication permission alone does not
+satisfy this content-review requirement. If confirmation cannot be obtained,
+keep the comment local and report the uncertainty without posting it.
 
 ### AI-generated content disclosure
 
@@ -332,11 +354,22 @@ generated comment. No additional action is needed.
 If the user asks for a draft or review before publishing, or if you are uncertain
 about any aspect of the documentation:
 
-1. Present the full issue content in chat for review.
-2. Ask the user to confirm before creating the issue.
-3. Only publish after explicit confirmation.
+1. Present the issue draft and proposed source-PR comment for review, explaining
+   any unresolved uncertainty.
+2. Obtain explicit approval before creating the docs issue or posting the
+   source-PR comment. Approval of one does not authorize the other.
+3. Publish only the approved artifacts. If approval cannot be obtained, keep
+   the unapproved outputs local and report the pending review.
+
+When the user has not explicitly asked to create the docs issue, keep that
+issue as a draft. This alone does not suppress an authorized source-PR
+documentation comment. A draft-only, dry-run, or review-before-publication
+request suppresses the comment as well.
 
-When the user has not explicitly asked to create the issue, default to draft mode.
+Unresolved uncertainty also holds the comment under the conditions in
+[Post the comment](#post-the-comment). Once the uncertainty is resolved, an
+otherwise authorized source-PR comment may be posted without another approval;
+creating the docs issue remains a separate publication decision.
 
 ---
 
@@ -347,7 +380,10 @@ If the user provides a GitHub search query or asks to process multiple PRs:
 1. Search for matching PRs using the query.
 2. For each PR, run Steps 1-5.
 3. Present a summary table of all PRs with their status (already documented vs needs docs).
-4. For PRs needing docs, present drafts and ask for confirmation before creating issues.
+4. For PRs needing docs, prepare drafts and apply the publication authorization
+   rules above. In an interactive session, advance permission may cover the
+   whole specified batch; otherwise, present each draft and obtain approval
+   before creating that issue.
 
 ---
 

.github/skills/create-kbe/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: create-kbe
-description: Create or update a Known Build Error issue in dotnet/runtime from a concrete CI failure. Use when a failure is actionable, a Build Analysis result is not yet known, or a workflow needs a repo-specific KBE issue for an outer-loop or PR-targeted failure.
+description: Analyze a concrete CI failure and draft a Known Build Error issue or update in dotnet/runtime. Publish only with explicit user authorization or scoped authorization from an executing workflow's documented publication contract. Use when a failure is actionable, a Build Analysis result is not yet known, or a workflow needs a repo-specific KBE outcome for an outer-loop or PR-targeted failure.
 ---
 
 # Create a Known Build Error for dotnet/runtime
@@ -15,6 +15,30 @@ This skill is the repo-specific entry point for KBE creation. It delegates to th
 - a PR-targeted scan found an actionable failure that Build Analysis has not already recognized as known
 - a workflow needs to decide whether a candidate should become a KBE, be skipped, or be deferred for human review
 
+## Publication authorization
+
+Follow the repository's [GitHub publication authorization rules](../../copilot-instructions.md#github-publication-authorization).
+
+- In interactive and coding sessions without workflow authorization, prepare
+  a complete local draft for each proposed issue creation or update. Use the
+  draft and publication authorization pattern in
+  [PR Failure Scan Step 5](../pr-failure-scan/SKILL.md#step-5-write-draft-files-and-optionally-create-live-issues).
+  In an interactive session, explicit advance permission covering the proposed
+  publication is sufficient; do not ask again. Otherwise, present the proposed
+  title, labels, full body, destination, and publishing account and obtain
+  explicit approval before publishing. Without authorization, return the
+  draft and pending decision without publishing.
+- When actually executing a repository-configured agentic workflow, publish
+  only the operations explicitly authorized by its purpose and configured
+  outputs, through its configured output mechanism and within its limits.
+- When executing a user-requested or enabled workflow, its documented
+  publication contract may authorize the proposed issue creation or update.
+  Publish only within its declared outputs and currently authorized actions,
+  without another approval step unless the contract requires one. Invoking
+  this skill as a helper or reading workflow instructions does not grant
+  that workflow's authorization.
+- Dry-run mode never publishes. Preserve any stricter caller approval rules.
+
 ## Required workflow
 
 Read and follow these in order:
@@ -28,7 +52,7 @@ Read and follow these in order:
 - One failure shape = one KBE outcome.
 - Do not create duplicate KBEs.
 - Search existing open and recent closed KBEs before filing a new one.
-- If the failure is not caused by the PR, do not rerun CI; file or update a `Known Build Error` instead.
+- If the failure is not caused by the PR, do not rerun CI; search for an existing KBE and prepare any proposed new issue or update subject to the publication authorization rules above.
 - Do not comment on existing KBEs; Build Analysis tracks occurrence data in the issue body.
 - Only emit a KBE when the signature is stable and actionable.
 - If the issue is already known or effectively handled by existing triage, skip rather than filing a duplicate.

.github/skills/mobile-platforms/SKILL.md

@@ -94,6 +94,17 @@ Things that have caused confusion before and will again:
 
 Classify every failure as **infrastructure** or **code** before acting.
 
+Follow the repository's [GitHub publication authorization rules](../../copilot-instructions.md#github-publication-authorization)
+for all proposed issues, updates, and comments below. In an interactive
+session, explicit advance permission covering the proposed publication is
+sufficient; do not ask again. An executing workflow's documented publication
+contract may also authorize the proposed publication within its currently
+authorized actions; follow any approval conditions it requires. Otherwise, in
+interactive and coding sessions, present the complete draft and obtain explicit
+approval before publishing. Without authorization, leave the draft locally.
+A workflow's authorization covers only its declared outputs and action limits,
+not every reporting action described in this skill.
+
 ### Infrastructure failures
 
 Caused by the test environment, not code. Indicators:
@@ -103,15 +114,15 @@ Caused by the test environment, not code. Indicators:
 - Machine-specific: same test passes on other machines
 - "No space left on device", Helix agent crashes
 
-Report infrastructure failures on existing tracking issues with a table entry:
+Prepare an update for an existing tracking issue with a table entry:
 
 | Build | Date | Machine | Job | Error |
 |---|---|---|---|---|
 | [#buildNumber](link) | YYYY-MM-DD | machineName | jobName | brief error |
 
-If no matching issue exists, create one with `area-Infrastructure` and platform labels (`os-ios`, `os-tvos`, `os-maccatalyst`, `os-android`).
+If no matching issue exists, draft one with `area-Infrastructure` and platform labels (`os-ios`, `os-tvos`, `os-maccatalyst`, `os-android`).
 
-For already tracked known issues, check whether the root cause is actionable. If a code or configuration fix is feasible, open a PR. If the issue is purely infrastructure (device provisioning, network), add occurrence data to the tracking issue instead.
+For already tracked known issues, check whether the root cause is actionable. If a code or configuration fix is feasible, prepare the fix and recommend a PR; open it only when publication is authorized. If the issue is purely infrastructure (device provisioning, network), draft occurrence data for the tracking issue instead.
 
 ### Code failures
 
@@ -128,7 +139,7 @@ Investigate code failures by starting with `git log --oneline --since='3 days ag
 
 ## Self-improvement
 
-When a mobile fix workflow discovers new patterns or workarounds, record the finding as a comment on the tracking issue (or create a new issue labeled `area-Infrastructure-mono`) so the team can later incorporate it into this document. Add findings to the relevant section above:
+When a mobile fix workflow discovers new patterns or workarounds, draft a comment on the tracking issue (or a new issue labeled `area-Infrastructure-mono`) so the team can later incorporate it into this document. Publish only with the authorization described above. Include findings about:
 - New failure patterns not yet documented
 - Code paths that turned out to be relevant
 - Recurring infrastructure issues and their workarounds