Context
I've been trying to use Hunk as my primary human code-review tool (not just for agent-driven review sessions). Two gaps stood out enough to write up:
1. No keyboard binding to edit or delete a user review note
Once a c note is saved, the only way to remove it is clicking the [x] in its top border with the mouse — there's no bound command for this (confirmed there's no hunk.review.* command for delete in the keybindings table, so it can't even be remapped to something).
Editing an already-saved note isn't possible at all, mouse or keyboard — the only workaround is delete-and-redraft.
For a tool that's otherwise very keyboard-first (c to draft, Ctrl+S to save, ]/[ to navigate hunks...), having to reach for the mouse just to delete a note — and having no path at all to fix a typo in one — breaks the flow. This is probably the single thing most likely to make me bounce off a fully keyboard-driven review session.
Related: #380 covers CLI-level comment editing and mentions a TUI keybinding as a "nice companion" — from where I'm sitting, the TUI keybinding (for both edit and delete) is the primary ask, not a companion to the CLI one.
2. No built-in way to turn notes into a GitHub PR review
Right now, going from "notes I left in Hunk" to "a review posted on the actual GitHub PR" requires a custom workaround — I ended up writing an agent skill that reads hunk session comment list --type user --json, cleans the notes up, and posts them as a pending/draft GitHub PR review via the API. It works, but it's exactly the kind of thing I'd expect Hunk to offer natively, especially since hunk session comment list --json already gives clean structured data that maps almost 1:1 onto GitHub's review-comment shape (path/line/side/body).
Related open issues that cover pieces of this: #460 (publish agent notes as a GitHub review), #465 (hunk diff --pr), #487 (the reverse direction — importing GitHub review comments in). Flagging this issue mainly to attach real usage motivation to that cluster — "I built the round-trip myself and it took real effort" is the signal I wanted to leave, in case it helps prioritize.
Environment
- Hunk 0.18.0 (Homebrew, macOS arm64)
Context
I've been trying to use Hunk as my primary human code-review tool (not just for agent-driven review sessions). Two gaps stood out enough to write up:
1. No keyboard binding to edit or delete a user review note
Once a
cnote is saved, the only way to remove it is clicking the[x]in its top border with the mouse — there's no bound command for this (confirmed there's nohunk.review.*command for delete in the keybindings table, so it can't even be remapped to something).Editing an already-saved note isn't possible at all, mouse or keyboard — the only workaround is delete-and-redraft.
For a tool that's otherwise very keyboard-first (
cto draft,Ctrl+Sto save,]/[to navigate hunks...), having to reach for the mouse just to delete a note — and having no path at all to fix a typo in one — breaks the flow. This is probably the single thing most likely to make me bounce off a fully keyboard-driven review session.Related: #380 covers CLI-level comment editing and mentions a TUI keybinding as a "nice companion" — from where I'm sitting, the TUI keybinding (for both edit and delete) is the primary ask, not a companion to the CLI one.
2. No built-in way to turn notes into a GitHub PR review
Right now, going from "notes I left in Hunk" to "a review posted on the actual GitHub PR" requires a custom workaround — I ended up writing an agent skill that reads
hunk session comment list --type user --json, cleans the notes up, and posts them as a pending/draft GitHub PR review via the API. It works, but it's exactly the kind of thing I'd expect Hunk to offer natively, especially sincehunk session comment list --jsonalready gives clean structured data that maps almost 1:1 onto GitHub's review-comment shape (path/line/side/body).Related open issues that cover pieces of this: #460 (publish agent notes as a GitHub review), #465 (
hunk diff --pr), #487 (the reverse direction — importing GitHub review comments in). Flagging this issue mainly to attach real usage motivation to that cluster — "I built the round-trip myself and it took real effort" is the signal I wanted to leave, in case it helps prioritize.Environment