qiankun is a JavaScript framework for building web applications from independently developed micro frontends, allowing multiple teams to combine apps made with different frameworks. It addresses integration, isolation, deployment independence, runtime sandboxing, performance, and shared dependencies between those smaller applications. Catalogue add-ons provide workflows for using qiankun.
Borrowing it
Nothing to install: this file belongs to umijs/qiankun. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/umijs/qiankun/next/.claude/skills/release-changelog/SKILL.mdgit clone --depth 1 https://github.com/umijs/qiankunWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/umijs/qiankun/release-changelog)<a href="https://agentmods.dev/skills/umijs/qiankun/release-changelog"><img src="https://agentmods.dev/badge/skills/umijs/qiankun/release-changelog/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/umijs/qiankun/release-changelog"><img src="https://agentmods.dev/badge/skills/umijs/qiankun/release-changelog.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector pass
What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00110 | $0.00832 |
| Opus 5 | $0.00055 | $0.00416 |
| Sonnet 5 | $0.00022 | $0.00166 |
| Haiku 4.5 | $0.00011 | $0.00083 |
Grade A, and why
release-changelog scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 12d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 74 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Release changelog
Qiankun releases are commit-driven: CI auto-derives changesets from Conventional Commits, changesets writes each sub-package's own CHANGELOG.md (so npm shows a per-package changelog), and on publish scripts/generate-release-notes.mjs aggregates those into one GitHub Release per version.
That aggregated Release is mechanical (raw per-package changelog lines). This skill polishes it into a human-readable, bilingual write-up — an English version on top, a Chinese version below — after the fact, directly on the GitHub Release, without touching any committed changelog. Read .changeset/README.md for the surrounding flow.
When to run
After a release has been published (the "Version Packages" PR was merged and CI created the GitHub Release). Typically: "polish the latest release notes".
Steps
-
Find the release to polish (default: the most recent one):
gh release list --limit 5 gh release view <tag> --json tagName,name,bodyConfirm the target tag with the user if it's not obviously the latest.
-
Read the mechanical notes from the release
body. This is the raw material — the aggregated per-package changelog. Do not invent anything not present in it (cross-check againstgit log <prev-tag>..<tag>only to understand, not to add unlisted changes). -
Polish the notes, keeping the per-package structure so consumers still see each sub-package and its version. Polishing means:
- Lead with a short Highlights list (2–5 bullets) when the release has notable user-facing changes; skip it for small patch releases.
- Rewrite terse lines into clear, user-facing wording; keep the
(#PR)reference at the end of each line. - De-duplicate: a change that touched many packages is often better stated once under the facade
qiankunsection than repeated under every package. - Drop noise (pure "Updated dependencies" internal bumps).
-
Produce a bilingual document — the full English version first, then the full 简体中文 version, separated by a
---rule. Keep the identical per-package structure and(#PR)references in both halves; translate the prose (highlights, descriptions), never the package names, versions, or PR numbers. Template:
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 12d ago First seen · 74 lines · 110 tokens per session scan A cbe429355a77
release-changelog is a skill published in the GitHub repository umijs/qiankun (16,687 stars, last pushed today), licensed MIT. It adds 110 tokens to every session and 832 once invoked, about $0.0006 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
draft-release-notes
Author the committed release-notes file for a Prisma 8 release (stable or 8.0.0-rc.N) by enumerating the merged PRs since the previous release v tag (stable or -rc.N), resolving opaque TML-NNNN: titles via Linear context (never copied verbatim), triaging public-worthiness, and writing categorized notes — breaking…
publish-npm-version
Cuts the next release of Prisma 8: bumps the root package.json version (on the v8 RC line: 8.0.0-rc.N → rc.N+1), propagates it to every workspace package, and opens a PR titled "chore(release): bump to ". When the maintainer merges the PR, the Publish to npm workflow runs automatically and ships the new version to npm…
pr-snapshot-release
Guide a Mastra maintainer through publishing an npm snapshot from a pull request or a specified repository branch. Use when asked to release, publish, or create a PR snapshot, branch snapshot, canary package build, or branch-specific npm tag. Performs source and branch preflight checks, requires confirmation before…
publish-release
Cut and publish a versioned release of @loopdive/js2 + the js2wasm proxy — bump both manifests in lockstep, land a reviewed release PR, then push the vX.Y.Z tag that triggers npm/JSR publish. Use this whenever the user wants to release, publish, ship, cut, or tag a version, bump the version number, push a release tag…
multipublish
Publish monorepo packages simultaneously to npm and JSR via a platforms config array. Integrates with changesets via stdin pipe or --useChangesetStatus flag. Use experimentalGenerateJSR to skip maintaining a jsr.json. Supports pnpm, bun, npm, yarn (jsr and npm); deno (jsr only). Config via cosmiconfig or package.json…
create-pr
Creates a GitHub PR with a Linear-ticket-prefixed title and a decision-led, narrative description for Prisma 8. Use when the user wants to create a pull request, open a PR, or submit changes for review.