@buildinternet/releases-skills 0.47.0 → 0.49.0

package/package.json

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

package/skills/finding-changelogs/SKILL.md

@@ -240,3 +240,5 @@ Organizations can have multiple distinct products (e.g., Vercel → Next.js, Tur
 Use product and org management operations to organize what you find. CLI: `releases admin product create`, `releases admin org tag add`, `releases categories`. Typed tools: `manage_product`, `manage_org` — each carries the valid category list in its description (also provided in your system prompt).
 
 Don't force product groupings when sources are ambiguous — leave them at the org level and note suggestions in the state file.
+
+When a company is multi-product (you found a multi-product `changelog.json`, or distinct product changelogs/repos), carry that grouping into onboarding by tagging each source with its `productName`/`productSlug` (see *Grouping sources into products* in `managing-sources`). Index only the org's own products, not ecosystem/community plugins.

package/skills/managing-sources/SKILL.md

@@ -65,6 +65,19 @@ Rules, in priority order:
 
 When in doubt: would a developer reading this name on its own (with the org already shown above) recognize what it is? If yes, strip. If no, keep the prefix.
 
+### Grouping sources into products
+
+**Grouping sources into products.** Most companies are single-product — leave `productSlug`/`productName` unset and sources attach directly to the org (the default).
+
+Only when a company ships **2 or more genuinely distinct products** — each with its own identity and release cadence (Vercel → Next.js, Turborepo, SWR; Datadog → APM, RUM, Browser SDK) — tag each discovered source with the product it belongs to: `productName` (canonical name, same naming rules as sources — no org prefix) and `productSlug` (stable kebab-case, per-org unique).
+
+A product is a distinct offering, **not**:
+- the company/engineering blog, newsroom, or all-in-one changelog → leave org-direct (untagged)
+- the docs site or marketing feed → org-direct
+- every individual GitHub repo by default — only repos that are themselves a recognized product
+
+If you can't name 2+ distinct products with confidence, tag nothing. Spurious products are worse than none.
+
 ### Organization descriptions
 
 When creating an org, include a brief one-sentence product description. This grounds AI summaries for lesser-known products, and it's also the primary signal for the entity vector index — the unified `search` tool (and the registry side of hybrid search) matches on description + category, not just name. A good description noticeably improves recall.

package/skills/releases-cli/SKILL.md

@@ -50,6 +50,10 @@ Two commands built for agents specifically:
 
 `releases get <source> --json` reports `hasChangelogFile` and the `changelogUrl` keyless, so you can tell whether a source maintains a checked-in CHANGELOG.md. To read the **sliced content** keyless, use the MCP's `get_catalog_entry` (with `changelog_tokens` / `nextOffset`) or fetch the `changelogUrl` directly — the CLI's `releases admin source changelog` wrapper is key-gated and won't run without auth.
 
+### Submitting a source (keyless)
+
+`releases submit <url>` suggests a changelog or release-notes URL for the registry — the same review queue the [web submit form](https://releases.sh/submit) feeds, no key required. Scheme is optional (`https://` assumed); `--note` adds context and `--contact` an optional reply email. With no argument in a TTY it prompts; it also reads a piped URL from stdin. Its sibling `releases feedback "<message>"` sends product feedback the same keyless way. Maintainers triage submissions under the key-gated `releases admin recommendations …` (see the admin reference).
+
 ## Common Mistakes
 
 - `releases list` lists sources (alias `releases sources`). Do NOT write `releases sources list` — it reads `list` as a source slug and fails with "Source not found: list".

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

@@ -211,3 +211,19 @@ releases admin mcp serve
 ```
 
 Useful for clients that only support stdio transport. For native remote MCP support (Claude Code, Codex), connect directly to `https://mcp.releases.sh/mcp` instead.
+
+## Recommendations
+
+Review and triage the source URLs that users submit keyless via `releases submit` (and the [web submit form](https://releases.sh/submit)). The submit side needs no key; only the review verbs below do.
+
+```bash
+releases admin recommendations list                          # newest first
+releases admin recommendations list --status new --type source
+releases admin recommendations list --include-archived --cursor <cursor>
+releases admin recommendations triage <id> --status closed   # new | triaged | closed
+releases admin recommendations archive <id>                  # hide from default list
+releases admin recommendations archive <id> --undo           # restore
+releases admin recommendations delete <id>                   # permanent — type the id to confirm, or --yes
+```
+
+`list` is cursor-paginated (`--limit`, follow `--cursor` from the previous page) and hides archived rows unless `--include-archived` is passed. Prefer `archive` over `delete` for a reversible removal. Recommendation ids are `rec_…`. Mirrors the `releases admin feedback …` triage surface.

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

@@ -132,6 +132,21 @@ releases lookup domain vercel.com
 releases lookup domain https://tailwindcss.com/blog
 ```
 
+## Submit a source
+
+Suggest a changelog or release-notes URL for the registry (keyless — no account or key). This feeds the same review queue as the [web submit form](https://releases.sh/submit); maintainers triage it under the key-gated `releases admin recommendations …`.
+
+```bash
+releases submit https://acme.dev/changelog                  # one-shot
+releases submit acme.dev/changelog                          # scheme optional — https:// is assumed
+releases submit                                             # prompt for the URL (interactive)
+echo "https://acme.dev/releases" | releases submit          # pipe from stdin
+releases submit https://acme.dev/changelog --note "GitHub: acme/acme" --contact you@example.com
+releases submit https://acme.dev/changelog --dry-run --json # preview the payload, send nothing
+```
+
+`--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.
+
 ## Agent self-discovery
 
 ```bash