Bifrost is an AI gateway that gives applications one OpenAI-compatible API for accessing models from more than 23 providers. It is used to route model requests, handle provider failover and load balancing, and apply features such as caching, guardrails, and MCP gateway support.
Borrowing it
Nothing to install: this file belongs to maximhq/bifrost. 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/maximhq/bifrost/dev/.claude/skills/split-commit-into-stack/SKILL.mdgit clone --depth 1 https://github.com/maximhq/bifrostWrote 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/maximhq/bifrost/split-commit-into-stack)<a href="https://agentmods.dev/skills/maximhq/bifrost/split-commit-into-stack"><img src="https://agentmods.dev/badge/skills/maximhq/bifrost/split-commit-into-stack/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/maximhq/bifrost/split-commit-into-stack"><img src="https://agentmods.dev/badge/skills/maximhq/bifrost/split-commit-into-stack.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector warn
SkillSpector: 2 findings, up to high
These are SkillSpector’s own severities. On a checked sample its high-severity flags on skills were ~96% false positives — a documented command, a public API, a “never do X” rule — so we show them as a caution to read, not a verdict. Why →
- high Tool Misuse · line 158 Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).Fix: Validate all tool parameters against an allowlist. Reject dangerous parameter values (shell=True, --force, -rf /) and use safe defaults.
- high Tool Misuse · line 207 Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).Fix: Validate all tool parameters against an allowlist. Reject dangerous parameter values (shell=True, --force, -rf /) and use safe defaults.
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.00096 | $0.03693 |
| Opus 5.5 | $0.00038 | $0.01477 |
| Sonnet 5.5 | $0.00019 | $0.00739 |
| Haiku 4.5 | $0.00010 | $0.00369 |
Grade A, and why
split-commit-into-stack 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 1mo 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 — 299 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Split Commit Into Stack
Turn one large commit into a stack where each PR is a coherent story that compiles and passes on its own. The work is mostly analysis: the mechanics are five commands, but choosing the cut and proving it holds is where the value is.
Most of the cost of a big PR is that a reviewer cannot tell which changes belong to which decision. A split earns its keep when it separates decisions, not when it merely reduces line count.
Step 0: Measure before proposing anything
Measure the whole branch against its base, not the tip against its parent: a branch that
already holds several commits is split as one diff, and HEAD~1 would silently measure,
inspect and later reset only the last of them.
base="$(git merge-base "$(gt parent)" HEAD)" # the branch's base, whatever the commit count
git --no-pager log --oneline "$base"..HEAD # several commits that already match the concerns: see Graphite notes
git --no-pager diff --numstat "$base" HEAD | awk '{i+=$1;d+=$2; printf "+%-6d -%-6d %s\n",$1,$2,$3} END {printf "TOTAL +%d -%d\n",i,d}'
git --no-pager diff --name-status "$base" HEAD
Every later step reads "$base" from this shell, so run them in the same one or set it
again.
Two numbers change the conversation before any splitting is discussed:
- Production vs test insertions. A 3,500-line diff where 1,000 lines are one new test file is not a 3,500-line review. Report the production-only figure; sometimes it dissolves the problem and no split is warranted.
- Per-concern totals. Group files by concern (below) and total each. If one group is
85% of the diff and is atomic, splitting the remaining 15% is the entire available win
- say so plainly rather than proposing a heroic three-way split.
- Whether one file serves both concerns. Two or three such files is normal and Step 4 usually dissolves them; a dozen means the concerns are not actually separable and the honest answer is to leave the commit whole.
Use --name-status and not just --numstat: added (A) and deleted (D) files change
what the git add commands must look like, and a deletion left in the wrong PR breaks
the build in a way that is annoying to diagnose later.
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.
- 1mo ago First seen · 299 lines · 96 tokens per session scan A 81cdbe0a315e
split-commit-into-stack is a skill published in the GitHub repository maximhq/bifrost (8,898 stars, last pushed yesterday), licensed Apache-2.0. It adds 96 tokens to every session and 3,693 once invoked, about $0.0004 per session on Opus 5.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-09-02.
Other skills, from other repositories
validate-release-green
Run or inspect the local Release-Green observer for an exact base or combined PR candidate, separating hard failures, advisory drift and incomplete evidence. Use for maintainer preflight; full CI acceptance remains a separate requirement.
maintainer-ops
Use for vLLM Semantic Router issue intake, PR decisions, releases, and reviewed GitHub mutations performed on behalf of maintainers.
release-notes
Create release notes for a new version tag. Gathers all commits, PRs, issues fixed, and breaking changes since a previous release. Creates the release notes markdown file, tags the repo, and pushes. Asks the user to confirm the base version to diff against.
create-milestone
Create a GitHub milestone for an upcoming release. Suggests the next version based on the latest release, gathers all merged PRs and closed issues since that release, presents a draft with two tables (Issues and PRs) for user approval, then creates the milestone and assigns all approved items.
thumbgate-protect
Inspect this repo's branch and release governance (protected branches, release rules, protected-file globs) and, only when the user explicitly approves, grant a scoped, time-limited exception so a protected-file edit or publish can proceed under audit. Reads posture via the getbranchgovernance MCP tool and records a…
release-notes
Generate release notes from git history and CHANGELOG. Formats for GitHub Release, Slack, or email. Use before tagging a release.