Install Skill

${var} — The community pack to install: owner/repo, optionally followed by specific skill slugs to install only a subset, and optional flags. Required. Examples:

• clawhunter/clawhunter-skills — install the whole pack
• clawhunter/clawhunter-skills clawhunter-bounties — install one skill from it
• richard7463/aeon-skill-pack-claim-audit --branch develop — install from a non-default branch

If ${var} is empty, exit INSTALL_SKILL_NO_VAR:

./notify "install-skill aborted: var empty — pass a pack repo e.g. \"owner/repo\" (optionally + skill slugs)"

Then stop.

Today is ${today}. Your task is to install the community skill pack named in ${var} into this fork and ship it as a PR that auto-merges — so the skills land on main (and show up in the dashboard) with no manual step. Never commit directly to main: the change still flows through a reviewable, CI-gated PR — it just merges itself. This is the dashboard "Install" button's backend: the operator clicked it on a Community Pack card, so be fast, safe, and honest about what landed. The safety gate is real but unchanged: every skill is security-scanned and lands disabled, so nothing executes until the operator sets secrets and flips enabled: true.

How installation works (so you can explain it and trust the output)

The repo already ships a hardened installer, bin/install-skill-pack, which is the single source of truth — do not reimplement it. Given owner/repo it:

1. Downloads the repo tarball and reads its skills-pack.json manifest (per-skill path, schedule, default_enabled, secrets_required, capabilities). No manifest → it falls back to scanning skills/*/SKILL.md.
2. Security-scans every skill from an untrusted source via scripts/skill-scan.sh. Sources listed in skills/security/trusted-sources.txt skip the deep scan (format checks still run). In CI there is no TTY, so a HIGH-severity finding blocks that skill unless --force is passed — this is the safety gate, leave it on.
3. Copies each skill into skills/<slug>/, then updates aeon.yml (added enabled: false so nothing runs until the operator turns it on), skills.json, and records provenance in skills.lock.

Your job is to drive that script, regenerate the catalog, and wrap the result in a reviewable PR.

Steps

1. Parse and validate ${var}. The first whitespace-separated token is the repo; it must match owner/repo (strip a leading https://github.com/ and a trailing .git). Anything after it is either skill slugs or flags passed straight through. If the first token isn't owner/repo, exit INSTALL_SKILL_BAD_VAR:

   ./notify "install-skill aborted: \"${var}\" is not owner/repo format"

   Then stop. Never pass --force or --yes unless the operator explicitly included it in ${var} — the security gate stays on by default.

   Opt-out flag: if ${var} contains --no-merge, the operator wants a PR they'll merge themselves — strip that token here (do not forward it to bin/install-skill-pack, which would reject it) and skip the auto-merge in step 6 (open the PR and stop at the notify with the review link).

2. Preview first (dry run). See what would land before writing anything:

   bin/install-skill-pack ${var} --dry-run 2>&1 | tee /tmp/install-preview.txt

   If the preview shows 0 skills or fails to fetch the repo, exit INSTALL_SKILL_FETCH_FAILED and notify with the error — don't open an empty PR.

3. Branch. Derive a slug from the repo name and create a branch — never work on main:

   REPO_NAME=$(echo "${var}" | awk '{print $1}' | sed 's#.*/##; s/\.git$//')
   git checkout -b "install-pack/${REPO_NAME}"

4. Install for real.

   bin/install-skill-pack ${var} 2>&1 | tee /tmp/install-result.txt

   Read the output. Note: how many installed, how many were skipped/blocked by the security scan, any secrets_required warnings, and any declared capabilities. Trusted sources will say "skipping deep security scan". If everything was blocked and nothing installed, exit INSTALL_SKILL_BLOCKED, notify the operator that the source tripped HIGH-severity findings and that they can review and re-run bin/install-skill-pack ${var} --force from a local clone if they trust it. Then stop.

5. Confirm the catalog regenerated. bin/install-skill-pack already regenerates both skills.json and packs.json at the end of a successful install — packs.json is what routes the new skills into the dashboard's always-visible Installed pack, so it must not be skipped. Re-run them yourself only as a safety net (idempotent), and verify both files actually changed before committing — a skills.json bump without a matching packs.json bump means the skill will be invisible:

   bin/generate-skills-json && bin/generate-packs-json
   git status --short skills.json packs.json   # both should be listed

6. Commit, open a PR, and auto-merge it — never push to main directly; the PR is the audit trail and CI gate. Stage all install changes so no manifest is missed — git add -A (the install touched only skill dirs + aeon.yml, skills.json, skills.lock, packs.json), commit, push the branch, then open the PR and capture its URL:

   PR_URL=$(gh pr create --title "feat: install ${REPO_NAME} community pack" --body "$(cat <<'BODY'
   Installs the **<pack name>** community pack from `${var}` (clicked from the dashboard). Auto-merges once mergeable — skills land **disabled**, so nothing runs until enabled.
   
   ## Skills installed
   - `<slug>` — <one-line description>
   
   ## Security
   - Source trust: <trusted | scanned, N HIGH findings>
   - Skipped/blocked: <none | list with reason>
   
   ## Secrets required before enabling
   - `<ENV_VAR>` — set in repo Actions secrets, then flip the skill to `enabled: true` in aeon.yml
   
   ## Provenance
   Recorded in skills.lock (source repo, branch, commit SHA).
   BODY
   )")

   Fill the placeholders from the install output. Then merge it (unless --no-merge was passed in step 1). Prefer queued auto-merge so CI gates it; fall back to an immediate squash-merge when the repo doesn't have auto-merge enabled:

   gh pr merge "$PR_URL" --squash --delete-branch --auto \
     || gh pr merge "$PR_URL" --squash --delete-branch

   If both merge attempts fail, the repo's "Allow GitHub Actions to create and approve pull requests" setting is likely still off (the dashboard normally enables it before dispatching this skill; a cron/CLI run may not have). Don't error — leave the PR open and tell the operator to merge it (and to turn that setting on: re-run ./aeon init, open the instance in Aeon Connect, which turns it on, or enable it under Settings → Actions → General). All installed skills land disabled — say so in the PR so the operator knows they must enable them.

7. Notify one concise line with the result. On auto-merge success, point the operator at the dashboard (new skills sit in their pack — enable that pack in the Packs view to see them):

   ./notify "Installed & merged ${REPO_NAME} (<N> skills) to main — they land disabled in the <pack> pack; enable the pack in the dashboard, set any required secrets, then flip enabled: true."

   If you opened a PR without merging (--no-merge, or the merge was blocked), say so instead and include the review link: "Installed ${REPO_NAME} (<N> skills) — review & merge: <pr-url>. Skills land disabled."