pack-submit

> **${var}** — The local skill to publish as a community pack: a skill **slug** (a directory name under `skills/`), optionally followed by flags. **Required.**
> Examples:
> - `token-movers` — package `skills/token-movers/` into a fresh public repo and submit it to the aeon registry
> - `token-movers --repo myorg/aeon-token-movers` — override the pack repo name (default `aeon-skill-pack-<slug>`)
> - `token-movers --no-register` — create and push the pack repo, but skip the registry PR against `aeonfun/aeon`
> - `token-movers --dry-run` — build and validate the pack locally, write nothing to GitHub

If `${var}` is empty, exit `PACK_SUBMIT_NO_VAR`:
```bash
./notify "pack-submit aborted: var empty — pass a skill slug e.g. \"token-movers\""
```
Then stop.

Today is ${today}. Your task is to take the **existing** skill named in `${var}`, wrap it in a standalone community-pack repo (its own GitHub repo with a `skills-pack.json` manifest), and **submit it to the aeon community registry** — a PR against `aeonfun/aeon` that adds both surfaces the registry demands in one diff: a row in the README's **Community Packs** table AND a matching entry in `catalog/skill-packs.json`. This is the inverse of `install-skill`: instead of pulling a community pack in, it pushes one of your own skills out for every other Aeon agent to install with `bin/install-skill-pack`.

## What a community pack is (so you build the right thing)

A community pack is a **public GitHub repo** that holds one or more skills plus a `skills-pack.json` manifest that names and versions them. `bin/install-skill-pack owner/repo` reads that manifest and installs the skills. To be **discoverable** (listed by `bin/install-skill-pack --list` and the dashboard's Community Packs panel), the pack must also be registered in `aeonfun/aeon`'s `catalog/skill-packs.json` + README table. So publishing is two moves: **(a)** stand up the pack repo, **(b)** open the registry PR. This skill does both. Full protocol: `docs/community-skill-packs.md`.

## Steps

1. **Parse and validate `${var}`.** The first whitespace-separated token is the skill slug; the rest are flags (`--repo owner/name`, `--no-register`, `--dry-run`). The slug must match `^[a-z0-9][a-z0-9-]*$` and resolve to a real directory:
   ```bash
   SLUG=$(echo "${var}" | awk '{print $1}')
   FLAGS=$(echo "${var}" | cut -s -d' ' -f2-)
   if ! echo "$SLUG" | grep -qE '^[a-z0-9][a-z0-9-]*$'; then
     ./notify "pack-submit aborted: \"$SLUG\" is not a valid skill slug (lowercase kebab-case)"; exit 0
   fi
   if [ ! -f "skills/$SLUG/SKILL.md" ]; then
     ./notify "pack-submit aborted: skills/$SLUG/SKILL.md not found — run with a slug from \`ls skills/\`"; exit 0
   fi
   ```
   If validation fails, exit `PACK_SUBMIT_BAD_VAR` with the notify above and stop. Extract the boolean flags from `$FLAGS` and the optional `--repo` value.

2. **Read the source skill's metadata.** Everything the manifest and registry entry need is already declared in `skills/$SLUG/SKILL.md`'s frontmatter — read it, don't invent it:
   - **Display name** — `metadata.title`; fall back to the top-level `name:`.
   - **Description** — the top-level `description:` (one line).
   - **Category** — `metadata.category`. Registry categories are an open vocabulary, but first-party-only values (`core`, `evolution`, `basics`) don't describe a third-party pack — if you see one of those, pick the closest community category (`dev`, `crypto`, `productivity`, `research`, `social`) from what the skill actually does. Otherwise pass the category through.
   - **Secrets** — `metadata.requires`. An entry ending in `?` is **optional** → `secrets_optional`; an entry without `?` is **required** → `secrets_required`. Strip the `?`. Registry `secrets_required` must be UPPER_SNAKE env names.
   - **Capabilities** — `metadata.capabilities`, copied verbatim (already the locked taxonomy; see `docs/CAPABILITIES.md`). Omit if absent.

   ```bash
   fm(){ sed -n '/^---$/,/^---$/p' "skills/$SLUG/SKILL.md"; }
   TITLE=$(fm | sed -n 's/^[[:space:]]*title:[[:space:]]*//p' | head -1)
   [ -z "$TITLE" ] && TITLE=$(fm | sed -n 's/^name:[[:space:]]*//p' | head -1)
   DESC=$(fm | sed -n 's/^description:[[:space:]]*//p' | head -1)
   CATEGORY=$(fm | sed -n 's/^[[:space:]]*category:[[:space:]]*//p' | head -1)
   ```
   Collect `requires:`/`capabilities:` list items (lines under those keys beginning with `    - `) into shell arrays; split `requires` into required (no `?`) and optional (trailing `?`, stripped).

3. **Build the pack repo locally.** Stage a clean working tree — the manifest at root, the full skill directory copied verbatim (including any helper scripts/config, not just `SKILL.md`), a README, and an MIT `LICENSE`:
   ```bash
   PACK_DIR=$(mktemp -d)/pack
   mkdir -p "$PACK_DIR/skills/$SLUG"
   cp -R "skills/$SLUG/." "$PACK_DIR/skills/$SLUG/"
   ```
   Write `$PACK_DIR/skills-pack.json` (build it with `python3`/`jq`, never string concatenation, so quoting is safe). Include only fields you actually have:
   ```json
   {
     "name": "<TITLE>",
     "version": "0.1.0",
     "description": "<DESC>",
     "author": "<operator github handle>",
     "license": "MIT",
     "homepage": "https://github.com/<owner>/<pack-repo>",
     "skills": [
       {
         "slug": "<SLUG>",
         "path": "skills/<SLUG>",
         "description": "<DESC>",
         "category": "<CATEGORY>",
         "schedule": "0 12 * * *",
         "default_enabled": false,
         "secrets_required": [ ... ],
         "secrets_optional": [ ... ],
         "capabilities": [ ... ]
       }
     ]
   }
   ```
   Write a `README.md` that names the skill, states its schedule assumption, lists required/optional secrets, and shows the one-line install (`bin/install-skill-pack <owner>/<pack-repo>`). Write a standard MIT `LICENSE` (year `${today}`'s year, copyright the operator handle). Resolve the operator handle once: `OWNER=$(gh api user --jq .login)`.

4. **Pre-flight the pack.** Run the repo's