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/superplanehq/superplane/superplane-changelognpx skills add superplanehq/superplane --skill superplane-changeloggit clone --depth 1 https://github.com/superplanehq/superplaneWhat 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.00050 | $0.02257 |
| Opus 5 | $0.00025 | $0.01128 |
| Sonnet 5 | $0.00010 | $0.00451 |
| Haiku 4.5 | $0.00005 | $0.00226 |
Grade A, and why
superplane-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 yesterday.
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 — 110 lines — stays where its author put it; the contents beside it link to each section on GitHub.
SuperPlane Changelog
Use this skill when the user wants a changelog of what was merged to main over a given time range (e.g. "since Monday", "last 5 days", "since last Friday"). Produce a single markdown file in tmp/ with a consistent structure and tone.
1. Determine time range
- User may say: "since Monday", "last 5 days", "since last Friday", "Feb 3 to now", "since v0.6.0", or a specific date.
- Compute: Start and end of the window. Use date and time (not just date) when the start is a version tag so that same-day commits before the tag are excluded.
- Date-only ranges (e.g. "since Monday", "Feb 3 to now"): Start = date at midnight, end = today. For "last 5 days" use Monday to Friday; for "since last Friday" use that Friday through today.
- Version-tag ranges (e.g. "since v0.6.0"): Start = exact commit timestamp of the tag (e.g.
git log -1 --format="%cI" v0.6.0for ISO 8601). End = now or a chosen end date. This ensures commits that landed the same calendar day but before the tag are not included.
- Git: Use
git log --since="<start>" --format="%h %ad %s" mainwhere<start>is:- For date-only:
YYYY-MM-DD(e.g.2026-02-03). Use--date=shortin the format. - For version-tag: the tag's commit timestamp in ISO 8601 (e.g.
2026-02-01T15:30:00+00:00). Use--date=isoif you need to compare times. Only include in the changelog items whose commit/merge date is strictly after the start when using a tag.
- For date-only:
2. Classify what landed
From commit messages and dates:
- Exclude
chore:commits (mandatory). Do not list or derive any changelog entry from commits whose subject starts withchore:orchore(...):. This applies to every section: do not add an improvement, integration, component, or any other bullet based on a chore commit, even if the change seems user-facing (e.g. "Allow running multiple instances" is still a chore and must be omitted). When classifying what landed, skip chore commits entirely; only usefeat:,fix:,docs:(for user-facing doc changes), and similar non-chore prefixes as sources for changelog entries. - New integrations: Integrations that were fully added in the window (base integration registered + first components). Example: SendGrid, Jira. Do not count standalone components (e.g. SSH is a component under
pkg/components/ssh, not an integration). - New components and triggers: Only components/triggers that first appeared in the time window. If an integration already existed, list only the new component(s) (e.g. GitHub: Get Release). If the integration is new, list all its components and triggers. Use commit timestamps (date and time) to exclude anything that landed before the start of the window (e.g. when the window is "since v0.6.0", exclude commits with timestamp on or before the tag's commit time, so same-day commits before the tag are excluded).
- Improvements: User-facing product changes from non-chore commits only (e.g. RBAC, Secrets, integrations UX). Exclude internal/technical items (e.g. "Component/Trigger Cleanup()", "listing integration resources with additional parameters", Cursor skills). Describe each improvement in user-oriented terms: what the user can do, what problem it solves, or what benefit they get (e.g. "Define roles and permissions and control what each user can do" rather than "Permission guard in the UI").
- Security: Vulnerability fixes and security-related changes from the same commit range. Look for commits that mention "security", "SSRF", "CVE", "vulnerability", "auth", "injection", "XSS", "sanitiz", etc. Include a dedicated Security section whenever at least one such fix is present. Do not list a security fix if it only affects a component or integration that was introduced in this changelog window.
- Bug fixes: Fixes and reliability improvements from the same commit range (excluding security fixes, which go under Security). Keep in "Bug Fixes" even if somewhat technical. Do not list a fix if it only affects a component or integration that was introduced in this changelog window (e.g. "fix: AWS ECR timestamp" when ECR was added in the same window).
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.
- yesterday First seen · 110 lines · 50 tokens per session scan A 80f0b2f7dfa8
superplane-changelog is a skill published in the GitHub repository superplanehq/superplane (5,633 stars, last pushed yesterday), licensed Apache-2.0. It adds 50 tokens to every session and 2,257 once invoked, about $0.0003 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
iterate-pr
Iterate on a PR until CI passes. Optionally merge or merge and publish a release of the repo. Automates the feedback-fix-push-wait cycle.
qa-test-planner
Generate comprehensive test plans, manual test cases, regression test suites, and bug reports for QA engineers. Includes Figma MCP integration for design validation.
database-schema-designer
Design robust, scalable database schemas for SQL and NoSQL databases. Provides normalization guidelines, indexing strategies, migration patterns, constraint design, and performance optimization. Ensures data integrity, query performance, and maintainable data models.
gen-relationship
Create and refine schema-backed Meshery relationship definitions (models//relationships/.json). Use for "add a relationship", "fix this relationship JSON", classifying kind/type/subType, or reviewing selectors and mutatorRef/mutatedRef patches between model components.
gepetto
Creates detailed, sectionized implementation plans through research, stakeholder interviews, and multi-LLM review. Use when planning features that need thorough pre-implementation analysis.
gnhf
Use when the user asks to run GNHF, says they are going to sleep or leaving and wants an agent-managed coding run, asks to supervise, steer, or review an active GNHF run, or gives feedback on GNHF results.