glab-cli

# GLab CLI Use `glab` with host-aware defaults instead of hardcoding `gitlab.com`. ## Workflow Follow this order unless the user explicitly asks for a single command. ### 1. Let `glab` use the current context by default Do not run host detection by default. In a Git repository, prefer: ```bash glab <command> ``` Only add `GITLAB_HOST`, `--hostname`, or `-R` when the task targets another repo or another instance, or when `glab` resolves the wrong context. ### 2. Detect the platform only when context is unclear or failing Check `git remote -v` only when: - `glab` resolves to the wrong instance - auth checks fail against an unexpected host - the repository has both GitHub and GitLab remotes - multiple GitLab hosts are present - the task targets a different instance than the current directory Rules: - Prefer a GitLab remote over any GitHub or Bitbucket remote. - If the remote host is `gitlab.com`, treat the platform as `gitlab.com`. - If the remote host is anything else, treat the platform as `self-managed-or-dedicated`. - If multiple GitLab hosts appear in `git remote -v`, treat the result as ambiguous and confirm before any write operation. - If `GITLAB_HOST` is already set, let it override the remote-derived host. If `git remote -v` does not show a GitLab remote: - check whether the user is in the intended repository - ask for the GitLab host or repository URL only if the task is otherwise blocked - avoid guessing `gitlab.com` for a private installation If mult...