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`:

```bash
RAW="$(printf '%s' "${var}" | sed -e 's/^[[:space:]]*//' -e 's/[[:space:]]*$//')"

# Config capture (Telegram force-reply): var="add-repo:<owner/repo>" appends to the watchlist,
# confirms, and ends — it is NOT a view, so it must be intercepted before the VIEW parse below.
case "$RAW" in
  add-repo:*)
    CAND="$(printf '%s' "${RAW#add-repo:}" \
      | sed -e 's#^https\?://github.com/##' -e 's/^@//' -e 's/\.git$//' \
            -e 's/^[[:space:]]*//' -e 's/[[:space:]].*$//')"
    if ! printf '%s' "$CAND" | grep -qE '^[A-Za-z0-9._-]+/[A-Za-z0-9._-]+$'; then
      ./notify "Couldn't read \"$CAND\" as a repo. Reply with owner/repo (e.g. acme/api)."
      # log: - view: add-repo (var="${var}") → BAD_VALUE
      exit 0
    fi
    mkdir -p memory; touch memory/watched-repos.md
    if grep -qiE "^[[:space:]]*-[[:space:]]*${CAND}[[:space:]]*$" memory/watched-repos.md; then
      ./notify "Already watching $CAND."
    else
      printf -- '- %s\n' "$CAND" >> memory/watched-repos.md
      ./notify "Now watching $CAND — it'll show up in the next GitHub Monitor run."
    fi
    # log under ### github-monitor: - view: add-repo (var="${var}") → $CAND
    exit 0 ;;
esac

if [ -z "$RAW" ]; then
  VIEW=monitor; SCOPE=""
else
  VIEW_TOKEN="$(printf '%s' "$RAW" | awk '{print tolower($1)}')"
  SCOPE="$(printf '%s' "$RAW" | sed -E 's/^[^[:space:]]+[[:space:]]*//')"   # everything after the first word
  case "$VIEW_TOKEN" in
    issues|releases|prs) VIEW="$VIEW_TOKEN" ;;
    *)                   VIEW=monitor; SCOPE="$RAW" ;;   # bare owner/repo scopes the combined monitor
  esac
fi
```

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. 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.

From aeonfun/aeon, MIT.

More from aeonfun/aeon