github-monitor

Files (1)

• SKILL.md

SKILL.md (first lines)

> **${var}** — View selector + optional scope.
> - **empty** → combined **monitor** over every repo in `memory/watched-repos.md`.
> - **`owner/repo`** (a bare repo, no view keyword) → combined **monitor** scoped to that one repo.
> - **`issues [scope]`** → new-issue triage queue. `scope` accepts `owner/repo`, `org:foo`, `user:bar`, or a bare login; empty = all repos owned by the authenticated user.
> - **`releases [repo,repo,…]`** → release upgrade-triage digest. Comma-separated repo list; empty = the built-in watch list.
> - **`prs`** → status tracker for PRs this aeon instance opened across external repos.
> - **`add-repo:<owner/repo>`** → append `owner/repo` to `memory/watched-repos.md`, confirm, and end (the shape the Telegram force-reply sends — see the config-capture note in Shared setup). No view runs.

This skill is four focused views of the same GitHub surface. The combined monitor is the default; `issues`, `releases`, and `prs` each drill into one dimension with the sibling view's own filtering, ranking, and output format. Only the `monitor` and `issues` views take a repo scope; `releases` takes a repo list; `prs` takes no scope (it reads its config from `aeon.yml`/env).

---

## Shared setup (every view)

1. Read `memory/MEMORY.md` for high-level context.
2. Read the last 2 days of `memory/logs/` — used for dedup in the `monitor`, `issues`, and `releases` views.
3. Parse `${var}` into a `VIEW` and a `SCOPE` in your head, not in a shell script (see **Shell shape** below). `RAW` = `${var}` with leading and trailing whitespace trimmed.

   **Config capture (Telegram force-reply)** - `RAW` starting with `add-repo:` appends to the watchlist, confirms, and ends. It is NOT a view, so it is handled before the VIEW parse:
   - `CAND` = the text after `add-repo:`, with a leading `github.com/` prefix (and any `http://` or `https://` scheme before it) removed, a leading `@` removed, a trailing `.git` removed, leading whitespace trimmed, and everything from the first remaining whitespace on dropped.
   - If `CAND` does not match `^[A-Za-z0-9._-]+/[A-Za-z0-9._-]+$`: send `./notify "Couldn't read \"<CAND>\" as a repo. Reply with owner/repo (e.g. acme/api)."`, log `- view: add-repo (var="${var}") → BAD_VALUE` under `### github-monitor`, and stop.
   - Otherwise read `memory/watched-repos.md` (missing = empty). If a line matches `- <CAND>` (case-insensitive, surrounding whitespace ignored): send `./notify "Already watching <CAND>."`. Else append the line `- <CAND>` with Edit (Write if the file is new), then send `./notify "Now watching <CAND> - it'll show up in the next GitHub Monitor run."`.
   - Log under `### github-monitor`: `- view: add-repo (var="${var}") → <CAND>`, and stop.

   **View parse:**
   - `RAW` empty: `VIEW=monitor`, `SCOPE` empty.
   - Else `VIEW_TOKEN` = the first word of `RAW`, lowercased; `SCOPE` = everything after the first word (leading whitespace trimmed).
     - `VIEW_TOKEN` is `issues`, `releases` or `prs`: `VIEW` = `VIEW_TOKEN`.
     - Anything else: `VIEW=monitor`, `SCOPE` = `RAW` (a bare owner/repo scopes the combined monitor).

   **Shell shape.** Each Bash call is one allowed command (pipes are fine). The run refuses a call that sets a variable (`RAW="$(...)"`, `ME=$(...)`), uses `if` / `case` / `[ ... ]`, redirects into a file with `>` or `>>` (/tmp included), puts a `$name` in a jq filter (`--arg prefix ... '$prefix'`), or joins commands with `;`, `&&` or `||`, and each refusal costs a model turn. So the var parse above happens in your head, file changes go through Edit/Write (a command's output reaches a /tmp file through a piped `node -e` writer), values go into jq filters as literal strings (`startswith("<BRANCH_PREFIX>")`), every `date` or `gh api user` lookup is its own call whose printed value you write into later commands literally (`<YESTERDAY>`, `<ME>`), and each per-repo `gh` call has the repo written in literally (`<REPO>`), one call per repo.

4. Dispatch to the matching view section below. Run exactly one view per invocation.

**Selector examples:** `""` → monitor/all · `anza-xyz/agave` → monitor/one-repo · `issues` → issues/all · `issues org:anthropics` → issues/org · `releases` → releases/watch-list · `releases anthropics/claude-code,openai/openai-python` → releases/custom · `prs` → PR tracker.

**Logging convention (all views):** every view appends to `memory/logs/${today}.md` under the single heading `### github-monitor`, and its **first bullet is a discriminator** naming the view that ran: `- view: <monitor|issues|releases|prs> (var="${var}")`. Keep the view-specific bullets exactly as described in each section — the identifiers/URLs they write are what the next run dedups against.

---

## View: monitor  (default — empty var, or a bare `owner/repo` scope)

Tiered urgency scan of PRs, new issues, and new releases across watched repos, with concrete next actions.

### Config

Read repos from `memory/watched-repos.md`. If the file is missing or empty, offer to add the first repo via a Telegram force-reply, then log `GITHUB_MONITOR_EMPTY_CONFIG` (under `### github-monitor`) and end. Send the offer **only** if no `add-repo` prompt was already offered in the last 2 days of `memory/logs/` (dedup so an unconfigured fork isn't nagged every run):

```bash
./notify "No repos on the watchlist yet. Which repo should I watch? Reply with owner/repo." \
  --force-reply --placeholder "owner/repo" \
  --context "github-monitor::add-repo"
```

The reply routes back as `var=add-repo:<owner/repo>`, handled by the config-capture branch in Shared setup. Record `FORCE_REPLY_OFFERED: add-repo` in the log when you send it.

```markdown
# memory/watched-repos.md
- owner/repo
- another-owner/another-repo
```

If `SCOPE` is set (a bare `owner/repo`), monitor **only** that repo. Otherwise monitor every entry in `watched-repos.md`.

### 1. Collect

For each repo, run these three `gh` calls, each its own Bash call with the repo written in literally as `<REPO>`. Capture the JSON; do not trust any shell expansion of untrusted fields.

**Open PRs** (full shape — the extra fields power the tier classifier):
```bash
gh pr list -R <REPO> --state open --limit 30 \
  --json number,title,url,updatedAt,isDraft,reviewDecision,reviewRequests,statusCheckRollup,labels,author
```

**Issues opened in the last 24h**:
```bash
gh issue list -R <REPO> --state open --limit 20 \
  --json number,title,url,createdAt,labels,author
```
Filter client-side to items where `createdAt` is within the last 24h.

**Releases published in the last 24h** (skip drafts and prereleases):
```bash
gh release list -R <REPO> --limit 5 --exclude-drafts --exclude-pre-releases \
  --json tagName,publishedAt,name,url
```
Filter client-side to items where `publishedAt` is within the last 24h.

If any single `gh` call fails (network, auth, 404), record it as `gh_error(<code>)` for that repo and keep going — one repo's failure must not abort the whole run.

### 2. Classify into tiers

Walk every collected item and assign it to exactly one tier. Drop items that match no tier.

**Tier precedence (when multiple criteria qualify, pick the highest):** `ACT NOW > REVIEW > INFO`. Evaluate ACT NOW rules first; if any match, lock the tier and skip further checks for that item. Only fall through to REVIEW if no ACT NOW rule matched, and to INFO only if neither matched.

**ACT NOW** — needs a human decision today:
- Open PR, not draft, with any `statusCheckRollup[].conclusion == "FAILURE"`
- Open PR, not draft, `reviewRequests` non-empty, `updatedAt` older than 72h (reviewer ghosted)
- New issue whose labels match any of: `security`, `critical`, `p0`, `regression`, `outage`, `incident`
- Release whose `tagName` is a major bump vs. the previously logged tag (e.g. `v2.0.0` after `v1.*`)

**REVIEW** — worth a look, not urgent:
- Open PR, not draft, `reviewDecision == "REVIEW_REQUIRED"`, `updatedAt` 48–72h ago
- Open PR, not draft, `mergeStateStatus`/merge conflict markers flagged in `statusCheckRollup`
- New issue labelled `bug` or `p1`
- Release that is a minor or patch bump

**INFO** — background signal:
- Other open, non-draft PRs with `updatedAt` older than 48h
- New issue with no priority label
- Anything else passing the 24/48h windows

Drafts are never ACT NOW or REVIEW — at most INFO, and only if stale >7d. Do not alert on draft PRs just because they're idle.

Cap each tier at 5 items. If a tier would exceed 5, keep the top 5 by (tier rank, then most recently active) and append `…and N more` as the last bullet.

### 3. Dedup

From aeonfun/aeon, MIT.

More from aeonfun/aeon