你帮我尽可能全的统计gh这个工具有多少个命令 要尽可能全


用户想要统计 gh（GitHub CLI）工具有多少个命令，要尽可能全面。让我先加载相关的 skill，然后执行 gh 命令来统计。

让我先加载相关 skill，然后全面统计 gh 的命令数量。


---
name: github-gh-skill
description: 使用 GitHub CLI（`gh`）处理认证、仓库、Issue、Pull Request、Actions、Release，以及通过 JSON/JQ 调用 API 查询数据。适用于用户提到 `gh`、GitHub CLI、终端里的 GitHub、PR、Issue、Actions、Release，或需要不打开浏览器直接获取 GitHub 数据的场景。
---

# GitHub CLI（gh）技能

## 何时启用

用户提到：`gh`、GitHub CLI、命令行操作 GitHub、PR/Issue/Release/Actions、或需要从终端拉取 GitHub 信息时，优先按本技能执行。

## 前置检查（一次性）

1. **检查 `gh` 是否已安装**：执行 `gh --version`。
   - 若命令不存在，**自动安装最新版**：根据系统包管理器执行安装（如 `apt install gh -y`、`yum install gh -y`、`brew install gh`）。
   - 安装失败再**提示用户手动安装**（参考官网 <https://cli.github.com/>）。
2. 若需私有资源，执行 `gh auth status`；未登录则 `gh auth login`（非 CI 场景由用户完成交互）。
3. 需要脚本化检测时，运行跨平台脚本：`python scripts/check_gh.py`（或 `python3 ...`，仅需 Python 3.8+ 与标准库）。

## 高效原则（给 Agent）

- **优先机器可读**：能用 `--json` 就用；需要筛选时用 `--jq`（避免解析人类表格输出）。
- **减少交互**：批量操作用 `--yes` / `-y`；需要合并且非交互时用环境变量或文档中的标志位（见 [reference.md](reference.md)）。
- **先定目标再选子命令**：issue / pr / repo / workflow / release / api —— 不要猜，缺参数时 `gh <cmd> --help`。
- **API 兜底**：`gh` 子命令缺能力时用 `gh api`，路径以官方 REST 为准。

## 模块索引（按场景跳转）

| 模块 | 内容 |
|------|------|
| A. 认证与上下文 | `gh auth`，默认仓库 |
| B. 仓库 | `gh repo clone/view/create` |
| C. Issue | `gh issue list/create/view/close` |
| D. PR | `gh pr list/create/view/diff/merge/checkout` |
| E. Actions | `gh run list/view/watch/rerun` |
| F. Release | `gh release list/create` |
| G. 高级 | `gh api`，GraphQL |

**详细命令与模板**见 [reference.md](reference.md)。

## A. 认证与上下文

- 查看登录：`gh auth status`
- 设置默认仓库（减少重复 `-R`）：在仓库目录内 `gh repo set-default`

## B. 仓库

- 克隆：`gh repo clone owner/name`
- 当前仓库信息（JSON）：`gh repo view --json name,owner,url,defaultBranchRef`

## C. Issue

- 列表（JSON）：`gh issue list --json number,title,state,author,labels`
- 创建：`gh issue create --title "..." --body "..."`

## D. Pull Request

- 列表：`gh pr list --json number,title,state,headRefName`
- 检出本地分支：`gh pr checkout <number>`
- 查看差异：`gh pr diff <number>`

## E. GitHub Actions（workflow / run）

- 运行列表：`gh run list --limit 20`
- 单次运行详情 + 日志：`gh run view <run-id> --log`

## F. Release 与标签

- 列表：`gh release list --limit 20`
- 创建（需明确 tag 与说明）：`gh release create <tag> --notes "..."`

## G. `gh api`（REST）

- GET 示例：`gh api repos/{owner}/{repo}/issues --jq '.[0].title'`
- 占位符：`{owner}` `{repo}` 在已关联 git remote 时常可自动解析；不确定时显式传 `-R owner/repo`。

## 错误处理

- **401/403**：检查 `gh auth status`、token 权限（repo、workflow 等）。
- **未找到命令**：升级 `gh` 或改用 `gh api`。
- **交互阻塞**：CI/自动化中避免会打开编辑器的命令；为 `pr merge` 等加 `--merge`/`--squash`/`--rebase` 等非交互选项。

## 附加资源

- 完整命令表与 JSON 字段提示：[reference.md](reference.md)
- 环境检查脚本（模块化，中文注释；跨平台，仅标准库）：[scripts/check_gh.py](scripts/check_gh.py)


gh version 2.92.0 (2026-04-28)
https://github.com/cli/cli/releases/tag/v2.92.0


好的，用户想要全面统计 gh 工具有多少个命令。gh 版本是 2.92.0。我需要尽可能全面地列出所有命令和子命令。

让我先获取顶层命令，然后逐层展开。

好的，让我尽可能全面地统计 gh 的所有命令。先从顶层开始，然后逐层展开。

bash

gh --help 2>&1 | grep -E '^\s+\w' | awk '{print $1}'


Work seamlessly with GitHub from the command line.

USAGE
  gh <command> <subcommand> [flags]

CORE COMMANDS
  auth:          Authenticate gh and git with GitHub
  browse:        Open repositories, issues, pull requests, and more in the browser
  codespace:     Connect to and manage codespaces
  gist:          Manage gists
  issue:         Manage issues
  org:           Manage organizations
  pr:            Manage pull requests
  project:       Work with GitHub Projects.
  release:       Manage releases
  repo:          Manage repositories
  skill:         Install and manage agent skills (preview)

GITHUB ACTIONS COMMANDS
  cache:         Manage GitHub Actions caches
  run:           View details about workflow runs
  workflow:      View details about GitHub Actions workflows

ALIAS COMMANDS
  co:            Alias for "pr checkout"

ADDITIONAL COMMANDS
  agent-task:    Work with agent tasks (preview)
  alias:         Create command shortcuts
  api:           Make an authenticated GitHub API request
  attestation:   Work with artifact attestations
  completion:    Generate shell completion scripts
  config:        Manage configuration for gh
  copilot:       Run the GitHub Copilot CLI (preview)
  extension:     Manage gh extensions
  gpg-key:       Manage GPG keys
  label:         Manage labels
  licenses:      View third-party license information
  preview:       Execute previews for gh features
  ruleset:       View info about repo rulesets
  search:        Search for repositories, issues, and pull requests
  secret:        Manage GitHub secrets
  ssh-key:       Manage SSH keys
  status:        Print information about relevant issues, pull requests, and notifications across repositories
  variable:      Manage GitHub Actions variables

HELP TOPICS
  accessibility: Learn about GitHub CLI's accessibility experiences
  actions:       Learn about working with GitHub Actions
  environment:   Environment variables that can be used with gh
  exit-codes:    Exit codes used by gh
  formatting:    Formatting options for JSON data exported from gh
  mintty:        Information about using gh with MinTTY
  reference:     A comprehensive reference of all gh commands
  telemetry:     Information about telemetry in gh

FLAGS
  --help      Show help for command
  --version   Show gh version

EXAMPLES
  $ gh issue create
  $ gh repo clone cli/cli
  $ gh pr checkout 321

LEARN MORE
  Use `gh <command> <subcommand> --help` for more information about a command.
  Read the manual at https://cli.github.com/manual
  Learn about exit codes using `gh help exit-codes`
  Learn about accessibility experiences using `gh help accessibility`


gh
auth:
browse:
codespace:
gist:
issue:
org:
pr:
project:
release:
repo:
skill:
cache:
run:
workflow:
co:
agent-task:
alias:
api:
attestation:
completion:
config:
copilot:
extension:
gpg-key:
label:
licenses:
preview:
ruleset:
search:
secret:
ssh-key:
status:
variable:
accessibility:
actions:
environment:
exit-codes:
formatting:
mintty:
reference:
telemetry:
Use
Read
Learn
Learn


好的，我已经得到了顶层命令的列表。现在我需要展开每个命令的子命令，以便得到更完整的统计。让我逐个获取每个主要命令的子命令。

好的，顶层命令已经出来了。现在展开每个命令的子命令：

for cmd in auth browse codespace gist issue org pr project release repo skill cache run workflow agent-task alias api attestation completion config copilot extension gpg-key label licenses preview ruleset search secret ssh-key status variable; do
  echo "=== $cmd ==="
  gh $cmd --help 2>&1 | grep -A 1000 'AVAILABLE COMMANDS' | grep -B 1000 '^$' | grep -E '^\s+\w' | awk '{print "  " $1}'
  echo ""
done


=== auth ===
  login:
  logout:
  refresh:
  setup-git:
  status:
  switch:
  token:
  Use
  Read
  Learn
  Learn

=== browse ===

=== codespace ===
  code:
  cp:
  create:
  delete:
  edit:
  jupyter:
  list:
  logs:
  ports:
  rebuild:
  ssh:
  stop:
  view:
  Use
  Read
  Learn
  Learn

=== gist ===
  clone:
  create:
  delete:
  edit:
  list:
  rename:
  view:
  A
  Use
  Read
  Learn
  Learn

=== issue ===

=== org ===

=== pr ===

=== project ===
  close:
  copy:
  create:
  delete:
  edit:
  field-create:
  field-delete:
  field-list:
  item-add:
  item-archive:
  item-create:
  item-delete:
  item-edit:
  item-list:
  link:
  list:
  mark-template:
  unlink:
  view:
  Use
  Read
  Learn
  Learn

=== release ===

=== repo ===

=== skill ===
  install:
  preview:
  publish:
  search:
  update:
  Use
  Read
  Learn
  Learn

=== cache ===
  delete:
  list:
  Use
  Read
  Learn
  Learn

=== run ===
  cancel:
  delete:
  download:
  list:
  rerun:
  view:
  watch:
  Use
  Read
  Learn
  Learn

=== workflow ===
  disable:
  enable:
  list:
  run:
  view:
  Use
  Read
  Learn
  Learn

=== agent-task ===
  create:
  list:
  view:
  A
  Identifying
  there
  Use
  Read
  Learn
  Learn

=== alias ===
  delete:
  import:
  list:
  set:
  Use
  Read
  Learn
  Learn

=== api ===

=== attestation ===
  download:
  trusted-root:
  verify:
  Use
  Read
  Learn
  Learn

=== completion ===

=== config ===
  clear-cache:
  get:
  list:
  set:
  Use
  Read
  Learn
  Learn

=== copilot ===

=== extension ===
  browse:
  create:
  exec:
  install:
  list:
  remove:
  search:
  upgrade:
  Use
  Read
  Learn
  Learn

=== gpg-key ===
  add:
  delete:
  list:
  Use
  Read
  Learn
  Learn

=== label ===
  clone:
  create:
  delete:
  edit:
  list:
  Use
  Read
  Learn
  Learn

=== licenses ===

=== preview ===
  prompter:
  Use
  Read
  Learn
  Learn

=== ruleset ===
  check:
  list:
  view:
  Use
  Read
  Learn
  Learn

=== search ===
  code:
  commits:
  issues:
  prs:
  repos:
  Use
  Read
  Learn
  Learn

=== secret ===
  delete:
  list:
  set:
  Use
  Read
  Learn
  Learn

=== ssh-key ===
  add:
  delete:
  list:
  Use
  Read
  Learn
  Learn

=== status ===

=== variable ===
  delete:
  get:
  list:
  set:
  Use
  Read
  Learn
  Learn


用户想要尽可能全面地统计 gh 工具的所有命令。让我继续展开更深层的子命令，并检查那些没有显示子命令的顶层命令的子命令。

