Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
73 changes: 73 additions & 0 deletions .experiments/tech-debt-burndown/memory.md
Original file line number Diff line number Diff line change
@@ -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.
18 changes: 15 additions & 3 deletions .github/PULL_REQUEST_TEMPLATE.md
Original file line number Diff line number Diff line change
Expand Up @@ -18,9 +18,21 @@ background they need before the problem makes sense, and avoid jargon.
### How did you test this change?

<!--
Demonstrate the code is solid, and how you know it solves the problem in the description.
Give the exact commands you ran and their output.
If this changes command output, show it before and after. Screenshot images are preferred over pasted text.
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.
-->
Expand Down
Loading
Loading