@buildinternet/releases-skills 0.63.0 → 0.64.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@buildinternet/releases-skills",
-  "version": "0.63.0",
+  "version": "0.64.0",
   "description": "Agent skills bundled with the Releases CLI. Markdown playbooks for changelog ingest, discovery, and analysis.",
   "type": "module",
   "license": "MIT",

package/skills/releases-cli/SKILL.md

@@ -62,6 +62,24 @@ Two commands built for agents specifically:
 - There is **no** `summary` or `compare` command in this CLI, and **no** AI summarization tools on the hosted MCP (`summarize_changes` / `compare_products` do not exist). To summarize or compare, read each entity with `releases get` / `releases tail` (or `--json`) and synthesize the answer yourself.
 - Don't reach for `admin` commands to do reads — every read above is keyless. `admin` is only for registry maintenance and requires a key (below).
 
+## Signed-in user commands (`releases login`)
+
+After `releases login` (device flow) or with a stored `relu_` key, you can manage your own account state — no admin key required:
+
+```bash
+releases follow vercel              # follow an org or product
+releases following                # list follows
+releases feed                     # personalized release timeline
+
+releases webhook list             # your outbound webhook subscriptions
+releases webhook add --scope follows --url https://your.app/hook
+releases webhook add --org vercel --url https://your.app/hook
+releases webhook test <id>        # enqueue a signed test delivery
+releases webhook verify --key …   # local HMAC check (no auth)
+```
+
+Org-scoped webhooks: up to 10 per account (`--org`, optional `--source`, `--product`, `--type feature|rollup`). Follows-scoped: one webhook that tracks your current follow graph (real-time sibling to `feed` + digest email); optional `--type` narrows delivery. `webhook edit` can update filters (`--clear-source`, `--clear-product`, `--clear-type`). Signing keys are shown once on `add` / `rotate-secret`. Operator/admin webhooks (`releases admin webhook …`) are a separate root-key surface.
+
 ## Admin surface (invite-only — reads never need it)
 
 `releases admin <noun> <verb>` manages the registry (create/update sources, orgs, products; fetch; discovery; policies). It requires `RELEASES_API_KEY`, and **keys are not self-serve** — there's no public signup. Admin commands fail fast at startup without a key, so don't retry them unauthenticated, and don't fall back to them for read tasks. If a user asks how to get a key, tell them access is currently invite-only and point them at the project repo; don't invent a signup URL. Full operator reference: **[references/admin.md](references/admin.md)**.

package/skills/releases-cli/references/reader.md

@@ -159,6 +159,26 @@ releases submit https://acme.dev/changelog --dry-run --json # preview the payloa
 
 `--note` carries extra context (product name, GitHub repo, feed quirks); `--contact` is an optional email to notify once it's reviewed. With no URL argument in an interactive terminal, `submit` prompts for the URL (and the optional note/contact); otherwise pass it inline or pipe via stdin. Index pages, changelogs, GitHub releases, and feed URLs are all ideal.
 
+## Signed-in account commands (`releases login`)
+
+These act on **your** account via `/v1/me/*` — sign in first (`releases login` or `RELEASES_API_KEY`):
+
+```bash
+releases follow vercel
+releases following
+releases feed
+
+releases webhook list
+releases webhook add --scope follows --url https://your.app/hook
+releases webhook add --org vercel --url https://your.app/hook
+releases webhook add --org vercel --product next-js --type feature --url https://your.app/hook
+releases webhook edit <id> --type rollup
+releases webhook test <id>
+releases webhook verify --key <hex> --signature … --timestamp … --body-file -
+```
+
+`webhook verify` is local (no auth). Admin webhooks (`releases admin webhook …`) are a separate root-key operator surface.
+
 ## Agent self-discovery
 
 ```bash