What do you want to change?
Extend hunk session navigate with a --comment <comment-id> selector so the CLI can jump the live viewport to a specific comment by ID, the same way it can already jump by file/hunk/line or by --next-comment / --prev-comment.
Why?
Today the navigate subcommand only accepts three kinds of targets:
- an absolute position (
--file <path> + --hunk <n> / --old-line <n> / --new-line <n>)
- the next comment (
--next-comment)
- the previous comment (
--prev-comment)
The comment IDs that hunk session comment list prints are otherwise opaque: a script can read them, but it has no way to ask the running TUI to focus one. The closest workaround is navigate --file <path> --new-line <n> after parsing the comment payload, which is two round-trips and breaks if the comment was anchored to a different side or to a hunk-relative target.
For agent-driven review flows that read the comment list with --json, pick the comment they want the human to look at next, and then steer the TUI there, the missing selector is the last hand-off step. A direct --comment <id> flag closes the loop and matches the existing ergonomics (--file / --hunk / --old-line / --new-line / --next-comment / --prev-comment are all first-class peers).
How? (optional)
- Add
.option("--comment <id>", "focus the viewport on the comment with this id") to the session navigate commander setup, alongside the existing positional/option flags.
- In
requireNavigateTarget (or whichever validator currently enforces "exactly one target"), accept --comment <id> as a fourth mutually-exclusive target and reject it when combined with --file, --hunk, --old-line, --new-line, --next-comment, or --prev-comment so the matcher stays unambiguous.
- Resolve
--comment <id> in the daemon: look up the comment by id (the same path comment list already walks), read its filePath / hunkIndex / side / line, and emit the same navigate payload you'd get from the equivalent --file --hunk --side --line triple — no new payload field, no new socket verb, just a server-side resolver.
- Add unit coverage for the commander option (mutual exclusion) and a daemon-level test that
--comment <id> lands the viewport on the right hunk+side+line.
- Add one
--json example to docs/agent-workflows.md showing the read-comment-then-navigate loop.
What do you want to change?
Extend
hunk session navigatewith a--comment <comment-id>selector so the CLI can jump the live viewport to a specific comment by ID, the same way it can already jump by file/hunk/line or by--next-comment/--prev-comment.Why?
Today the
navigatesubcommand only accepts three kinds of targets:--file <path>+--hunk <n>/--old-line <n>/--new-line <n>)--next-comment)--prev-comment)The comment IDs that
hunk session comment listprints are otherwise opaque: a script can read them, but it has no way to ask the running TUI to focus one. The closest workaround isnavigate --file <path> --new-line <n>after parsing the comment payload, which is two round-trips and breaks if the comment was anchored to a different side or to a hunk-relative target.For agent-driven review flows that read the comment list with
--json, pick the comment they want the human to look at next, and then steer the TUI there, the missing selector is the last hand-off step. A direct--comment <id>flag closes the loop and matches the existing ergonomics (--file/--hunk/--old-line/--new-line/--next-comment/--prev-commentare all first-class peers).How? (optional)
.option("--comment <id>", "focus the viewport on the comment with this id")to thesession navigatecommander setup, alongside the existing positional/option flags.requireNavigateTarget(or whichever validator currently enforces "exactly one target"), accept--comment <id>as a fourth mutually-exclusive target and reject it when combined with--file,--hunk,--old-line,--new-line,--next-comment, or--prev-commentso the matcher stays unambiguous.--comment <id>in the daemon: look up the comment by id (the same pathcomment listalready walks), read itsfilePath/hunkIndex/side/line, and emit the samenavigatepayload you'd get from the equivalent--file --hunk --side --linetriple — no new payload field, no new socket verb, just a server-side resolver.--comment <id>lands the viewport on the right hunk+side+line.--jsonexample todocs/agent-workflows.mdshowing the read-comment-then-navigate loop.