需要展开的命令包括：
- issue（没有显示子命令，但肯定有很多）
- org
- pr
- release
- repo
- copilot
- licenses

这些可能需要更仔细地获取。

另外还需要检查一些子命令下的子命令，比如：
- codespace ports 的子命令
- run rerun 的子命令
- secret 的各级作用域子命令
等等。

让我继续深挖。

好，继续深挖那些没展开的命令和更深层子命令：

for cmd in issue org pr release repo copilot licenses; do
  echo "=== $cmd ==="
  gh $cmd --help 2>&1 | grep -A 1000 'AVAILABLE COMMANDS\|COMMANDS' | grep -B 1000 '^\s*$' | grep -E '^\s+\w' | awk '{print "  " $1}'
  echo ""
done


=== issue ===
  create:
  list:
  status:
  close:
  comment:
  delete:
  develop:
  edit:
  lock:
  pin:
  reopen:
  transfer:
  unlock:
  unpin:
  view:
  An
  Use
  Read
  Learn
  Learn

=== org ===
  list:
  Use
  Read
  Learn
  Learn

=== pr ===
  create:
  list:
  status:
  checkout:
  checks:
  close:
  comment:
  diff:
  edit:
  lock:
  merge:
  ready:
  reopen:
  revert:
  review:
  unlock:
  update-branch:
  view:
  A
  Use
  Read
  Learn
  Learn

=== release ===
  create:
  list:
  delete:
  delete-asset:
  download:
  edit:
  upload:
  verify:
  verify-asset:
  view:
  Use
  Read
  Learn
  Learn

=== repo ===
  create:
  list:
  archive:
  autolink:
  clone:
  delete:
  deploy-key:
  edit:
  fork:
  gitignore:
  license:
  rename:
  set-default:
  sync:
  unarchive:
  view:
  A
  Use
  Read
  Learn
  Learn

=== copilot ===

=== licenses ===


用户要求尽可能全面地统计 gh 工具的所有命令。我已经获取了顶层命令和一级子命令。现在我需要继续深入获取更深层的子命令，比如 `gh repo autolink`、`gh repo deploy-key`、`gh repo gitignore`、`gh repo license`、`gh repo sync`、`gh run rerun`、`gh codespace ports`、`gh secret list` 等等。

让我继续挖掘更深层的子命令。

继续深挖更深层的子命令：

for cmd in "repo autolink" "repo deploy-key" "repo gitignore" "repo license" "repo sync" "run rerun" "codespace ports" "codespace ssh" "copilot"; do
  echo "=== $cmd ==="
  gh $cmd --help 2>&1 | grep -A 1000 'AVAILABLE COMMANDS\|COMMANDS' | grep -B 1000 '^\s*$' | grep -E '^\s+\w' | awk '{print "  " $1}'
  echo ""
done


=== repo autolink ===
  create:
  delete:
  list:
  view:
  Use
  Read
  Learn
  Learn

=== repo deploy-key ===
  add:
  delete:
  list:
  Use
  Read
  Learn
  Learn

=== repo gitignore ===
  list:
  view:
  Use
  Read
  Learn
  Learn

=== repo license ===
  list:
  view:
  Use
  Read
  Learn
  Learn

=== repo sync ===

=== run rerun ===

=== codespace ports ===
  forward:
  visibility:
  browseUrl,
  Use
  Read
  Learn
  Learn

=== codespace ssh ===

=== copilot ===


The user wants me to continue gathering all subcommands of gh. Let me continue exploring deeper levels. Let me check the remaining commands that have subcommands, like `secret list`, `secret set`, `variable list`, etc., and also check if there are any more levels deep.

Let me get a more comprehensive approach - use `gh help reference` or try to get all commands at once.

# Try to get the full reference
gh help reference 2>&1 | head -200

# Check deeper: secret/variable scope subcommands, extension browse, etc.
for cmd in "secret list" "secret set" "secret delete" "variable list" "variable get" "variable set" "variable delete" "extension browse" "gist rename"; do
  echo "=== $cmd ==="
  gh $cmd --help 2>&1 | grep -A 50 'AVAILABLE COMMANDS\|COMMANDS' | grep -B 50 '^\s*$' | grep -E '^\s+\w' | awk '{print "  " $1}'
  echo ""
done


# gh reference

## gh agent-task <command>

Work with agent tasks (preview)

Aliases

gh agent-tasks, gh agent, gh agents

### gh agent-task create [<task description>] [flags]

Create an agent task (preview)

  -b, --base string           Base branch for the pull request (use default branch if not provided)
  -a, --custom-agent string   Use a custom agent for the task. e.g., use 'my-agent' for the 'my-agent.md' agent
      --follow                Follow agent session logs
  -F, --from-file file        Read task description from file (use "-" to read from standard input)

### gh agent-task list [flags]

List agent tasks (preview)

  -q, --jq expression     Filter JSON output using a jq expression
      --json fields       Output JSON with the specified fields
  -L, --limit int         Maximum number of agent tasks to fetch (default 30)
  -t, --template string   Format JSON output using a Go template; see "gh help formatting"
  -w, --web               Open agent tasks in the browser

### gh agent-task view [<session-id> | <pr-number> | <pr-url> | <pr-branch>] [flags]

View an agent task session (preview)

      --follow            Follow agent session logs
  -q, --jq expression     Filter JSON output using a jq expression
      --json fields       Output JSON with the specified fields
      --log               Show agent session logs
  -t, --template string   Format JSON output using a Go template; see "gh help formatting"
  -w, --web               Open agent task in the browser

## gh alias <command>

Create command shortcuts

### gh alias delete {<alias> | --all} [flags]

Delete set aliases

  --all   Delete all aliases

### gh alias import [<filename> | -] [flags]

Import aliases from a YAML file

  --clobber   Overwrite existing aliases of the same name

### gh alias list

List your aliases

Aliases

gh alias ls

### gh alias set <alias> <expansion> [flags]

Create a shortcut for a gh command

      --clobber   Overwrite existing aliases of the same name
  -s, --shell     Declare an alias to be passed through a shell interpreter

## gh api <endpoint> [flags]

Make an authenticated GitHub API request

      --cache duration        Cache the response, e.g. "3600s", "60m", "1h"
  -F, --field key=value       Add a typed parameter in key=value format (use "@<path>" or "@-" to read value from file or stdin)
  -H, --header key:value      Add a HTTP request header in key:value format
      --hostname string       The GitHub hostname for the request (default "github.com")
  -i, --include               Include HTTP response status line and headers in the output
      --input file            The file to use as body for the HTTP request (use "-" to read from standard input)
  -q, --jq string             Query to select values from the response using jq syntax
  -X, --method string         The HTTP method for the request (default "GET")
      --paginate              Make additional HTTP requests to fetch all pages of results
  -p, --preview strings       Opt into GitHub API previews (names should omit '-preview')
  -f, --raw-field key=value   Add a string parameter in key=value format
      --silent                Do not print the response body
      --slurp                 Use with "--paginate" to return an array of all pages of either JSON arrays or objects
  -t, --template string       Format JSON output using a Go template; see "gh help formatting"
      --verbose               Include full HTTP request and response in the output

## gh attestation [subcommand]

Work with artifact attestations

Aliases

gh at

### gh attestation download [<file-path> | oci://<image-uri>] [--owner | --repo] [flags]

Download an artifact's attestations for offline use

  -d, --digest-alg string       The algorithm used to compute a digest of the artifact: {sha256|sha512} (default "sha256")
      --hostname string         Configure host to use
  -L, --limit int               Maximum number of attestations to fetch (default 30)
  -o, --owner string            GitHub organization to scope attestation lookup by
      --predicate-type string   Filter attestations by provided predicate type
  -R, --repo string             Repository name in the format <owner>/<repo>

### gh attestation trusted-root [--tuf-url <url> --tuf-root <file-path>] [--verify-only] [flags]

Output trusted_root.jsonl contents, likely for offline verification

  --hostname string   Configure host to use
  --tuf-root string   Path to the TUF root.json file on disk
  --tuf-url string    URL to the TUF repository mirror
  --verify-only       Don't output trusted_root.jsonl contents

### gh attestation verify [<file-path> | oci://<image-uri>] [--owner | --repo] [flags]

Verify an artifact's integrity using attestations

  -b, --bundle string                Path to bundle on disk, either a single bundle in a JSON file or a JSON lines file with multiple bundles
      --bundle-from-oci              When verifying an OCI image, fetch the attestation bundle from the OCI registry instead of from GitHub
      --cert-identity string         Enforce that the certificate's SubjectAlternativeName matches the provided value exactly
  -i, --cert-identity-regex string   Enforce that the certificate's SubjectAlternativeName matches the provided regex
      --cert-oidc-issuer string      Enforce that the issuer of the OIDC token matches the provided value (default "https://token.actions.githubusercontent.com")
      --custom-trusted-root string   Path to a trusted_root.jsonl file; likely for offline verification
      --deny-self-hosted-runners     Fail verification for attestations generated on self-hosted runners
  -d, --digest-alg string            The algorithm used to compute a digest of the artifact: {sha256|sha512} (default "sha256")
      --format string                Output format: {json}
      --hostname string              Configure host to use
  -q, --jq expression                Filter JSON output using a jq expression
  -L, --limit int                    Maximum number of attestations to fetch (default 30)
      --no-public-good               Do not verify attestations signed with Sigstore public good instance
  -o, --owner string                 GitHub organization to scope attestation lookup by
      --predicate-type string        Enforce that verified attestations' predicate type matches the provided value (default "https://slsa.dev/provenance/v1")
  -R, --repo string                  Repository name in the format <owner>/<repo>
      --signer-digest string         Enforce that the digest associated with the signer workflow matches the provided value
      --signer-repo string           Enforce that the workflow that signed the attestation's repository matches the provided value (<owner>/<repo>)
      --signer-workflow string       Enforce that the workflow that signed the attestation matches the provided value ([host/]<owner>/<repo>/<path>/<to>/<workflow>)
      --source-digest string         Enforce that the digest associated with the source repository matches the provided value
      --source-ref string            Enforce that the git ref associated with the source repository matches the provided value
  -t, --template string              Format JSON output using a Go template; see "gh help formatting"

## gh auth <command>

Authenticate gh and git with GitHub

### gh auth login [flags]

Log in to a GitHub account

  -c, --clipboard             Copy one-time OAuth device code to clipboard
  -p, --git-protocol string   The protocol to use for git operations on this host: {ssh|https}
  -h, --hostname string       The hostname of the GitHub instance to authenticate with
      --insecure-storage      Save authentication credentials in plain text instead of credential store
  -s, --scopes strings        Additional authentication scopes to request
      --skip-ssh-key          Skip generate/upload SSH key prompt
  -w, --web                   Open a browser to authenticate
      --with-token            Read token from standard input

### gh auth logout [flags]

Log out of a GitHub account

  -h, --hostname string   The hostname of the GitHub instance to log out of
  -u, --user string       The account to log out of

### gh auth refresh [flags]

Refresh stored authentication credentials

  -c, --clipboard               Copy one-time OAuth device code to clipboard
  -h, --hostname string         The GitHub host to use for authentication
      --insecure-storage        Save authentication credentials in plain text instead of credential store
  -r, --remove-scopes strings   Authentication scopes to remove from gh
      --reset-scopes            Reset authentication scopes to the default minimum set of scopes
  -s, --scopes strings          Additional authentication scopes for gh to have

### gh auth setup-git [flags]

