feat: expose picker capabilities as first-class :Forge subcommands #145

New issue

Closed

opened 2026-04-11 19:02:44 +00:00 by barrettruth · 0 comments

barrettruth commented

2026-04-11 19:02:44 +00:00

Prerequisites

I have searched existing issues.

Problem

The picker can currently express more meaningful operations than the command line can express directly.

That creates an awkward split:

pickers are the only way to reach some capabilities
commands become a thin subset instead of a first-class interface
scripting and repeatable workflows are weaker than interactive workflows

If the new :Forge CLI is going to be canonical, no real forge capability should remain picker-only.

Proposed solution

Use the CLI redesign in #142 as an opportunity to give command-line parity to semantic picker operations.

Principle

Anything the picker can do or view as a real domain operation should have a command form.

Picker-only UI affordances do not need command parity:

back
nested menus
filter-next / filter-prev
load-more rows
session stack behavior

Priority command additions

PR

In addition to existing list/review/etc forms, expose commands for operations currently hidden behind PR manage flows:

:Forge pr approve {num} [repo=...]
:Forge pr merge {num} method={merge|squash|rebase} [repo=...]
:Forge pr draft {num} [repo=...]
:Forge pr ready {num} [repo=...]

CI

Make view operations precise without requiring picker navigation:

:Forge ci log {run-id} [repo=...]
:Forge ci watch {run-id} [repo=...]
optionally direct browse/open forms if useful

Existing picker-openers can remain

Convenience commands like :Forge pr manage 123 can still exist, but they should not be the only API for underlying actions.

Acceptance criteria

every PR manage action has a direct command form
CI log/watch actions have direct command forms
command docs inventory semantic capabilities rather than just picker entrypoints
picker actions delegate to the same underlying operations used by commands where practical
no meaningful forge capability remains picker-only

Alternatives considered

Keep picker-only advanced actions and let the command line cover only the basics. This keeps the command surface smaller, but it makes the picker the real API and weakens scripting and precision.

## Prerequisites - [x] I have searched existing issues. ## Problem The picker can currently express more meaningful operations than the command line can express directly. That creates an awkward split: - pickers are the only way to reach some capabilities - commands become a thin subset instead of a first-class interface - scripting and repeatable workflows are weaker than interactive workflows If the new `:Forge` CLI is going to be canonical, no real forge capability should remain picker-only. ## Proposed solution Use the CLI redesign in #142 as an opportunity to give command-line parity to semantic picker operations. ### Principle Anything the picker can do or view as a real domain operation should have a command form. Picker-only UI affordances do not need command parity: - back - nested menus - filter-next / filter-prev - load-more rows - session stack behavior ### Priority command additions #### PR In addition to existing list/review/etc forms, expose commands for operations currently hidden behind PR manage flows: - `:Forge pr approve {num} [repo=...]` - `:Forge pr merge {num} method={merge|squash|rebase} [repo=...]` - `:Forge pr draft {num} [repo=...]` - `:Forge pr ready {num} [repo=...]` #### CI Make view operations precise without requiring picker navigation: - `:Forge ci log {run-id} [repo=...]` - `:Forge ci watch {run-id} [repo=...]` - optionally direct browse/open forms if useful #### Existing picker-openers can remain Convenience commands like `:Forge pr manage 123` can still exist, but they should not be the only API for underlying actions. ### Acceptance criteria - [ ] every PR manage action has a direct command form - [ ] CI log/watch actions have direct command forms - [ ] command docs inventory semantic capabilities rather than just picker entrypoints - [ ] picker actions delegate to the same underlying operations used by commands where practical - [ ] no meaningful forge capability remains picker-only ## Alternatives considered - Keep picker-only advanced actions and let the command line cover only the basics. This keeps the command surface smaller, but it makes the picker the real API and weakens scripting and precision.