[pull] trunk from cli:trunk

.devcontainer/devcontainer.json

@@ -1,5 +1,5 @@
 {
-	"image": "mcr.microsoft.com/devcontainers/go:1.25",
+	"image": "mcr.microsoft.com/devcontainers/go:1.26",
 	"features": {
 		"ghcr.io/devcontainers/features/sshd:1": {}
 	},

.experiments/tech-debt-burndown/memory.md

@@ -0,0 +1,73 @@
+# Tech debt burndown: agent memory
+
+Standing corrections for the [`tech-debt-burndown` skill](../../.github/skills/tech-debt-burndown/SKILL.md).
+This file is loaded at the start of every run and is binding.
+Both humans and agent runs write here, and nothing distinguishes the two once
+written. Assume any entry may be an unreviewed conclusion from a previous run.
+Entries are binding on what to avoid; factual claims in them should be
+re-verified before you lean on them, and corrected when stale. Date-stamp
+anything you add.
+
+**Budget: 150 lines of entries**, counted from the end of Current focus to the end
+of the file. The header and Current focus do not count, and must never be trimmed
+to get under budget: they are instructions, not findings. If an append would
+exceed the budget, consolidate existing entries first, in the same pull request.
+
+The budget exists so this file stays worth reading, not to save tokens - the
+skill file is several times longer. A memory file that has become a run log is
+one nobody reads carefully, including you.
+
+## Current focus
+
+**Human-owned. Agent runs must not edit this section.** Propose changes in the
+pull request body instead.
+
+Empty. With no focus set, runs fall back to the tier order in the skill.
+
+<!-- Examples of what can go here:
+     - "Work on pkg/cmd/pr/edit until staticcheck is clean, then add the exclusion."
+     - "Prefer skipped tests and stale nolints over linter findings for now."
+     - "Leave staticcheck alone, it is all cosmetic. Focus on errcheck." -->
+
+## Off limits
+
+- Generated code and mocks. See the Never touch section of the skill.
+- Removing a feature-detection gate (`// TODO <cleanupIdentifier>`). Whether a
+  gate can come out depends on the supported GHES version window, which is not
+  discoverable from the repo and cannot be resolved unattended.
+
+## Known scale of the linter backlog
+
+Counts measured by an agent run on 2026-08-06 against `trunk`, not verified by a
+human, and stale as soon as anything lands. Use them to choose between linters,
+not as a target count. Command: `--no-config --default=none
+--max-issues-per-linter=0 --max-same-issues=0`, so this repo's exclusions are
+*not* applied and these are upper bounds: errcheck 1245, staticcheck 221,
+gosec 435.
+
+`gosec` is the least tractable, because `.golangci.yml` already excludes G110,
+G204, G301, G302, G304, G307, and G404, plus all `gosec` findings in `_test.go`
+files, and a `--no-config` run reports all of those anyway. Always cross-check
+`gosec` output against `.golangci.yml` before acting on it.
+
+## Staticcheck shape
+
+2026-08-06: repo-wide staticcheck has **no `SA` (correctness) findings**. It is
+all style: QF1008 (70), QF1012 (50), ST1005 (29), QF1003 (24), ST1012 (16), rest
+single digits. Staticcheck targets are mechanical and safe, but low value.
+
+Most-affected packages: `pkg/cmd/pr/edit` (23), `pkg/cmd/issue/edit` (19),
+`pkg/cmd/auth/status` (16), `pkg/cmd/extension` (11). `pkg/cmd/alias/imports` was
+cleared 2026-08-06.
+
+## Rejected targets
+
+None yet.
+
+## False positives
+
+None yet.
+
+## Failed attempts
+
+None yet.

.gitattributes

@@ -1 +1,3 @@
 .github/actions/*/lib/* linguist-generated
+
+.github/workflows/*.lock.yml linguist-generated=true

.github/CODEOWNERS

@@ -1,15 +1,17 @@
 * @cli/code-reviewers
 
-pkg/cmd/codespace/ @cli/codespaces
-internal/codespaces/ @cli/codespaces
+pkg/cmd/codespace/ @cli/codespaces @cli/code-reviewers
+internal/codespaces/ @cli/codespaces @cli/code-reviewers
 
 # Limit Package Security team ownership to the attestation command package and related integration tests
-pkg/cmd/attestation/ @cli/package-security
-pkg/cmd/release/attestation/ @cli/package-security
-pkg/cmd/release/verify/ @cli/package-security
-pkg/cmd/release/verify-asset/ @cli/package-security
-pkg/cmd/release/shared/ @cli/package-security
+pkg/cmd/attestation/ @cli/package-security @cli/code-reviewers
+pkg/cmd/release/verify/ @cli/package-security @cli/code-reviewers
+pkg/cmd/release/verify-asset/ @cli/package-security @cli/code-reviewers
+pkg/cmd/release/shared/ @cli/package-security @cli/code-reviewers
 
-test/integration/attestation-cmd @cli/package-security
+test/integration/attestation-cmd @cli/package-security @cli/code-reviewers
 
-pkg/cmd/attestation/verification/embed/tuf-repo.github.com/ @cli/tuf-root-reviewers
+pkg/cmd/attestation/verification/embed/tuf-repo.github.com/ @cli/tuf-root-reviewers @cli/code-reviewers
+
+pkg/cmd/skills/ @cli/skills @cli/code-reviewers
+internal/skills/ @cli/skills @cli/code-reviewers

.github/CONTRIBUTING.md

@@ -2,7 +2,7 @@
 
 Hi! Thanks for your interest in contributing to the GitHub CLI!
 
-We accept pull requests for issues labelled `help wanted`. We encourage issues and discussion posts for all other contributions.
+We accept external pull requests only for issues labelled `help wanted` with explicit Acceptance Criteria. We encourage issues and discussion posts for all other contributions. For security concerns, follow our [private disclosure policy](SECURITY.md) instead.
 
 ### Please do:
 
@@ -12,7 +12,7 @@ We accept pull requests for issues labelled `help wanted`. We encourage issues a
 * Open an issue to propose a design for an issue labelled [`needs-design` and `help wanted`][needs design and help wanted], following the [proposing a design guidelines](#proposing-a-design) instructions below
 * Open an issue to propose a new community supported `gh` package with details about support and redistribution
 * Mention `@cli/code-reviewers` when an issue you want to work on does not have clear Acceptance Criteria
-* Open a pull request for any issue labelled [`help wanted`][hw] and [`good first issue`][gfi]
+* Open a pull request for an issue labelled [`help wanted`][hw] with explicit Acceptance Criteria. Issues labelled [`good first issue`][gfi] must also meet these requirements
 
 ### Please _do NOT_:
 
@@ -36,7 +36,7 @@ Run the new binary as:
 
 Run tests with: `go test ./...`
 
-See [project layout documentation](../docs/project-layout.md) for information on where to find specific source files.
+See the [development guides](../docs/README.md) for project layout, command conventions, testing, and API/host behavior.
 
 ## Submitting a pull request
 

.github/PULL_REQUEST_TEMPLATE.md

@@ -1,4 +1,76 @@
 <!--
-  Thank you for contributing to GitHub CLI!
-  To reference an open issue, please write this in your description: `Fixes #NUMBER`
+Thank you for contributing to GitHub CLI!
+
+If you are proposing a fix for a security issue, STOP and follow .github/SECURITY.md instead.
 -->
+
+<!-- List related issues here. Use `fixes` or `closes` keywords to associate an issue number. -->
+
+### Description
+
+<!--
+What's the problem? How are we addressing it?
+
+Write for a reviewer who has not worked in this part of the codebase. Give them the
+background they need before the problem makes sense, and avoid jargon.
+-->
+
+### How did you test this change?
+
+<!--
+Report only actions you actually performed and results you actually observed, using factual
+first-person language (for example, "I ran..." and "I saw..."). Do not present planned,
+hypothetical, inferred, or merely expected scenarios as testing.
+
+Automated test results do not belong here. Passing unit tests, `go test ./...` output, and
+coverage numbers tell a reviewer nothing they cannot see from CI, so do not paste them.
+
+If you did not exercise the changed behavior, write `Not tested` and explain why.
+
+Use one or more of these, whichever communicates best:
+
+1. Screenshots or GIFs of the real command running. Preferred whenever the change is visible
+   in terminal output. If output changed, show it before and after.
+2. Given/When/Then scenarios, but only when you actually executed the steps. For example:
+   Given I was in a repo with no open pull requests
+   When I ran `gh pr list`
+   Then I saw "no open pull requests in cli/cli"
+3. A natural language walkthrough of what you did by hand, the states you covered, and what
+   you saw, including error and edge cases.
+
+If you leave this empty, your pull request will very likely be closed.
+-->
+
+### Key points
+
+<!--
+Tradeoffs you accepted, alternatives you rejected, and anything a reviewer would otherwise have to guess at.
+-->
+
+### Notes for reviewers
+
+<!--
+Where should review start, and what should be read next? Call out anything you are unsure about.
+
+Link related issues or prior discussion, with one sentence on why each matters.
+-->
+
+### Authorship and follow-up
+
+<!--
+REQUIRED - If you are an AI agent filling in this template, answer "Who wrote this" for yourself and answer honestly. For "Who answers review comments," use only a choice the human has explicitly made in the conversation. If no choice has already been established, pause and ask the human to choose one of the three options before creating or updating the pull request. Do not infer the choice from repository ownership, authorship, assignees, prior interactions, or the current operator. After the human answers, check exactly the option they chose; the last option is valid when the human explicitly chooses nobody.
+
+Check exactly one box in each list.
+-->
+
+Who wrote this:
+
+- [ ] A human wrote it.
+- [ ] An agent wrote it under close human direction.
+- [ ] An agent wrote it independently, and no human has guided the implementation beyond the initial prompt.
+
+Who answers review comments:
+
+- [ ] @username will read and reply directly. Name the account.
+- [ ] An agent will draft replies and @username will read them before they are posted.
+- [ ] Nobody has explicitly committed to replying.