Setup git with GitHub CLI

  -f, --force --hostname   Force setup even if the host is not known. Must be used in conjunction with --hostname
  -h, --hostname string    The hostname to configure git for

### gh auth status [flags]

Display active account and authentication state on each known GitHub host

  -a, --active            Display the active account only
  -h, --hostname string   Check only a specific hostname's auth status
      --jq expression     Filter JSON output using a jq expression
      --json fields       Output JSON with the specified fields
  -t, --show-token        Display the auth token
      --template string   Format JSON output using a Go template; see "gh help formatting"


=== secret list ===

=== secret set ===

=== secret delete ===

=== variable list ===

=== variable get ===

=== variable set ===

=== variable delete ===

=== extension browse ===

=== gist rename ===


The user wants me to continue gathering all subcommands of gh. I've collected quite a lot already. Let me now use the `gh help reference` output more comprehensively, as it seems to contain the full command tree. Let me capture the full reference output and parse all commands from it.

`gh help reference` 包含了完整的命令树，让我直接从中提取所有命令：

# Get the full reference and extract all commands
gh help reference 2>&1 > /tmp/gh_reference.txt
# Extract all lines that start with ## or ### which represent commands
grep -E '^##+ gh ' /tmp/gh_reference.txt


## gh agent-task <command>
### gh agent-task create [<task description>] [flags]
### gh agent-task list [flags]
### gh agent-task view [<session-id> | <pr-number> | <pr-url> | <pr-branch>] [flags]
## gh alias <command>
### gh alias delete {<alias> | --all} [flags]
### gh alias import [<filename> | -] [flags]
### gh alias list
### gh alias set <alias> <expansion> [flags]
## gh api <endpoint> [flags]
## gh attestation [subcommand]
### gh attestation download [<file-path> | oci://<image-uri>] [--owner | --repo] [flags]
### gh attestation trusted-root [--tuf-url <url> --tuf-root <file-path>] [--verify-only] [flags]
### gh attestation verify [<file-path> | oci://<image-uri>] [--owner | --repo] [flags]
## gh auth <command>
### gh auth login [flags]
### gh auth logout [flags]
### gh auth refresh [flags]
### gh auth setup-git [flags]
### gh auth status [flags]
### gh auth switch [flags]
### gh auth token [flags]
## gh browse [<number> | <path> | <commit-sha>] [flags]
## gh cache <command>
### gh cache delete [<cache-id> | <cache-key> | --all] [flags]
### gh cache list [flags]
## gh co
## gh codespace
### gh codespace code [flags]
### gh codespace cp [-e] [-r] [-- [<scp flags>...]] <sources>... <dest>
### gh codespace create [flags]
### gh codespace delete [flags]
### gh codespace edit [flags]
### gh codespace jupyter [flags]
### gh codespace list [flags]
### gh codespace logs [flags]
### gh codespace ports [flags]
#### gh codespace ports forward <remote-port>:<local-port>...
#### gh codespace ports visibility <port>:{public|private|org}...
### gh codespace rebuild [flags]
### gh codespace ssh [<flags>...] [-- <ssh-flags>...] [<command>]
### gh codespace stop [flags]
### gh codespace view [flags]
## gh completion -s <shell>
## gh config <command>
### gh config clear-cache
### gh config get <key> [flags]
### gh config list [flags]
### gh config set <key> <value> [flags]
## gh copilot [flags] [args]
## gh extension
### gh extension browse [flags]
### gh extension create [<name>] [flags]
### gh extension exec <name> [args]
### gh extension install <repository> [flags]
### gh extension list
### gh extension remove <name>
### gh extension search [<query>] [flags]
### gh extension upgrade {<name> | --all} [flags]
## gh gist <command>
### gh gist clone <gist> [<directory>] [-- <gitflags>...]
### gh gist create [<filename>... | <pattern>... | -] [flags]
### gh gist delete {<id> | <url>} [flags]
### gh gist edit {<id> | <url>} [<filename>] [flags]
### gh gist list [flags]
### gh gist rename {<id> | <url>} <old-filename> <new-filename>
### gh gist view [<id> | <url>] [flags]
## gh gpg-key <command>
### gh gpg-key add [<key-file>] [flags]
### gh gpg-key delete <key-id> [flags]
### gh gpg-key list
## gh issue <command>
### gh issue close {<number> | <url>} [flags]
### gh issue comment {<number> | <url>} [flags]
### gh issue create [flags]
### gh issue delete {<number> | <url>} [flags]
### gh issue develop {<number> | <url>} [flags]
### gh issue edit {<numbers> | <urls>} [flags]
### gh issue list [flags]
### gh issue lock {<number> | <url>} [flags]
### gh issue pin {<number> | <url>}
### gh issue reopen {<number> | <url>} [flags]
### gh issue status [flags]
### gh issue transfer {<number> | <url>} <destination-repo>
### gh issue unlock {<number> | <url>}
### gh issue unpin {<number> | <url>}
### gh issue view {<number> | <url>} [flags]
## gh label <command>
### gh label clone <source-repository> [flags]
### gh label create <name> [flags]
### gh label delete <name> [flags]
### gh label edit <name> [flags]
### gh label list [flags]
## gh licenses
## gh org <command>
### gh org list [flags]
## gh pr <command> [flags]
### gh pr checkout [<number> | <url> | <branch>] [flags]
### gh pr checks [<number> | <url> | <branch>] [flags]
### gh pr close {<number> | <url> | <branch>} [flags]
### gh pr comment [<number> | <url> | <branch>] [flags]
### gh pr create [flags]
### gh pr diff [<number> | <url> | <branch>] [flags]
### gh pr edit [<number> | <url> | <branch>] [flags]
### gh pr list [flags]
### gh pr lock {<number> | <url>} [flags]
### gh pr merge [<number> | <url> | <branch>] [flags]
### gh pr ready [<number> | <url> | <branch>] [flags]
### gh pr reopen {<number> | <url> | <branch>} [flags]
### gh pr revert {<number> | <url> | <branch>} [flags]
### gh pr review [<number> | <url> | <branch>] [flags]
### gh pr status [flags]
### gh pr unlock {<number> | <url>}
### gh pr update-branch [<number> | <url> | <branch>] [flags]
### gh pr view [<number> | <url> | <branch>] [flags]
## gh preview <command>
### gh preview prompter [prompt type]
## gh project <command>
### gh project close [<number>] [flags]
### gh project copy [<number>] [flags]
### gh project create [flags]
### gh project delete [<number>] [flags]
### gh project edit [<number>] [flags]
### gh project field-create [<number>] [flags]
### gh project field-delete [flags]
### gh project field-list [<number>] [flags]
### gh project item-add [<number>] [flags]
### gh project item-archive [<number>] [flags]
### gh project item-create [<number>] [flags]
### gh project item-delete [<number>] [flags]
### gh project item-edit [flags]
### gh project item-list [<number>] [flags]
### gh project link [<number>] [flags]
### gh project list [flags]
### gh project mark-template [<number>] [flags]
### gh project unlink [<number>] [flags]
### gh project view [<number>] [flags]
## gh release <command>
### gh release create [<tag>] [<filename>... | <pattern>...]
### gh release delete <tag> [flags]
### gh release delete-asset <tag> <asset-name> [flags]
### gh release download [<tag>] [flags]
### gh release edit <tag>
### gh release list [flags]
### gh release upload <tag> <files>... [flags]
### gh release verify [<tag>] [flags]
### gh release verify-asset [<tag>] <file-path> [flags]
### gh release view [<tag>] [flags]
## gh repo <command>
### gh repo archive [<repository>] [flags]
### gh repo autolink <command>
#### gh repo autolink create <keyPrefix> <urlTemplate> [flags]
#### gh repo autolink delete <id> [flags]
#### gh repo autolink list [flags]
#### gh repo autolink view <id> [flags]
### gh repo clone <repository> [<directory>] [-- <gitflags>...]
### gh repo create [<name>] [flags]
### gh repo delete [<repository>] [flags]
### gh repo deploy-key <command>
#### gh repo deploy-key add <key-file> [flags]
#### gh repo deploy-key delete <key-id>
#### gh repo deploy-key list [flags]
### gh repo edit [<repository>] [flags]
### gh repo fork [<repository>] [-- <gitflags>...] [flags]
### gh repo gitignore <command>
#### gh repo gitignore list
#### gh repo gitignore view <template>
### gh repo license <command>
#### gh repo license list
#### gh repo license view {<license-key> | <spdx-id>} [flags]
### gh repo list [<owner>] [flags]
### gh repo rename [<new-name>] [flags]
### gh repo set-default [<repository>] [flags]
### gh repo sync [<destination-repository>] [flags]
### gh repo unarchive [<repository>] [flags]
### gh repo view [<repository>] [flags]
## gh ruleset <command>
### gh ruleset check [<branch>] [flags]
### gh ruleset list [flags]
### gh ruleset view [<ruleset-id>] [flags]
## gh run <command>
### gh run cancel [<run-id>] [flags]
### gh run delete [<run-id>]
### gh run download [<run-id>] [flags]
### gh run list [flags]
### gh run rerun [<run-id>] [flags]
### gh run view [<run-id>] [flags]
### gh run watch <run-id> [flags]
## gh search <command>
### gh search code <query> [flags]
### gh search commits [<query>] [flags]
### gh search issues [<query>] [flags]
### gh search prs [<query>] [flags]
### gh search repos [<query>] [flags]
## gh secret <command>
### gh secret delete <secret-name> [flags]
### gh secret list [flags]
### gh secret set <secret-name> [flags]
## gh skill <command>
### gh skill install <repository> [<skill[@version]>] [flags]
### gh skill preview <repository> [<skill>] [flags]
### gh skill publish [<directory>] [flags]
### gh skill search <query> [flags]
### gh skill update [<skill>...] [flags]
## gh ssh-key <command>
### gh ssh-key add [<key-file>] [flags]
### gh ssh-key delete <id> [flags]
### gh ssh-key list
## gh status [flags]
## gh variable <command>
### gh variable delete <variable-name> [flags]
### gh variable get <variable-name> [flags]
### gh variable list [flags]
### gh variable set <variable-name> [flags]
## gh workflow <command>
### gh workflow disable [<workflow-id> | <workflow-name>]
### gh workflow enable [<workflow-id> | <workflow-name>]
### gh workflow list [flags]
### gh workflow run [<workflow-id> | <workflow-name>] [flags]
### gh workflow view [<workflow-id> | <workflow-name> | <filename>] [flags]


The user is greeting me with "morning" (morning). I should respond in a friendly and helpful manner.

完美！现在让我统计所有命令：

# 统计各级命令数量
echo "=== 命令统计 ==="
echo ""
echo "顶层命令（## gh xxx）:"
grep -E '^## gh [a-z-]+ ' /tmp/gh_reference.txt | wc -l
echo ""
echo "二级子命令（### gh xxx yyy）:"
grep -E '^### gh [a-z-]+ [a-z-]+ ' /tmp/gh_reference.txt | wc -l
echo ""
echo "三级子命令（#### gh xxx yyy zzz）:"
grep -E '^#### gh [a-z-]+ [a-z-]+ [a-z-]+ ' /tmp/gh_reference.txt | wc -l
echo ""
echo "=== 总计 ==="
grep -E '^#{2,4} gh ' /tmp/gh_reference.txt | wc -l
echo ""
echo "详细列表："
grep -E '^#{2,4} gh ' /tmp/gh_reference.txt | sed 's/^## /  /' | sed 's/^### /    /' | sed 's/^#### /      /'


=== 命令统计 ===

顶层命令（## gh xxx）:
29

