### Summary Installing glab and then accessing duo cli through it has a confusing out of box experience (first time use experience). The only way to launch duo under glab if glab did the runtime install seems to be to completely enter the duo cli subshell - but `glab duo --help` makes it seem like one can run one command in the duo subshell from the glab shell. ### Steps to reproduce If I: 1. Install glab on a machine that has never had it. 2. And run glab duo --help I get a usage message "glab duo <command> prompt [command] [--flags]" 3. Run `glab duo explain "the code in my repo"` or `glab duo "/explain the code in my repo"` or `glab duo cli explain "the code in my repo"` I get the error error: `too many arguments. Expected 0 arguments but got 1.` - which clearly contradicts the help (which I think is coming from glab). 4. If I run `glab duo` I get prompted through installing duo cli. 5. Then if I run any of the above commands I get the same `too many arguments. Expected 0 arguments but got 1.` 6. Then if I run `glab duo` I get an initialization screen and `Initializing - ❌ Error: No token provided Reason: invalid_token Credentials source: no credentials found Run 'glab auth login' to authenticate.` 7. After authorization is successfully handled, attempting any direct command by `glab duo` get's the too many arguments error 8. Trying 'glab duo" required more setup steps. ### Example Project 1. From a clean VM or machine that does not have glab nor duo cli 2. Install only glab 3. Try `glab duo --help` and see that it implies the ability to execute the subshell in the current shell. 4. Do `glab duo` and follow prompts to install. 5. Do `glab duo` and follow prompts to authenticate. 6. Do `glab duo help` and you get the actual duo cli help 7. Do `glab duo --help` and you get the help stub from glab that still does not clearly connote that duo must be used as a subshell or only the commands in `glab duo help` (NO dashes) ### What is the current *bug* behavior? 1. The help stub for `glab duo --help` is confusing: - This specific documentation is wrong because it implies - It does not list the actual duo cli subcommands - It is not smart enough to know whether duo cli is not installed and give commands to get setup and authorized. 2. Once duo cli is setup via glab, the command `glab duo --help` does not pass through to the same content as `glab duo help` (no dashes) ### What is the expected *correct* behavior? 1. Correct glab duo --help output to be accurate 2. [Desirable] Make it smart about whether DUO cli has been installed yet (especially if it was installed by the glab duo command execution) and present help that tells how to resolve the runtime install 3. If glab duo is installed, `glab duo --help` and `glab duo help` should produce identical results. ### Relevant logs and/or screenshots {width=900 height=522} ### Output of checks <!-- If you are reporting a bug on GitLab.com, uncomment below --> <!-- This bug happens on GitLab.com --> <!-- and uncomment below if you have /label privileges --> <!-- /label ~"reproduced on GitLab.com" --> <!-- or follow up with an issue comment of `@gitlab-bot label ~"reproduced on GitLab.com"` if you do not --> #### Results of GitLab environment info <!-- Input any relevant GitLab environment information if needed. --> <details> <summary>Expand for output related to GitLab environment info</summary> <pre> (For installations with omnibus-gitlab package run and paste the output of: `sudo gitlab-rake gitlab:env:info`) (For installations from source run and paste the output of: `sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production`) </pre> </details> #### Results of GitLab application Check <!-- Input any relevant GitLab application check information if needed. --> <details> <summary>Expand for output related to the GitLab application check</summary> <pre> (For installations with omnibus-gitlab package run and paste the output of: `sudo gitlab-rake gitlab:check SANITIZE=true`) (For installations from source run and paste the output of: `sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true`) (we will only investigate if the tests are passing) </pre> </details> ### Possible fixes <!-- If you can, link to the line of code that might be responsible for the problem. --> ### Patch release information for backports If the bug fix needs to be backported in a [patch release](https://handbook.gitlab.com/handbook/engineering/releases/patch-releases) to a version under [the maintenance policy](https://docs.gitlab.com/policy/maintenance/), please follow the steps on the [patch release runbook for GitLab engineers](https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/patch/engineers.md). Refer to the [internal "Release Information" dashboard](https://dashboards.gitlab.net/d/delivery-release_info/delivery3a-release-information?orgId=1) for information about the next patch release, including the targeted versions, expected release date, and current status. #### High-severity bug remediation To remediate high-severity issues requiring an [internal release](https://handbook.gitlab.com/handbook/engineering/releases/internal-releases/) for single-tenant SaaS instances, refer to the [internal release process for engineers](https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/internal-releases/engineers.md?ref_type=heads). <!-- If you don't have /label privileges, follow up with an issue comment of `@gitlab-bot label ~"type::bug"` -->