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 skills add helderberto/agent-skills --skill to-stackgit clone --depth 1 https://github.com/helderberto/agent-skillsWrote 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/helderberto/agent-skills/to-stack)<a href="https://agentmods.dev/skills/helderberto/agent-skills/to-stack"><img src="https://agentmods.dev/badge/skills/helderberto/agent-skills/to-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/helderberto/agent-skills/to-stack"><img src="https://agentmods.dev/badge/skills/helderberto/agent-skills/to-stack.svg" alt="Reviewed on agentmods" width="80" height="20"></a>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.00044 | $0.01791 |
| Opus 5.5 | $0.00018 | $0.00716 |
| Sonnet 5.5 | $0.00009 | $0.00358 |
| Haiku 4.5 | $0.00004 | $0.00179 |
Grade A, and why
to-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 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 — 93 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Split
Turn one large change into a stack: PR 1 on the base branch, each later PR on the one below it. Reviewers read one concern at a time, and the top of the stack is byte-for-byte the tree you already tested.
Arguments: $ARGUMENTS
- A PR number or URL, or a branch. None → the current branch and its PR.
--each— land each PR on the base in order, each with its own version bump and CHANGELOG section. Default: merge from the top down into PR 1, which lands as one squash and one release.
Workflow
-
Resolve.
- Dirty tree → stop and ask to commit or stash.
- A PR →
gh pr view <PR> --json headRefName,baseRefName, thengh pr checkout <PR>. A branch → check it out. Its head is<tip>; its base is the PR'sbaseRefName, else the default branch. git fetch origin <base>, then diff against the remote base, since a stale local base inflates the diff:git diff --stat origin/<base>...<tip>andgit log --oneline origin/<base>..<tip>.- Tip conflicts with the base, or the base already released the planned version → merge the base in and bump first. A collision belongs to the whole change, not to one layer.
- Under ~600 changed lines without lockfiles → say a split isn't worth it, and stop unless the user insists.
Done when the scope is stated: "Splitting
feat/x(#42) vsmain: 49 files, +3432". -
Map. Record what every changed file needs: its imports, and for each test case the mocks, globals, helpers and options it touches. Group the changes into concerns. For shared files (manifest, entry barrel, types index, core module, README, CHANGELOG), assign each changed line to a concern. Done when every changed line has an owner. Ownership rules: references/layering.md.
-
Plan. Order the concerns so each layer depends only on layers below it: manifest and config first, then the core, then features, then deprecated or compatibility code, so a future major deletes one layer. Each layer is tight:
- one concern, under ~600 changed lines without lockfiles
- green on its own
- nothing in it waits on a later layer to be used: move a reader with its writer
What ships with it
1 file beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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 · 93 lines · 44 tokens per session scan A 0e162fec750c
to-stack is a skill published in the GitHub repository helderberto/agent-skills (17 stars, last pushed yesterday), licensed MIT. It adds 44 tokens to every session and 1,791 once invoked, about $0.0002 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-10-21.
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, splitting uncommitted work in a messy working tree into clean atomic commits, opening or reviewing a pull request (PR), pushing to a remote, or when you need to organize work across multiple…
git-workflow
Trunk-based development with atomic commits, clean history, and meaningful commit messages. Every commit should be deployable.
git-workflow-and-versioning
Structures git workflow practices. Use when making any code change. Use when committing, branching, resolving conflicts, or when you need to organize work across multiple parallel streams.
shipping-and-launch
Prepares production launches. Use when preparing to deploy to production. Use when you need a pre-launch checklist, when setting up monitoring, when planning a staged rollout, or when you need a rollback strategy.
ship
Stage, commit, and push every current Git repository change in one operation. Use when the user says /ship, “ship it”, “commit and push everything”, “stage everything”, “push everything”, or otherwise explicitly authorizes committing all current worktree changes without splitting or reviewing them individually.
chinese-commit-conventions
A Chinese-language guide to Conventional Commits, a format for writing consistent Git commit messages, plus related changelog, commit-checking, and commit-helper configuration.