Skill Triage

SKILL.md preview

---
name: Skill Triage
description: Structured triage for inbound PRs that introduce or modify SKILL.md files — security scan per skill, required-secrets enumeration, cron slot-conflict check, basic quality signals, posted as one PR comment. The receipt that turns a 10-minute manual skill-PR review into a 10-second human decision
var: ""
tags: [dev, community]
---

> **${var}** — PR number on `aaronjmars/aeon` (required, integer). Empty `${var}` → `PR_SKILL_TRIAGE_BAD_VAR`, no writes, no notify. Use `workflow_dispatch` only.

Today is ${today}. Two external skill PRs are open right now — `#231` (`liquidpad-launch` from `liquidpadbot`, 2 days old) and `#241` (`signa-skills`, 10 skills from `codexvritra`, opened today). As `ECOSYSTEM.md` lists 40 projects and `skill-packs.json` grows, **incoming skill PRs are the new contribution model**. The current review path is fully manual: an operator reads the diff, mentally checks for HIGH security findings, counts skills, looks for missing metadata, and tries to remember whether a proposed cron slot collides with an existing one. This skill is the **receipt** that turns that 10-minute manual review into a 10-second human merge decision. It does not auto-merge — it surfaces the facts as a structured PR comment so the human keeps the call.

It is complementary to `pr-triage` (which welcomes every external PR with a generic first-touch comment) and `skill-scan` (which provides the per-file scanner). This skill is the **skill-PR-specific** triage that fans out across every `SKILL.md` in the PR diff, runs the scanner against each, and produces one structured comment covering security + required secrets + cron conflicts + quality signals for the whole pack at once.

Read `memory/MEMORY.md` for context.
Read the last 8 days of `memory/logs/` for prior-run context (skip if dispatched).
Read `soul/SOUL.md` + `soul/STYLE.md` if populated to match voice in the notification.

## Why a separate skill from `pr-triage`

`pr-triage` welcomes every external PR with a generic first-touch comment driven by a verdict rubric over title/body/diff. It does **not** open SKILL.md files, run the security scanner, or check cron-slot collisions — those steps are skill-pack-specific. A unified skill would either bloat `pr-triage` with conditional pack logic on every run (most PRs have no `SKILL.md` change), or skip the scanner on PRs that genuinely need it. Keeping `skill-triage` separate lets the operator dispatch it precisely when an inbound skill PR lands, so the scanner output, secret enumeration, and slot-conflict table all surface in one structured comment without polluting general-purpose triage runs.

## Inputs

| Source | Purpose | Auth |
|--------|---------|------|
| `gh api repos/aaronjmars/aeon/pulls/${PR_NUMBER}` | PR metadata — author, created_at, head SHA, mergeable state | `GH_TOKEN` |
| `gh api repos/aaronjmars/aeon/pulls/${PR_NUMBER}/files` | List of changed file paths (with `status` per file: added / modified / removed) | `GH_TOKEN` |
| `gh api repos/aaronjmars/aeon/contents/{path}?ref={head_sha}` | Each changed `SKILL.md` body for security scan + frontmatter parsing | `GH_TOKEN` |
| `aeon.yml` (local) | Existing cron schedules for slot-conflict check | Local file |
| `skills/skill-scan/scan.sh` (local) | Scanner — reused verbatim (no fork, no shadow copy) | Local script |

No new secrets. GitHub access uses the `gh` CLI (`GH_TOKEN`) per CLAUDE.md.

Writes:
- One PR comment via `gh pr comment ${PR_NUMBER}` (the actual deliverable — this is where the triage receipt lives)
- `memory/topics/skill-triage-state.json` — `{"${PR_NUMBER}": {"head_sha": "abc1234", "commented_at": "<ISO8601>", "verdict": "OK|WARN|BLOCK"}}` so re-dispatch on the same head SHA is a no-op
- `memory/logs/${today}.md` — one log block per run
- Notification via `./notify` — only when a HIGH security finding fires (BLOCK) or a hard cron conflict is detected (everything else is just the PR comment + log)

## Steps

### 0. Bootstra

…