/issues — the project's to-do list and memory, in GitHub issues

Every problem worth fixing becomes an issue: a claim in the paper that misleads, a table that disagrees with the code, a bug, an improvement for later. The open issues are the to-do list. When a fix lands, the issue is closed with a comment that says what was wrong, what was tried — including what did not work — and how it was fixed. Read back months later, the closed issues are the project's memory: auditable, searchable, and the same on every machine and for every co-author, which a chat transcript or a local notes file is not.

This skill makes the habit cheap. It never posts anything without showing the draft first and getting a yes.

When to use

• After a review — /review-paper, /seven-pass-review, /adjudicate-review, or findings you list yourself — to turn each confirmed problem into its own issue.
• When starting or resuming work — to see what is open for the paper, section or files at hand, and pick the next thing.
• When a fix has landed — to close its issue with a record of what happened.