Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/phantom/phantom-connect-sdk/generate-release-notesnpx skills add phantom/phantom-connect-sdk --skill generate-release-notesgit clone --depth 1 https://github.com/phantom/phantom-connect-sdkWhat 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 | $0.00000 | $0.01134 |
| Opus 5 | $0.00000 | $0.00567 |
| Sonnet 5 | $0.00000 | $0.00227 |
| Haiku 4.5 | $0.00000 | $0.00113 |
Grade A, and why
generate-release-notes 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 2d 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 — 140 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Skill: generate-release-notes
Generate a high-level release note summarising what changed between a git tag and the current codebase.
Arguments: <tag> [package] — a git tag to diff against (e.g. v1.2.0, @phantom/[email protected]), and an optional package name to scope the diff (e.g. @phantom/react-sdk). If no package is provided, all packages are included.
Note: Release tags live on the public mirror at
https://github.com/phantom/phantom-connect-sdk. The diff is always performed against the current (internal) repo.
Phase 0 — Determine scope
Parse the arguments:
{tag}— the first argument (required){package}— the second argument (optional)
If {package} is provided, scope all git diff/log commands to packages/{package-dirname}/ where {package-dirname} is derived from the package name (e.g. @phantom/react-sdk → react-sdk). Use the package name in the output filename.
If {package} is not provided, run commands without a path filter to capture all packages, and use all in the output filename.
Phase 1 — Resolve the tag commit from the public repo
The internal repo does not have release tags. Fetch the commit SHA that the tag points to from the public mirror:
# Get the commit SHA the tag resolves to on the public repo
git ls-remote https://github.com/phantom/phantom-connect-sdk.git "refs/tags/{tag}" "refs/tags/{tag}^{}"
Take the last SHA returned (the dereferenced ^{} entry if present, otherwise the only entry). Call this {public-sha}.
Then verify this commit exists in the internal repo:
git -C <repo-root> cat-file -t {public-sha}
If the commit is not found, the internal and public repos may have diverged in history. Stop and report this to the user.
Phase 2 — Gather raw data
Run the following from the repo root using {public-sha} as the base:
# List commits between the tag SHA and HEAD (scoped to package path if provided)
git log {public-sha}...HEAD --oneline --no-merges [-- packages/{package-dirname}/]
# Full diff summary
git diff {public-sha}...HEAD --stat [-- packages/{package-dirname}/]
# Detailed diff
git diff {public-sha}...HEAD [-- packages/{package-dirname}/]
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.
- 2d ago First seen · 140 lines · 0 tokens per session scan A 9fb2dd6ff99f
generate-release-notes is a skill published in the GitHub repository phantom/phantom-connect-sdk (159 stars, last pushed 4mo ago), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 1,134 tokens. 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
git-workflow-and-versioning
Structures git workflow practices. Use when making any code change. Use when committing, branching, resolving conflicts, opening or reviewing a pull request (PR), pushing to a remote, or when you need to organize work across multiple parallel streams. Use when cutting a release, choosing a semantic version bump…
release
Cut a Symphony release by bumping the committed version, landing it, tagging the merged commit, and verifying the Burrito release workflow. Use when asked to release, tag, or retag Symphony.
release-notes
Draft concise release notes.
greptimedb-release
Runbook for publishing a new GreptimeDB version (tag + GitHub release + docs release-note PR) on the upstream GreptimeTeam/greptimedb repo. Use when asked to "release" / "publish" a GreptimeDB version (e.g. v1.1.0, v1.0.3).
refresh-arm-sdk-release
WORKFLOW SKILL — Prepares Azure.ResourceManager SDK refresh pull requests in azure-sdk-for-net. WHEN: "prepare sdk refresh", "refresh Azure.ResourceManager package", "update ARM SDK from autorest tag", "refresh changelog dependencies". INVOKES: git and GitHub pull request tools for branch, commit, push, and PR…
store-update
在 CCX Desktop 发布后下载 Store MSIX 并生成发布公告。用户提到 Store 上架、MSIX、从 GitHub Release 下载 store.msix、发布后同步 Windows Store、从 release 填写商店更新内容时必须使用此技能。该技能会下载最新 GitHub Release 的 amd64/arm64 MSIX,校验 sha256,从 Release body 生成 Store listing releaseNotes 预览,并输出手动上传指引。.