github-statuslisted

Cross-machine overview of your GitHub-owned local clones — every repo with pending work (uncommitted changes, unpushed commits, inbound remote commits), open issues, or convention versions still to adopt, merged across this machine and its peer, with branch, counts, age of the oldest pending work, how far behind /adopt each clone is, and a one-line summary per working machine. Prints a box table and writes a self-contained HTML report. Each run fetches every repo's origin on both machines so the counts reflect the current remote. TRIGGER when: user asks "/github-status", wants a cross-project overview of their repos, "which repos have unpushed commits", "what's new on remotes", "what have I been working on", "which repos are behind on conventions", or "what is uncommitted on the other machine". DO NOT TRIGGER when: user is asking about a single specific repo — that is `/repo-status`, which runs this same scan with `--repo`.
AnotherSava/claude-code-common · ★ 1 · Code & Development · score 74

Install: claude install-skill AnotherSava/claude-code-common

## Context - Config file: !`test -f ~/.claude/skills/github-status/config/config.env && echo PRESENT || echo MISSING` - GitHub user (script default): AnotherSava — override via `GITHUB_USER` env var ## 1. Ensure the config exists If **Config file** above is `PRESENT`, go straight to step 2. Otherwise ask the user (via one `AskUserQuestion` call carrying both questions) for: 1. **Projects root** — the absolute path to the directory holding all their local clones. Suggest `$HOME/Projects` on macOS, `$HOME/code` on Linux, `D:/projects` on Windows. 2. **The other machine** — whether there is a second machine to include, and if so its SSH target (`user@host`). Offer "no other machine" as an option; a single-machine report is a supported configuration, not a degraded one. Then write `~/.claude/skills/github-status/config/config.env`: ``` # github-status skill config — gitignored, user-specific PROJECTS_ROOT="<absolute path>" MACHINE_NAME="<what to call this machine in the report>" PEER_SSH="<user@host>" PEER_PYTHON="<the interpreter name on the peer>" ``` - Drop the `PEER_SSH` and `PEER_PYTHON` lines entirely when there is no second machine. - `PEER_PYTHON` is `python` when the peer runs Windows and `python3` everywhere else — a Windows install has no `python3` on PATH, and a Homebrew macOS install has no bare `python`. Getting this wrong shows up as the peer row reading `not reached`. - `MACHINE_NAME` defaults to the hostname when omitted. Set it when the hostna