gh

**Quick judgment** A solid, practical skill that exposes the GitHub CLI (`gh`) to an agent for core GitHub workflows (repos, issues, PRs, releases). It’s well-aligned with GitHub’s standard tooling and appears suitable for day-to-day repo management and automation, assuming `gh` is properly installed and authenticated in the runtime environment. **Key strengths** - Broad coverage of common GitHub operations (auth, repo create/clone/fork, issues, PRs, releases). - Uses explicit commands and `--confirm`, which is appropriate for non-interactive, automated use. - Emphasizes returning URLs so users can quickly inspect results in the browser. - Private-by-default repo creation is a sensible security baseline. **Risks and limitations** - **Destructive potential**: Repo management, merges, and other operations can be destructive if the wrong repo/owner/branch is targeted. There is some safety guidance, but enforcement ultimately depends on how the calling agent builds commands. - **Context sensitivity**: Behavior may depend on the current working directory (e.g., `gh pr create` or `gh repo view`), increasing the risk of acting on the wrong repository if context is mismanaged. - **Auth and permissions**: Requires `gh` to be configured and logged in with appropriate scopes; failures may be non-obvious if not handled robustly. - **Environment dependency**: Requires `gh` to be installed and up to date; version mismatches or missing binary will cause failures. **Recommended scenarios** - Agent-driven GitHub housekeeping: creating and initializing repos, cloning/forking for new contributions, or routine PR/issue triage. - Developer productivity assistants that need to open, list, or merge PRs and manage issues without leaving the terminal. - Release or tooling bots that create releases/tags and post links back to users. - Non-destructive queries (auth status, repo view, list issues/PRs) where risk is low and the CLI interface is stable. **Use with extra caution** - When performing merges, deletes, or other destructive operations, ensure the agent double-checks repo owner/name and branch, and ideally surfaces a summary to the user before executing. - In multi-repo environments where the current directory may not match the intended target repo; prefer explicit `OWNER/NAME` arguments wherever possible. - In shared or CI environments, verify that `gh` is correctly authenticated with least-privilege tokens and that logs do not leak sensitive repo details or access tokens.