Accept -R/--repo after resource commands #38

New issue

Closed

opened 2026-06-18 23:14:41 +01:00 by vnprc-agent · 0 comments

vnprc-agent commented

2026-06-18 23:14:41 +01:00

Member

Problem

forge only accepts -R/--repo before the resource:

forge -R owner/repo issue create ...

The GitHub CLI habit is to place the repository flag on the subcommand:

gh issue create -R owner/repo ...
forge issue create -R owner/repo ...

forge issue create -R owner/repo ... currently fails with forge: unknown option for issue create: -R because the top-level parser stops before command-specific argument parsing. This is easy for agents and humans to get wrong when muscle memory comes from gh.

Proposed behavior

Accept -R / --repo both before and after the resource/command for every command that needs a repository, matching gh ergonomics while keeping the current supported form.

Examples that should work:

forge -R vnprc/nexus issue create -t "Title" -b "Body"
forge issue create -R vnprc/nexus -t "Title" -b "Body"
forge issue list --repo vnprc/nexus
forge pr create -R vnprc/nexus -t "Title" -b "Body"

Acceptance sketch

Existing forge -R owner/repo ... behavior remains unchanged.
Command-level -R / --repo works for issue and PR read/write commands.
Tests cover at least issue create, issue list, and pr create with command-level repo flags.
Error messages remain clear when -R is missing its value.

## Problem `forge` only accepts `-R/--repo` before the resource: ```sh forge -R owner/repo issue create ... ``` The GitHub CLI habit is to place the repository flag on the subcommand: ```sh gh issue create -R owner/repo ... forge issue create -R owner/repo ... ``` `forge issue create -R owner/repo ...` currently fails with `forge: unknown option for issue create: -R` because the top-level parser stops before command-specific argument parsing. This is easy for agents and humans to get wrong when muscle memory comes from `gh`. ## Proposed behavior Accept `-R` / `--repo` both before and after the resource/command for every command that needs a repository, matching `gh` ergonomics while keeping the current supported form. Examples that should work: ```sh forge -R vnprc/nexus issue create -t "Title" -b "Body" forge issue create -R vnprc/nexus -t "Title" -b "Body" forge issue list --repo vnprc/nexus forge pr create -R vnprc/nexus -t "Title" -b "Body" ``` ## Acceptance sketch - Existing `forge -R owner/repo ...` behavior remains unchanged. - Command-level `-R` / `--repo` works for issue and PR read/write commands. - Tests cover at least `issue create`, `issue list`, and `pr create` with command-level repo flags. - Error messages remain clear when `-R` is missing its value.