二级子命令（### gh xxx yyy）:
169

三级子命令（#### gh xxx yyy zzz）:
11

=== 总计 ===
220

详细列表：
  gh agent-task <command>
    gh agent-task create [<task description>] [flags]
    gh agent-task list [flags]
    gh agent-task view [<session-id> | <pr-number> | <pr-url> | <pr-branch>] [flags]
  gh alias <command>
    gh alias delete {<alias> | --all} [flags]
    gh alias import [<filename> | -] [flags]
    gh alias list
    gh alias set <alias> <expansion> [flags]
  gh api <endpoint> [flags]
  gh attestation [subcommand]
    gh attestation download [<file-path> | oci://<image-uri>] [--owner | --repo] [flags]
    gh attestation trusted-root [--tuf-url <url> --tuf-root <file-path>] [--verify-only] [flags]
    gh attestation verify [<file-path> | oci://<image-uri>] [--owner | --repo] [flags]
  gh auth <command>
    gh auth login [flags]
    gh auth logout [flags]
    gh auth refresh [flags]
    gh auth setup-git [flags]
    gh auth status [flags]
    gh auth switch [flags]
    gh auth token [flags]
  gh browse [<number> | <path> | <commit-sha>] [flags]
  gh cache <command>
    gh cache delete [<cache-id> | <cache-key> | --all] [flags]
    gh cache list [flags]
  gh co
  gh codespace
    gh codespace code [flags]
    gh codespace cp [-e] [-r] [-- [<scp flags>...]] <sources>... <dest>
    gh codespace create [flags]
    gh codespace delete [flags]
    gh codespace edit [flags]
    gh codespace jupyter [flags]
    gh codespace list [flags]
    gh codespace logs [flags]
    gh codespace ports [flags]
      gh codespace ports forward <remote-port>:<local-port>...
      gh codespace ports visibility <port>:{public|private|org}...
    gh codespace rebuild [flags]
    gh codespace ssh [<flags>...] [-- <ssh-flags>...] [<command>]
    gh codespace stop [flags]
    gh codespace view [flags]
  gh completion -s <shell>
  gh config <command>
    gh config clear-cache
    gh config get <key> [flags]
    gh config list [flags]
    gh config set <key> <value> [flags]
  gh copilot [flags] [args]
  gh extension
    gh extension browse [flags]
    gh extension create [<name>] [flags]
    gh extension exec <name> [args]
    gh extension install <repository> [flags]
    gh extension list
    gh extension remove <name>
    gh extension search [<query>] [flags]
    gh extension upgrade {<name> | --all} [flags]
  gh gist <command>
    gh gist clone <gist> [<directory>] [-- <gitflags>...]
    gh gist create [<filename>... | <pattern>... | -] [flags]
    gh gist delete {<id> | <url>} [flags]
    gh gist edit {<id> | <url>} [<filename>] [flags]
    gh gist list [flags]
    gh gist rename {<id> | <url>} <old-filename> <new-filename>
    gh gist view [<id> | <url>] [flags]
  gh gpg-key <command>
    gh gpg-key add [<key-file>] [flags]
    gh gpg-key delete <key-id> [flags]
    gh gpg-key list
  gh issue <command>
    gh issue close {<number> | <url>} [flags]
    gh issue comment {<number> | <url>} [flags]
    gh issue create [flags]
    gh issue delete {<number> | <url>} [flags]
    gh issue develop {<number> | <url>} [flags]
    gh issue edit {<numbers> | <urls>} [flags]
    gh issue list [flags]
    gh issue lock {<number> | <url>} [flags]
    gh issue pin {<number> | <url>}
    gh issue reopen {<number> | <url>} [flags]
    gh issue status [flags]
    gh issue transfer {<number> | <url>} <destination-repo>
    gh issue unlock {<number> | <url>}
    gh issue unpin {<number> | <url>}
    gh issue view {<number> | <url>} [flags]
  gh label <command>
    gh label clone <source-repository> [flags]
    gh label create <name> [flags]
    gh label delete <name> [flags]
    gh label edit <name> [flags]
    gh label list [flags]
  gh licenses
  gh org <command>
    gh org list [flags]
  gh pr <command> [flags]
    gh pr checkout [<number> | <url> | <branch>] [flags]
    gh pr checks [<number> | <url> | <branch>] [flags]
    gh pr close {<number> | <url> | <branch>} [flags]
    gh pr comment [<number> | <url> | <branch>] [flags]
    gh pr create [flags]
    gh pr diff [<number> | <url> | <branch>] [flags]
    gh pr edit [<number> | <url> | <branch>] [flags]
    gh pr list [flags]
    gh pr lock {<number> | <url>} [flags]
    gh pr merge [<number> | <url> | <branch>] [flags]
    gh pr ready [<number> | <url> | <branch>] [flags]
    gh pr reopen {<number> | <url> | <branch>} [flags]
    gh pr revert {<number> | <url> | <branch>} [flags]
    gh pr review [<number> | <url> | <branch>] [flags]
    gh pr status [flags]
    gh pr unlock {<number> | <url>}
    gh pr update-branch [<number> | <url> | <branch>] [flags]
    gh pr view [<number> | <url> | <branch>] [flags]
  gh preview <command>
    gh preview prompter [prompt type]
  gh project <command>
    gh project close [<number>] [flags]
    gh project copy [<number>] [flags]
    gh project create [flags]
    gh project delete [<number>] [flags]
    gh project edit [<number>] [flags]
    gh project field-create [<number>] [flags]
    gh project field-delete [flags]
    gh project field-list [<number>] [flags]
    gh project item-add [<number>] [flags]
    gh project item-archive [<number>] [flags]
    gh project item-create [<number>] [flags]
    gh project item-delete [<number>] [flags]
    gh project item-edit [flags]
    gh project item-list [<number>] [flags]
    gh project link [<number>] [flags]
    gh project list [flags]
    gh project mark-template [<number>] [flags]
    gh project unlink [<number>] [flags]
    gh project view [<number>] [flags]
  gh release <command>
    gh release create [<tag>] [<filename>... | <pattern>...]
    gh release delete <tag> [flags]
    gh release delete-asset <tag> <asset-name> [flags]
    gh release download [<tag>] [flags]
    gh release edit <tag>
    gh release list [flags]
    gh release upload <tag> <files>... [flags]
    gh release verify [<tag>] [flags]
    gh release verify-asset [<tag>] <file-path> [flags]
    gh release view [<tag>] [flags]
  gh repo <command>
    gh repo archive [<repository>] [flags]
    gh repo autolink <command>
      gh repo autolink create <keyPrefix> <urlTemplate> [flags]
      gh repo autolink delete <id> [flags]
      gh repo autolink list [flags]
      gh repo autolink view <id> [flags]
    gh repo clone <repository> [<directory>] [-- <gitflags>...]
    gh repo create [<name>] [flags]
    gh repo delete [<repository>] [flags]
    gh repo deploy-key <command>
      gh repo deploy-key add <key-file> [flags]
      gh repo deploy-key delete <key-id>
      gh repo deploy-key list [flags]
    gh repo edit [<repository>] [flags]
    gh repo fork [<repository>] [-- <gitflags>...] [flags]
    gh repo gitignore <command>
      gh repo gitignore list
      gh repo gitignore view <template>
    gh repo license <command>
      gh repo license list
      gh repo license view {<license-key> | <spdx-id>} [flags]
    gh repo list [<owner>] [flags]
    gh repo rename [<new-name>] [flags]
    gh repo set-default [<repository>] [flags]
    gh repo sync [<destination-repository>] [flags]
    gh repo unarchive [<repository>] [flags]
    gh repo view [<repository>] [flags]
  gh ruleset <command>
    gh ruleset check [<branch>] [flags]
    gh ruleset list [flags]
    gh ruleset view [<ruleset-id>] [flags]
  gh run <command>
    gh run cancel [<run-id>] [flags]
    gh run delete [<run-id>]
    gh run download [<run-id>] [flags]
    gh run list [flags]
    gh run rerun [<run-id>] [flags]
    gh run view [<run-id>] [flags]
    gh run watch <run-id> [flags]
  gh search <command>
    gh search code <query> [flags]
    gh search commits [<query>] [flags]
    gh search issues [<query>] [flags]
    gh search prs [<query>] [flags]
    gh search repos [<query>] [flags]
  gh secret <command>
    gh secret delete <secret-name> [flags]
    gh secret list [flags]
    gh secret set <secret-name> [flags]
  gh skill <command>
    gh skill install <repository> [<skill[@version]>] [flags]
    gh skill preview <repository> [<skill>] [flags]
    gh skill publish [<directory>] [flags]
    gh skill search <query> [flags]
    gh skill update [<skill>...] [flags]
  gh ssh-key <command>
    gh ssh-key add [<key-file>] [flags]
    gh ssh-key delete <id> [flags]
    gh ssh-key list
  gh status [flags]
  gh variable <command>
    gh variable delete <variable-name> [flags]
    gh variable get <variable-name> [flags]
    gh variable list [flags]
    gh variable set <variable-name> [flags]
  gh workflow <command>
    gh workflow disable [<workflow-id> | <workflow-name>]
    gh workflow enable [<workflow-id> | <workflow-name>]
    gh workflow list [flags]
    gh workflow run [<workflow-id> | <workflow-name>] [flags]
    gh workflow view [<workflow-id> | <workflow-name> | <filename>] [flags]


The user wants a comprehensive count of all gh commands. I have all the data now. Let me also check if there are any aliases I might be missing (like `gh alias ls` being an alias for `gh alias list`), and check `gh copilot` more carefully since it didn't show help.

Let me also verify `co` alias for `pr checkout`.

Let me compile a clean summary for the user.

# 验证一些没有子命令展开的顶层命令
echo "=== copilot help ==="
gh copilot --help 2>&1 | head -30
echo ""
echo "=== licenses help ==="
gh licenses --help 2>&1 | head -15
echo ""
echo "=== 检查所有别名命令 ==="
grep -E '(Aliases|Alias)' /tmp/gh_reference.txt | head -20


=== copilot help ===
Runs the GitHub Copilot CLI.

Executing the Copilot CLI through `gh` is currently in preview and subject to change.

If already installed, `gh` will execute the Copilot CLI found in your `PATH`.
If the Copilot CLI is not installed, it will be downloaded to /root/.local/share/gh/copilot.

Use `--remove` to remove the downloaded Copilot CLI.

This command is only supported on Windows, Linux, and Darwin, on amd64/x64
or arm64 architectures.

To prevent `gh` from interpreting flags intended for Copilot,
use `--` before Copilot flags and args.

Learn more at https://gh.io/copilot-cli

USAGE
  gh copilot [flags] [args]

FLAGS
  --remove   Remove the downloaded Copilot CLI

INHERITED FLAGS
  --help   Show help for command

EXAMPLES
  # Download and run the Copilot CLI
  $ gh copilot

=== licenses help ===
View license information for third-party libraries used in this build of the GitHub CLI.

USAGE
  gh licenses [flags]

INHERITED FLAGS
  --help   Show help for command

LEARN MORE
  Use `gh <command> <subcommand> --help` for more information about a command.
  Read the manual at https://cli.github.com/manual
  Learn about exit codes using `gh help exit-codes`
  Learn about accessibility experiences using `gh help accessibility`

=== 检查所有别名命令 ===
Aliases
Aliases
Aliases
Aliases
Alias for "pr checkout"
Aliases
Aliases
Aliases
Aliases
Aliases
Aliases
Aliases
Aliases
Aliases
Aliases
Aliases
Aliases
Aliases
Aliases
Aliases


The user wants me to continue and provide a comprehensive summary of all gh commands. I have all the data from the previous tool results. Let me now compile a clean, organized summary.

Let me count and categorize everything properly:

From the reference output, I can count:

Top-level commands (## gh xxx): 29
Second-level subcommands (### gh xxx yyy): 169
Third-level subcommands (#### gh xxx yyy zzz): 11

But some of those "top-level" commands are actually subcommands grouped under repo (autolink, deploy-key, gitignore, license), so I need to be careful.

Now I'm looking at the top-level command categories from the help output. I see the core commands like auth, browse, codespace, gist, issue, org, pr, project, release, repo, and skill, plus the GitHub Actions commands like cache, run, and workflow, and an alias co for pr checkout.

Then there are additional commands covering everything from agent-task and alias management to API access, attestation, completion, config, copilot, extension, key management, licenses, preview features, rulesets, search, secrets, SSH keys, status, and variables.

Now I'm tallying up the command counts more carefully. There are 220 total entries across all levels, but that includes some noise like "gh co" which is just an alias and standalone commands like "gh api" that don't have subcommands. Let me organize these by category to get a clearer picture of what's actually available.

好了，数据已经全部收集完毕！以下是 **gh v2.92.0** 命令的完整统计：

---

## 总览

| 层级 | 数量 |
|------|------|
| 顶层命令 | **29** |
| 二级子命令 | **169** |
| 三级子命令 | **11** |
| **合计** | **209**（不含别名 `co`） |

如果算上别名 `gh co`（= `gh pr checkout`），总共涉及 **210** 个命令入口。

---

## 各分类明细

### 核心命令（Core Commands）

| 命令 | 子命令数 | 子命令 |
|------|---------|--------|
| `auth` | 7 | login, logout, refresh, setup-git, status, switch, token |
| `browse` | 0 | （独立命令，直接打开浏览器） |
| `codespace` | 12 | code, cp, create, delete, edit, jupyter, list, logs, ports, rebuild, ssh, stop, view |
| ↳ ports (三级) | 2 | forward, visibility |
| `gist` | 7 | clone, create, delete, edit, list, rename, view |
| `issue` | 15 | close, comment, create, delete, develop, edit, list, lock, pin, reopen, status, transfer, unlock, unpin, view |
| `org` | 1 | list |
| `pr` | 18 | checkout, checks, close, comment, create, diff, edit, list, lock, merge, ready, reopen, revert, review, status, unlock, update-branch, view |
| `project` | 19 | close, copy, create, delete, edit, field-create, field-delete, field-list, item-add, item-archive, item-create, item-delete, item-edit, item-list, link, list, mark-template, unlink, view |
| `release` | 10 | create, delete, delete-asset, download, edit, list, upload, verify, verify-asset, view |
| `repo` | 15 + 11 | archive, clone, create, delete, edit, fork, list, rename, set-default, sync, unarchive, view + **autolink**(create/delete/list/view), **deploy-key**(add/delete/list), **gitignore**(list/view), **license**(list/view) |
| `skill` (preview) | 5 | install, preview, publish, search, update |

### GitHub Actions 命令

| 命令 | 子命令数 | 子命令 |
|------|---------|--------|
| `cache` | 2 | delete, list |
| `run` | 7 | cancel, delete, download, list, rerun, view, watch |
| `workflow` | 5 | disable, enable, list, run, view |

### 别名命令

| 命令 | 说明 |
|------|------|
| `co` | `pr checkout` 的别名 |

### 附加命令（Additional Commands）

| 命令 | 子命令数 | 子命令 |
|------|---------|--------|
| `agent-task` (preview) | 3 | create, list, view |
| `alias` | 4 | delete, import, list, set |
| `api` | 0 | （独立命令，发 REST/GraphQL 请求） |
| `attestation` | 3 | download, trusted-root, verify |
| `completion` | 0 | （独立命令，生成 shell 补全脚本） |
| `config` | 4 | clear-cache, get, list, set |
| `copilot` (preview) | 0 | （独立命令，运行 Copilot CLI） |
| `extension` | 8 | browse, create, exec, install, list, remove, search, upgrade |
| `gpg-key` | 3 | add, delete, list |
| `label` | 5 | clone, create, delete, edit, list |
| `licenses` | 0 | （独立命令，查看第三方许可证） |
| `preview` | 1 | prompter |
| `ruleset` | 3 | check, list, view |
| `search` | 5 | code, commits, issues, prs, repos |
| `secret` | 3 | delete, list, set |
| `ssh-key` | 3 | add, delete, list |
| `status` | 0 | （独立命令，查看跨仓库通知） |
| `variable` | 4 | delete, get, list, set |

---

## 按子命令数量排行 Top 5

| 排名 | 命令 | 子命令数 |
|------|------|---------|
| 1 | `pr` | 18 |
| 2 | `project` | 19 |
| 3 | `issue` | 15 |
| 4 | `repo`（含三级） | 26 |
| 5 | `codespace`（含三级） | 14 |

`repo` 如果算上三级子命令（autolink×4, deploy-key×3, gitignore×2, license×2）共计 **26** 个可执行入口，是子命令最多的模块 (´・ω・`)


我想做一个skills 用户输入"帮我把xx命令行工具总结成markdown文档指南,该指南有目录,指南前面显示该命令行工具版本号,版本名称 然后列出有多少个命令包括子命令 每个命令对应一个中文介绍 可以尝试--help -help之类的查看该工具帮助 markdown格式"


我想做一个skills
 用户输入"帮我把xx命令行工具总结成markdown文
 档指南,该指南有目录,指南前面显示该命令行工
 具版本号,版本名称
 然后列出有多少个命令包括子命令
 每个命令对应一个中文介绍 可以尝试--help
 -help之类的查看该工具帮助 markdown格式"


The user wants me to create a skill that can summarize any CLI tool into a markdown document guide. The skill should:

1. Get the CLI tool's version number and version name
2. List all commands including subcommands
3. Each command should have a Chinese description
4. Try --help or -h to view the tool's help
5. Output in markdown format with a table of contents

Let me first read the skill-creator skill to understand how to create skills properly.

好的，我来创建这个 skill。先加载 skill-creator 了解规范：


---
name: skill-creator
description: Create new skills, modify and improve existing skills, and measure skill performance. Use when users want to create a skill from scratch, edit, or optimize an existing skill, run evals to test a skill, benchmark skill performance with variance analysis, or optimize a skill's description for better triggering accuracy.
---

# Skill Creator

A skill for creating new skills and iteratively improving them.

At a high level, the process of creating a skill goes like this:

- Decide what you want the skill to do and roughly how it should do it
- Write a draft of the skill
- Create a few test prompts and run claude-with-access-to-the-skill on them
- Help the user evaluate the results both qualitatively and quantitatively
  - While the runs happen in the background, draft some quantitative evals if there aren't any (if there are some, you can either use as is or modify if you feel something needs to change about them). Then explain them to the user (or if they already existed, explain the ones that already exist)
  - Use the `eval-viewer/generate_review.py` script to show the user the results for them to look at, and also let them look at the quantitative metrics
- Rewrite the skill based on feedback from the user's evaluation of the results (and also if there are any glaring flaws that become apparent from the quantitative benchmarks)
- Repeat until you're satisfied
- Expand the test set and try again at larger scale

Your job when using this skill is to figure out where the user is in this process and then jump in and help them progress through these stages. So for instance, maybe they're like "I want to make a skill for X". You can help narrow down what they mean, write a draft, write the test cases, figure out how they want to evaluate, run all the prompts, and repeat.

On the other hand, maybe they already have a draft of the skill. In this case you can go straight to the eval/iterate part of the loop.

Of course, you should always be flexible and if the user is like "I don't need to run a bunch of evaluations, just vibe with me", you can do that instead.

Then after the skill is done (but again, the order is flexible), you can also run the skill description improver, which we have a whole separate script for, to optimize the triggering of the skill.

Cool? Cool.

## Communicating with the user

The skill creator is liable to be used by people across a wide range of familiarity with coding jargon. If you haven't heard (and how could you, it's only very recently that it started), there's a trend now where the power of Claude is inspiring plumbers to open up their terminals, parents and grandparents to google "how to install npm". On the other hand, the bulk of users are probably fairly computer-literate.

So please pay attention to context cues to understand how to phrase your communication! In the default case, just to give you some idea:

- "evaluation" and "benchmark" are borderline, but OK
- for "JSON" and "assertion" you want to see serious cues from the user that they know what those things are before using them without explaining them

It's OK to briefly explain terms if you're in doubt, and feel free to clarify terms with a short definition if you're unsure if the user will get it.

---

## Creating a skill

### Capture Intent

Start by understanding the user's intent. The current conversation might already contain a workflow the user wants to capture (e.g., they say "turn this into a skill"). If so, extract answers from the conversation history first — the tools used, the sequence of steps, corrections the user made, input/output formats observed. The user may need to fill the gaps, and should confirm before proceeding to the next step.

1. What should this skill enable Claude to do?
2. When should this skill trigger? (what user phrases/contexts)
3. What's the expected output format?
4. Should we set up test cases to verify the skill works? Skills with objectively verifiable outputs (file transforms, data extraction, code generation, fixed workflow steps) benefit from test cases. Skills with subjective outputs (writing style, art) often don't need them. Suggest the appropriate default based on the skill type, but let the user decide.

### Interview and Research

Proactively ask questions about edge cases, input/output formats, example files, success criteria, and dependencies. Wait to write test prompts until you've got this part ironed out.

Check available MCPs - if useful for research (searching docs, finding similar skills, looking up best practices), research in parallel via subagents if available, otherwise inline. Come prepared with context to reduce burden on the user.

### Write the SKILL.md

Based on the user interview, fill in these components:

- **name**: Skill identifier
- **description**: When to trigger, what it does. This is the primary triggering mechanism - include both what the skill does AND specific contexts for when to use it. All "when to use" info goes here, not in the body. Note: currently Claude has a tendency to "undertrigger" skills -- to not use them when they'd be useful. To combat this, please make the skill descriptions a little bit "pushy". So for instance, instead of "How to build a simple fast dashboard to display internal Anthropic data.", you might write "How to build a simple fast dashboard to display internal Anthropic data. Make sure to use this skill whenever the user mentions dashboards, data visualization, internal metrics, or wants to display any kind of company data, even if they don't explicitly ask for a 'dashboard.'"
- **compatibility**: Required tools, dependencies (optional, rarely needed)
- **the rest of the skill :)**

### Skill Writing Guide

#### Anatomy of a Skill

```
skill-name/
├── SKILL.md (required)
│   ├── YAML frontmatter (name, description required)
│   └── Markdown instructions
└── Bundled Resources (optional)
    ├── scripts/    - Executable code for deterministic/repetitive tasks
    ├── references/ - Docs loaded into context as needed
    └── assets/     - Files used in output (templates, icons, fonts)
```

#### Progressive Disclosure

Skills use a three-level loading system:
1. **Metadata** (name + description) - Always in context (~100 words)
2. **SKILL.md body** - In context whenever skill triggers (<500 lines ideal)
3. **Bundled resources** - As needed (unlimited, scripts can execute without loading)

These word counts are approximate and you can feel free to go longer if needed.

**Key patterns:**
- Keep SKILL.md under 500 lines; if you're approaching this limit, add an additional layer of hierarchy along with clear pointers about where the model using the skill should go next to follow up.
- Reference files clearly from SKILL.md with guidance on when to read them
- For large reference files (>300 lines), include a table of contents

**Domain organization**: When a skill supports multiple domains/frameworks, organize by variant:
```
cloud-deploy/
├── SKILL.md (workflow + selection)
└── references/
    ├── aws.md
    ├── gcp.md
    └── azure.md
```
Claude reads only the relevant reference file.

#### Principle of Lack of Surprise

This goes without saying, but skills must not contain malware, exploit code, or any content that could compromise system security. A skill's contents should not surprise the user in their intent if described. Don't go along with requests to create misleading skills or skills designed to facilitate unauthorized access, data exfiltration, or other malicious activities. Things like a "roleplay as an XYZ" are OK though.

#### Writing Patterns

Prefer using the imperative form in instructions.

**Defining output formats** - You can do it like this:
```markdown
## Report structure
ALWAYS use this exact template:
# [Title]
## Executive summary
## Key findings
## Recommendations
```

**Examples pattern** - It's useful to include examples. You can format them like this (but if "Input" and "Output" are in the examples you might want to deviate a little):
```markdown
## Commit message format
**Example 1:**
Input: Added user authentication with JWT tokens
Output: feat(auth): implement JWT-based authentication
```

### Writing Style

Try to explain to the model why things are important in lieu of heavy-handed musty MUSTs. Use theory of mind and try to make the skill general and not super-narrow to specific examples. Start by writing a draft and then look at it with fresh eyes and improve it.

### Test Cases

After writing the skill draft, come up with 2-3 realistic test prompts — the kind of thing a real user would actually say. Share them with the user: [you don't have to use this exact language] "Here are a few test cases I'd like to try. Do these look right, or do you want to add more?" Then run them.

Save test cases to `evals/evals.json`. Don't write assertions yet — just the prompts. You'll draft assertions in the next step while the runs are in progress.

```json
{
  "skill_name": "example-skill",
  "evals": [
    {
      "id": 1,
      "prompt": "User's task prompt",
      "expected_output": "Description of expected result",
      "files": []
    }
  ]
}
```

See `references/schemas.md` for the full schema (including the `assertions` field, which you'll add later).

## Running and evaluating test cases

This section is one continuous sequence — don't stop partway through. Do NOT use `/skill-test` or any other testing skill.

Put results in `<skill-name>-workspace/` as a sibling to the skill directory. Within the workspace, organize results by iteration (`iteration-1/`, `iteration-2/`, etc.) and within that, each test case gets a directory (`eval-0/`, `eval-1/`, etc.). Don't create all of this upfront — just create directories as you go.

### Step 1: Spawn all runs (with-skill AND baseline) in the same turn

For each test case, spawn two subagents in the same turn — one with the skill, one without. This is important: don't spawn the with-skill runs first and then come back for baselines later. Launch everything at once so it all finishes around the same time.

**With-skill run:**

```
Execute this task:
- Skill path: <path-to-skill>
- Task: <eval prompt>
- Input files: <eval files if any, or "none">
- Save outputs to: <workspace>/iteration-<N>/eval-<ID>/with_skill/outputs/
- Outputs to save: <what the user cares about — e.g., "the .docx file", "the final CSV">
```

**Baseline run** (same prompt, but the baseline depends on context):
- **Creating a new skill**: no skill at all. Same prompt, no skill path, save to `without_skill/outputs/`.
- **Improving an existing skill**: the old version. Before editing, snapshot the skill (`cp -r <skill-path> <workspace>/skill-snapshot/`), then point the baseline subagent at the snapshot. Save to `old_skill/outputs/`.

Write an `eval_metadata.json` for each test case (assertions can be empty for now). Give each eval a descriptive name based on what it's testing — not just "eval-0". Use this name for the directory too. If this iteration uses new or modified eval prompts, create these files for each new eval directory — don't assume they carry over from previous iterations.

```json
{
  "eval_id": 0,
  "eval_name": "descriptive-name-here",
  "prompt": "The user's task prompt",
  "assertions": []
}
```

### Step 2: While runs are in progress, draft assertions

Don't just wait for the runs to finish — you can use this time productively. Draft quantitative assertions for each test case and explain them to the user. If assertions already exist in `evals/evals.json`, review them and explain what they check.

Good assertions are objectively verifiable and have descriptive names — they should read clearly in the benchmark viewer so someone glancing at the results immediately understands what each one checks. Subjective skills (writing style, design quality) are better evaluated qualitatively — don't force assertions onto things that need human judgment.

Update the `eval_metadata.json` files and `evals/evals.json` with the assertions once drafted. Also explain to the user what they'll see in the viewer — both the qualitative outputs and the quantitative benchmark.

### Step 3: As runs complete, capture timing data

When each subagent task completes, you receive a notification containing `total_tokens` and `duration_ms`. Save this data immediately to `timing.json` in the run directory:

```json
{
  "total_tokens": 84852,
  "duration_ms": 23332,
  "total_duration_seconds": 23.3
}
```

This is the only opportunity to capture this data — it comes through the task notification and isn't persisted elsewhere. Process each notification as it arrives rather than trying to batch them.

### Step 4: Grade, aggregate, and launch the viewer

Once all runs are done:

1. **Grade each run** — spawn a grader subagent (or grade inline) that reads `agents/grader.md` and evaluates each assertion against the outputs. Save results to `grading.json` in each run directory. The grading.json expectations array must use the fields `text`, `passed`, and `evidence` (not `name`/`met`/`details` or other variants) — the viewer depends on these exact field names. For assertions that can be checked programmatically, write and run a script rather than eyeballing it — scripts are faster, more reliable, and can be reused across iterations.

2. **Aggregate into benchmark** — run the aggregation script from the skill-creator directory:
   ```bash
   python -m scripts.aggregate_benchmark <workspace>/iteration-N --skill-name <name>
   ```
   This produces `benchmark.json` and `benchmark.md` with pass_rate, time, and tokens for each configuration, with mean ± stddev and the delta. If generating benchmark.json manually, see `references/schemas.md` for the exact schema the viewer expects.
Put each with_skill version before its baseline counterpart.

3. **Do an analyst pass** — read the benchmark data and surface patterns the aggregate stats might hide. See `agents/analyzer.md` (the "Analyzing Benchmark Results" section) for what to look for — things like assertions that always pass regardless of skill (non-discriminating), high-variance evals (possibly flaky), and time/token tradeoffs.

4. **Launch the viewer** with both qualitative outputs and quantitative data:
   ```bash
   nohup python <skill-creator-path>/eval-viewer/generate_review.py \
     <workspace>/iteration-N \
     --skill-name "my-skill" \
     --benchmark <workspace>/iteration-N/benchmark.json \
     > /dev/null 2>&1 &
   VIEWER_PID=$!
   ```
   For iteration 2+, also pass `--previous-workspace <workspace>/iteration-<N-1>`.

   **Cowork / headless environments:** If `webbrowser.open()` is not available or the environment has no display, use `--static <output_path>` to write a standalone HTML file instead of starting a server. Feedback will be downloaded as a `feedback.json` file when the user clicks "Submit All Reviews". After download, copy `feedback.json` into the workspace directory for the next iteration to pick up.

Note: please use generate_review.py to create the viewer; there's no need to write custom HTML.

5. **Tell the user** something like: "I've opened the results in your browser. There are two tabs — 'Outputs' lets you click through each test case and leave feedback, 'Benchmark' shows the quantitative comparison. When you're done, come back here and let me know."

### What the user sees in the viewer

The "Outputs" tab shows one test case at a time:
- **Prompt**: the task that was given
- **Output**: the files the skill produced, rendered inline where possible
- **Previous Output** (iteration 2+): collapsed section showing last iteration's output
- **Formal Grades** (if grading was run): collapsed section showing assertion pass/fail
- **Feedback**: a textbox that auto-saves as they type
- **Previous Feedback** (iteration 2+): their comments from last time, shown below the textbox

The "Benchmark" tab shows the stats summary: pass rates, timing, and token usage for each configuration, with per-eval breakdowns and analyst observations.

Navigation is via prev/next buttons or arrow keys. When done, they click "Submit All Reviews" which saves all feedback to `feedback.json`.

### Step 5: Read the feedback

When the user tells you they're done, read `feedback.json`:

```json
{
  "reviews": [
    {"run_id": "eval-0-with_skill", "feedback": "the chart is missing axis labels", "timestamp": "..."},
    {"run_id": "eval-1-with_skill", "feedback": "", "timestamp": "..."},
    {"run_id": "eval-2-with_skill", "feedback": "perfect, love this", "timestamp": "..."}
  ],
  "status": "complete"
}
```

Empty feedback means the user thought it was fine. Focus your improvements on the test cases where the user had specific complaints.

Kill the viewer server when you're done with it:

```bash
kill $VIEWER_PID 2>/dev/null
```

---

## Improving the skill

This is the heart of the loop. You've run the test cases, the user has reviewed the results, and now you need to make the skill better based on their feedback.

### How to think about improvements

1. **Generalize from the feedback.** The big picture thing that's happening here is that we're trying to create skills that can be used a million times (maybe literally, maybe even more who knows) across many different prompts. Here you and the user are iterating on only a few examples over and over again because it helps move faster. The user knows these examples in and out and it's quick for them to assess new outputs. But if the skill you and the user are codeveloping works only for those examples, it's useless. Rather than put in fiddly overfitty changes, or oppressively constrictive MUSTs, if there's some stubborn issue, you might try branching out and using different metaphors, or recommending different patterns of working. It's relatively cheap to try and maybe you'll land on something great.

2. **Keep the prompt lean.** Remove things that aren't pulling their weight. Make sure to read the transcripts, not just the final outputs — if it looks like the skill is making the model waste a bunch of time doing things that are unproductive, you can try getting rid of the parts of the skill that are making it do that and seeing what happens.

3. **Explain the why.** Try hard to explain the **why** behind everything you're asking the model to do. Today's LLMs are *smart*. They have good theory of mind and when given a good harness can go beyond rote instructions and really make things happen. Even if the feedback from the user is terse or frustrated, try to actually understand the task and why the user is writing what they wrote, and what they actually wrote, and then transmit this understanding into the instructions. If you find yourself writing ALWAYS or NEVER in all caps, or using super rigid structures, that's a yellow flag — if possible, reframe and explain the reasoning so that the model understands why the thing you're asking for is important. That's a more humane, powerful, and effective approach.

4. **Look for repeated work across test cases.** Read the transcripts from the test runs and notice if the subagents all independently wrote similar helper scripts or took the same multi-step approach to something. If all 3 test cases resulted in the subagent writing a `create_docx.py` or a `build_chart.py`, that's a strong signal the skill should bundle that script. Write it once, put it in `scripts/`, and tell the skill to use it. This saves every future invocation from reinventing the wheel.

This task is pretty important (we are trying to create billions a year in economic value here!) and your thinking time is not the blocker; take your time and really mull things over. I'd suggest writing a draft revision and then looking at it anew and making improvements. Really do your best to get into the head of the user and understand what they want and need.

### The iteration loop

After improving the skill:

1. Apply your improvements to the skill
2. Rerun all test cases into a new `iteration-<N+1>/` directory, including baseline runs. If you're creating a new skill, the baseline is always `without_skill` (no skill) — that stays the same across iterations. If you're improving an existing skill, use your judgment on what makes sense as the baseline: the original version the user came in with, or the previous iteration.
3. Launch the reviewer with `--previous-workspace` pointing at the previous iteration
4. Wait for the user to review and tell you they're done
5. Read the new feedback, improve again, repeat

Keep going until:
- The user says they're happy
- The feedback is all empty (everything looks good)
- You're not making meaningful progress

---

## Advanced: Blind comparison

For situations where you want a more rigorous comparison between two versions of a skill (e.g., the user asks "is the new version actually better?"), there's a blind comparison system. Read `agents/comparator.md` and `agents/analyzer.md` for the details. The basic idea is: give two outputs to an independent agent without telling it which is which, and let it judge quality. Then analyze why the winner won.

This is optional, requires subagents, and most users won't need it. The human review loop is usually sufficient.

---

## Description Optimization

The description field in SKILL.md frontmatter is the primary mechanism that determines whether Claude invokes a skill. After creating or improving a skill, offer to optimize the description for better triggering accuracy.

### Step 1: Generate trigger eval queries

Create 20 eval queries — a mix of should-trigger and should-not-trigger. Save as JSON:

```json
[
  {"query": "the user prompt", "should_trigger": true},
  {"query": "another prompt", "should_trigger": false}
]
```

The queries must be realistic and something a Claude Code or Claude.ai user would actually type. Not abstract requests, but requests that are concrete and specific and have a good amount of detail. For instance, file paths, personal context about the user's job or situation, column names and values, company names, URLs. A little bit of backstory. Some might be in lowercase or contain abbreviations or typos or casual speech. Use a mix of different lengths, and focus on edge cases rather than making them clear-cut (the user will get a chance to sign off on them).

Bad: `"Format this data"`, `"Extract text from PDF"`, `"Create a chart"`

Good: `"ok so my boss just sent me this xlsx file (its in my downloads, called something like 'Q4 sales final FINAL v2.xlsx') and she wants me to add a column that shows the profit margin as a percentage. The revenue is in column C and costs are in column D i think"`

For the **should-trigger** queries (8-10), think about coverage. You want different phrasings of the same intent — some formal, some casual. Include cases where the user doesn't explicitly name the skill or file type but clearly needs it. Throw in some uncommon use cases and cases where this skill competes with another but should win.

For the **should-not-trigger** queries (8-10), the most valuable ones are the near-misses — queries that share keywords or concepts with the skill but actually need something different. Think adjacent domains, ambiguous phrasing where a naive keyword match would trigger but shouldn't, and cases where the query touches on something the skill does but in a context where another tool is more appropriate.

The key thing to avoid: don't make should-not-trigger queries obviously irrelevant. "Write a fibonacci function" as a negative test for a PDF skill is too easy — it doesn't test anything. The negative cases should be genuinely tricky.

### Step 2: Review with user

Present the eval set to the user for review using the HTML template:

1. Read the template from `assets/eval_review.html`
2. Replace the placeholders:
   - `__EVAL_DATA_PLACEHOLDER__` → the JSON array of eval items (no quotes around it — it's a JS variable assignment)
   - `__SKILL_NAME_PLACEHOLDER__` → the skill's name
   - `__SKILL_DESCRIPTION_PLACEHOLDER__` → the skill's current description
3. Write to a temp file (e.g., `/tmp/eval_review_<skill-name>.html`) and open it: `open /tmp/eval_review_<skill-name>.html`
4. The user can edit queries, toggle should-trigger, add/remove entries, then click "Export Eval Set"
5. The file downloads to `~/Downloads/eval_set.json` — check the Downloads folder for the most recent version in case there are multiple (e.g., `eval_set (1).json`)

This step matters — bad eval queries lead to bad descriptions.

### Step 3: Run the optimization loop

Tell the user: "This will take some time — I'll run the optimization loop in the background and check on it periodically."

Save the eval set to the workspace, then run in the background:

```bash
python -m scripts.run_loop \
  --eval-set <path-to-trigger-eval.json> \
  --skill-path <path-to-skill> \
  --model <model-id-powering-this-session> \
  --max-iterations 5 \
  --verbose
```

Use the model ID from your system prompt (the one powering the current session) so the triggering test matches what the user actually experiences.

While it runs, periodically tail the output to give the user updates on which iteration it's on and what the scores look like.

This handles the full optimization loop automatically. It splits the eval set into 60% train and 40% held-out test, evaluates the current description (running each query 3 times to get a reliable trigger rate), then calls Claude to propose improvements based on what failed. It re-evaluates each new description on both train and test, iterating up to 5 times. When it's done, it opens an HTML report in the browser showing the results per iteration and returns JSON with `best_description` — selected by test score rather than train score to avoid overfitting.

### How skill triggering works

Understanding the triggering mechanism helps design better eval queries. Skills appear in Claude's `available_skills` list with their name + description, and Claude decides whether to consult a skill based on that description. The important thing to know is that Claude only consults skills for tasks it can't easily handle on its own — simple, one-step queries like "read this PDF" may not trigger a skill even if the description matches perfectly, because Claude can handle them directly with basic tools. Complex, multi-step, or specialized queries reliably trigger skills when the description matches.

This means your eval queries should be substantive enough that Claude would actually benefit from consulting a skill. Simple queries like "read file X" are poor test cases — they won't trigger skills regardless of description quality.

### Step 4: Apply the result

Take `best_description` from the JSON output and update the skill's SKILL.md frontmatter. Show the user before/after and report the scores.

---

### Package and Present (only if `present_files` tool is available)

Check whether you have access to the `present_files` tool. If you don't, skip this step. If you do, package the skill and present the .skill file to the user:

```bash
python -m scripts.package_skill <path/to/skill-folder>
```

After packaging, direct the user to the resulting `.skill` file path so they can install it.

---

## Claude.ai-specific instructions

In Claude.ai, the core workflow is the same (draft → test → review → improve → repeat), but because Claude.ai doesn't have subagents, some mechanics change. Here's what to adapt:

**Running test cases**: No subagents means no parallel execution. For each test case, read the skill's SKILL.md, then follow its instructions to accomplish the test prompt yourself. Do them one at a time. This is less rigorous than independent subagents (you wrote the skill and you're also running it, so you have full context), but it's a useful sanity check — and the human review step compensates. Skip the baseline runs — just use the skill to complete the task as requested.

**Reviewing results**: If you can't open a browser (e.g., Claude.ai's VM has no display, or you're on a remote server), skip the browser reviewer entirely. Instead, present results directly in the conversation. For each test case, show the prompt and the output. If the output is a file the user needs to see (like a .docx or .xlsx), save it to the filesystem and tell them where it is so they can download and inspect it. Ask for feedback inline: "How does this look? Anything you'd change?"

**Benchmarking**: Skip the quantitative benchmarking — it relies on baseline comparisons which aren't meaningful without subagents. Focus on qualitative feedback from the user.

**The iteration loop**: Same as before — improve the skill, rerun the test cases, ask for feedback — just without the browser reviewer in the middle. You can still organize results into iteration directories on the filesystem if you have one.

**Description optimization**: This section requires the `claude` CLI tool (specifically `claude -p`) which is only available in Claude Code. Skip it if you're on Claude.ai.

**Blind comparison**: Requires subagents. Skip it.

**Packaging**: The `package_skill.py` script works anywhere with Python and a filesystem. On Claude.ai, you can run it and the user can download the resulting `.skill` file.

**Updating an existing skill**: The user might be asking you to update an existing skill, not create a new one. In this case:
- **Preserve the original name.** Note the skill's directory name and `name` frontmatter field -- use them unchanged. E.g., if the installed skill is `research-helper`, output `research-helper.skill` (not `research-helper-v2`).
- **Copy to a writeable location before editing.** The installed skill path may be read-only. Copy to `/tmp/skill-name/`, edit there, and package from the copy.
- **If packaging manually, stage in `/tmp/` first**, then copy to the output directory -- direct writes may fail due to permissions.

---

## Cowork-Specific Instructions

If you're in Cowork, the main things to know are:

- You have subagents, so the main workflow (spawn test cases in parallel, run baselines, grade, etc.) all works. (However, if you run into severe problems with timeouts, it's OK to run the test prompts in series rather than parallel.)
- You don't have a browser or display, so when generating the eval viewer, use `--static <output_path>` to write a standalone HTML file instead of starting a server. Then proffer a link that the user can click to open the HTML in their browser.
- For whatever reason, the Cowork setup seems to disincline Claude from generating the eval viewer after running the tests, so just to reiterate: whether you're in Cowork or in Claude Code, after running tests, you should always generate the eval viewer for the human to look at examples before revising the skill yourself and trying to make corrections, using `generate_review.py` (not writing your own boutique html code). Sorry in advance but I'm gonna go all caps here: GENERATE THE EVAL VIEWER *BEFORE* evaluating inputs yourself. You want to get them in front of the human ASAP!
- Feedback works differently: since there's no running server, the viewer's "Submit All Reviews" button will download `feedback.json` as a file. You can then read it from there (you may have to request access first).
- Packaging works — `package_skill.py` just needs Python and a filesystem.
- Description optimization (`run_loop.py` / `run_eval.py`) should work in Cowork just fine since it uses `claude -p` via subprocess, not a browser, but please save it until you've fully finished making the skill and the user agrees it's in good shape.
- **Updating an existing skill**: The user might be asking you to update an existing skill, not create a new one. Follow the update guidance in the claude.ai section above.

---

## Reference files

The agents/ directory contains instructions for specialized subagents. Read them when you need to spawn the relevant subagent.

- `agents/grader.md` — How to evaluate assertions against outputs
- `agents/comparator.md` — How to do blind A/B comparison between two outputs
- `agents/analyzer.md` — How to analyze why one version beat another

The references/ directory has additional documentation:
- `references/schemas.md` — JSON structures for evals.json, grading.json, etc.

---

Repeating one more time the core loop here for emphasis:

- Figure out what the skill is about
- Draft or edit the skill
- Run claude-with-access-to-the-skill on test prompts
- With the user, evaluate the outputs:
  - Create benchmark.json and run `eval-viewer/generate_review.py` to help the user review them
  - Run quantitative evals
- Repeat until you and the user are satisfied
- Package the final skill and return it to the user.

Please add steps to your TodoList, if you have such a thing, to make sure you don't forget. If you're in Cowork, please specifically put "Create evals JSON and run `eval-viewer/generate_review.py` so human can review test cases" in your TodoList to make sure it happens.

Good luck!


OK, so I've read the skill creator guide. Now I need to create a skill that:

1. Takes a CLI tool name as input
2. Gets the tool's version info (--version, -v, etc.)
3. Discovers all commands and subcommands (--help, -h, etc.)
4. Gets help text for each command/subcommand
5. Translates command descriptions into Chinese
6. Outputs a well-structured Markdown document with:
   - Title with version number/name
   - Table of contents
   - Command count summary
   - Detailed command reference with Chinese descriptions

Let me create this skill with a clean structure. I'll call it `cli-guide-zh-skill` or `cli-doc-zh-skill`.

Let me think about the skill structure:
- SKILL.md - main instructions
- scripts/ - maybe a helper script to discover commands

Actually, looking at the existing `command-help-zh-skill`, let me check it first to avoid duplication and understand the pattern.

让我先看看已有的 `command-help-zh-skill`，避免重复：


---
name: command-help-zh-skill
description: 为任意 CLI 命令创建独立、无依赖的 Bash 包装脚本，将帮助文本翻译成中文，并只把说明性描述高亮为黄色。适用于用户希望获得本地化的 `--help` 体验，同时保持命令名称和参数不着色的场景。
---

# 命令帮助中文高亮

## 适用场景

用户要把任意命令的 `--help` / `-h` 帮助页做成中文版本，并且要求：

- 只高亮“介绍 / 描述”文字
- 命令名、参数名、选项名保持普通颜色
- 脚本必须是单文件 `bash`
- 不能依赖复杂工具链，优先只用 `printf`、`case`、`cat`

## 处理流程

1. 先确认目标命令名，例如 `codex`、`git`、`tea`、`gh`，或由用户提供 `--help` 输出。
2. 如果没有原始帮助内容，就先运行 `<command> --help` 获取输出。
3. 翻译成自然、简洁的中文。
4. 保留原始结构：
   - 标题
   - 简介
   - 用法
   - 命令
   - 参数
   - 选项
5. 输出时只让说明文字使用 ANSI 黄色。
   - 例如 `\033[1;33m`
   - 结束后恢复默认颜色
6. 命令名、参数、选项、括号内容保持普通颜色，不要整行染色。
7. 生成可直接放到全局 PATH 的脚本，默认命名为 `<command>-help`；如果用户要求或命名冲突，再用 `<command>-help-zh`。

## 实现要求

- 必须是独立脚本，不能依赖仓库内外的其他文件。
- 脚本开头应固定目标命令名，执行时再调用原始命令的 `--help`。
- 推荐使用 `printf` 逐行输出，避免把整段文本一起染色。
- 如果需要分隔“左侧标签”和“右侧说明”，先打印标签，再单独打印黄色说明。
- 保持输出整洁，避免多余前导空格。

## 输出标准

- 中文表达自然，优先清晰准确。
- 说明部分高亮黄色。
- 可以直接复制到 `/usr/local/bin/` 之类的位置使用。
- 如果用户指定了固定命令名，按用户要求命名。


总计 16
drwxr-xr-x  3 root root 4096  5月12日 15:00 .
drwxr-xr-x 12 root root 4096  6月12日 11:06 ..
drwxr-xr-x  2 root root 4096  5月12日 15:00 agents
-rw-r--r--  1 root root 1972  5月12日 14:54 SKILL.md


OK, so the existing `command-help-zh-skill` is about creating a bash wrapper script that translates help text to Chinese and highlights descriptions in yellow. This is different from what the user wants - they want a full markdown document guide for a CLI tool.

The user's skill should:
1. Take a CLI tool name (e.g., `gh`, `docker`, `kubectl`)
2. Get version info
3. Discover all commands and subcommands recursively
4. Get help for each command
5. Translate descriptions to Chinese
6. Output a structured markdown document with:
   - Title with version
   - Table of contents
   - Command count summary
   - Each command with Chinese description

Let me create the skill. I'll call it `cli-guide-zh-skill`.

The skill needs a good strategy for discovering commands. The approach I used in this conversation was:
1. Run `tool --help` to get top-level commands
2. For each command, run `tool <command> --help` to get subcommands
3. Repeat recursively

I should also try `tool -h`, `tool help`, `tool help reference` etc.

Let me write a comprehensive SKILL.md and maybe a helper script.

Actually, let me think about what the skill should contain:

1. **SKILL.md** - The main skill file with instructions
2. **scripts/discover_commands.py** - A Python script that automatically discovers all commands and subcommands for any CLI tool

The Python script would be useful because discovering commands recursively is a repetitive task that benefits from automation.

Let me design this:

### SKILL.md Design:
- Name: `cli-guide-zh-skill`
- Description: When user asks to summarize/document a CLI tool into a Chinese markdown guide, including version info, command count, and Chinese descriptions for each command.
- Workflow:
  1. Get version info
  2. Discover all commands recursively
  3. Get help text for each command
  4. Translate to Chinese
  5. Output markdown with TOC, version info, command count, and detailed reference

### Script Design:
A Python script that:
- Takes a command name as input
- Tries `--version`, `-v`, `version` to get version info
- Tries `--help`, `-h`, `help` to get top-level help
- Parses help output to extract subcommands
- Recursively discovers all subcommands
- Outputs structured JSON with all commands and their help text

This is a good approach. Let me write it.

Actually, I should keep it simpler. The skill should guide the AI to do this manually, since different CLI tools have different help formats. A script that tries to parse arbitrary help output is fragile. Better to have the AI do it iteratively with bash, like what we did in this conversation.

But I could provide a helper script that does the basic discovery. Let me think...

Actually, for maximum reliability, the approach should be:
1. Use a Python script to recursively discover commands by trying --help on each
2. Parse the help output heuristically
3. Output structured data that the AI can then use to create the markdown

This way the AI doesn't need to manually run dozens of commands.

Let me write both the SKILL.md and a discovery script.

The script should:
- Accept a command name
- Try to get version
- Try `cmd help`, `cmd --help`, `cmd -h` to find top-level commands
- For each discovered command, recursively discover subcommands
- Output JSON with all command paths, help snippets

Let me write this now. I'll make the script robust by handling different help formats.

Let me create the skill directory structure:

```
cli-guide-zh-skill/
├── SKILL.md
└── scripts/
    └── discover_cmds.py
```

Let me write these files.

好的，这个需求和现有的 `command-help-zh-skill` 是不同方向——那个是做 Bash 帮助脚本包装，用户要的是**生成完整的 Markdown 命令参考指南**。我来创建这个 skill。


(no output)


write

---
name: cli-guide-zh-skill
description: 将任意命令行工具（CLI tool）的完整命令树总结为中文 Markdown 参考指南。当用户要求把某个 CLI 工具生成文档、总结命令、写成指南、列出所有命令并翻译成中文时使用此技能。触发词包括：总结命令行工具、CLI 命令指南、命令参考文档、把xx工具整理成文档、生成命令手册、命令行工具文档化。
---

# CLI 工具中文 Markdown 指南生成器

将任意命令行工具的完整命令树发现、翻译并整理为结构化中文 Markdown 参考指南。

## 适用场景

用户说类似以下内容时触发：
- "帮我把 gh 命令行工具总结成 markdown 文档"
- "把 docker 的所有命令整理成中文指南"
- "生成 kubectl 命令参考手册"
- "列出 xx 工具有多少个命令"
- "把 xx 的 help 翻译成中文文档"

## 输出格式

生成的 Markdown 文档结构**必须**遵循以下模板：

```markdown
# {工具名} 中文参考指南

> 版本：{版本号}（{版本名称/构建信息}）
> 命令总数：{顶层命令数} | 子命令总数：{所有子命令数} | 合计：{总计}

---

## 目录

- [1. 概述](#1-概述)
- [2. 顶层命令一览](#2-顶层命令一览)
- [3. 命令详细参考](#3-命令详细参考)
  - [3.x {命令名}](#3x-命令名)
    - [3.x.y {子命令名}](#3xy-子命令名)

---

## 1. 概述

{工具的简短中文介绍，从帮助信息中提取}

## 2. 顶层命令一览

| 命令 | 中文说明 | 子命令数 |
|------|----------|---------|
| ... | ... | ... |

## 3. 命令详细参考

### 3.1 `cmd`

{中文说明}

**用法：** `cmd [flags]`

**子命令：** （如有）

| 子命令 | 中文说明 |
|--------|---------|
| ... | ... |

**选项：** （如有）

| 选项 | 中文说明 |
|------|---------|
| ... | ... |
```

## 执行流程

### 第一步：获取版本信息

尝试以下命令（按优先级依次尝试，成功即停）：

```bash
<tool> --version
<tool> -v
<tool> version
```

记录版本号和版本名称/构建信息。

### 第二步：发现完整命令树

**使用辅助脚本自动发现**（推荐）：

```bash
python3 {SKILL_DIR}/scripts/discover_cmds.py <tool_name>
```

脚本会递归探索所有命令和子命令，输出 JSON 结构，包含：
- 每个命令的路径（如 `repo.autolink.create`）
- 每个命令的帮助文本片段
- 层级关系

如果脚本无法正常工作（某些工具的帮助格式特殊），则手动递归发现：

1. 运行 `<tool> --help` 或 `<tool> -h` 或 `<tool> help`，获取顶层命令列表
2. 对每个非叶子命令，运行 `<tool> <subcmd> --help`，获取其子命令
3. 重复步骤 2，直到所有命令树都被遍历
4. 对于叶子命令，运行 `--help` 获取其选项和用法

提取方法：从帮助输出中寻找类似 `COMMANDS:`、`Available commands:`、`子命令:` 等段落后紧跟的缩进行，每行第一个词通常就是子命令名。

### 第三步：收集帮助信息

对发现的每个命令（含子命令），收集其帮助文本：

```bash
<tool> <subpath> --help    # 优先
<tool> <subpath> -h         # 备选
<tool> <subpath> help       # 再备选
```

从帮助文本中提取：
- 简短描述（翻译为中文）
- 用法格式
- 子命令列表及描述
- 选项/标志列表及描述

### 第四步：翻译与整理

- 将所有英文描述翻译为**自然、简洁的中文**
- 保留命令名、参数名、选项名为原文（不翻译）
- 用语保持一致，例如 `list` 始终翻译为"列表"或"列出"
- 常见术语翻译参考：

| 英文 | 中文 |
|------|------|
| create | 创建 |
| delete | 删除 |
| list | 列出 |
| view | 查看 |
| edit | 编辑 |
| update | 更新 |
| add | 添加 |
| remove | 移除 / 删除 |
| set | 设置 |
| get | 获取 |
| download | 下载 |
| upload | 上传 |
| install | 安装 |
| search | 搜索 |
| clone | 克隆 |
| fork | 派生 |
| merge | 合并 |
| push | 推送 |
| pull | 拉取 |
| commit | 提交 |
| branch | 分支 |
| tag | 标签 |
| release | 发行 |
| repository | 仓库 |
| issue | 议题 / Issue |
| pull request | 拉取请求 / PR |
| workflow | 工作流 |
| cache | 缓存 |
| secret | 密钥 |
| variable | 变量 |
| attestation | 证明 |
| authenticate | 认证 |
| configuration | 配置 |
| extension | 扩展 |

### 第五步：生成 Markdown 文档

按照上面定义的模板格式，组装最终文档：

1. 文档最前面显示版本号和命令统计
2. 自动生成目录（锚点链接）
3. 按命令分组组织内容，层级与命令树一致
4. 每个命令包含：中文说明、用法、子命令表（如有）、选项表（如有）
5. 保存到用户指定路径，或默认保存到 `/shumengya/docs/<tool>-guide.md`

## 统计规则

- **顶层命令**：帮助中列出的第一级命令
- **子命令**：所有二级及以下的命令
- **命令总数** = 顶层命令数 + 所有子命令数
- 别名（alias）不计入总数，但在文档中标注
- Help topics（纯帮助主题，非可执行命令）单独列出，不计入命令总数

## 注意事项

- 某些工具的帮助输出可能包含别名（如 `gh co` 是 `pr checkout` 的别名），需要识别并标注
- 某些工具的子命令可能是嵌套的（如 `gh repo autolink create`），需要递归发现到最深层
- 如果工具的帮助输出不是标准格式（如彩色输出、表格格式），需要灵活解析
- 对于 preview/实验性命令，在中文说明中标注"（预览版）"或"（实验性）"
- 生成的文档应该让不熟悉该工具的人也能快速查阅
- 如果命令数量非常多（>100个），考虑按功能分组，而不是单纯按字母顺序

## 术语对照表优先级

1. 如果工具本身有官方中文文档，优先采用其术语翻译
2. 否则参考上面的常见术语翻译表
3. 约定俗成的英文术语（如 PR、Issue、PR、Commit、Branch）可不翻译，但首次出现时附中文注释


Successfully wrote 3251 bytes to /shumengya/project/agent/sproutclaw/.pi/agent/skills/cli-guide-zh-skill/SKILL.md