[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 merge=ours

.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/PULL_REQUEST_TEMPLATE.md

@@ -1,4 +1,72 @@
 <!--
-  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?
+
+<!--
+Show how you exercised the change yourself, as a user of `gh` would.
+
+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.
+
+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. For example:
+   Given I am in a repo with no open pull requests
+   When I run `gh pr list`
+   Then I see "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.