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 commands/kaelsensei/magicaibuilder/add-commit-pushgit clone --depth 1 https://github.com/KaelSensei/MagicAIBuilderWhat 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.00990 |
| Opus 5 | $0.00000 | $0.00495 |
| Sonnet 5 | $0.00000 | $0.00198 |
| Haiku 4.5 | $0.00000 | $0.00099 |
Grade A, and why
add-commit-push 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 — 149 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Git Command – Stage, Commit, and Push Current Changes
When /git [message] is invoked, immediately execute the following steps to stage changes, create a
conventional commit, and push to the current branch.
Step 1: Load Project Context & Follow All Rules
- Assume the project root as the working directory
- Load and strictly follow ALL Cursor rules from
.cursor/rules/*.mdc:security.mdc- Security requirementsdocumentation.mdc- Documentation update requirementsversion-management.mdc- Git workflow and commit conventionsgeneral-principles.mdc- Project philosophy (keep it simple)
- Read relevant documentation if present:
README.md- Project progress / changelog docs (e.g.,
PROGRESS.md,CHANGELOG.md)
Step 2: Safety Checks (Mandatory)
-
Check current branch:
git branch --show-current -
Refuse to commit directly to protected branches:
- If branch is
mainormaster, stop and ask the user to create a feature branch first.
- If branch is
-
Check working tree:
git status -
If there is nothing to commit, report that and stop.
Step 3: Run Project Checks (Lint / Format / Tests)
Before committing, run the project's standard checks if they exist:
-
Detect common check commands by looking for scripts and config files:
- Node:
package.jsonscripts likecheck,lint,format:check,test - Python:
pyproject.toml,pytest.ini,ruff.toml - Go:
go test ./...,golangci-lint run - Rust:
cargo test,cargo fmt --check,cargo clippy
- Node:
-
Run the most relevant, fastest checks first (format check + lint).
-
If checks fail:
- Stop and report the failures
- Fix if safe and straightforward
- Re-run the checks until they pass
Note: if the repo has a pre-commit hook, it will also run automatically when committing.
Step 3.5: SonarCloud Quality Gate (Mandatory)
After the code is ready and the tests pass, run the Sonar scan and verify there are 0 open issues.
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 · 149 lines · 0 tokens per session scan A ec6680522191
add-commit-push is a command published in the GitHub repository KaelSensei/MagicAIBuilder (2 stars, last pushed 3d ago), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 990 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-31.
Other commands, from other repositories
spec-plan
Step 4 of the Vibe-Spec workflow. Generate the high-level plan file for every phase in the V2 phase index, each with a scope + status header, so the user has a complete set of plan files to work from.
spec-phases
Step 3 of the Vibe-Spec workflow. Break the V1 spec into sequential, self-contained phases and append a phase index, producing the final V2 spec.
spec-secrets
Audit a Vibe-Spec app for secrets leaking to the browser. A locked-down, redacting command — a local script reads .env and the built bundle, and Claude only ever sees variable NAMES and pass/fail verdicts. Secret values never enter the model's context.
spec-doctor
Read-only environment health check for the Vibe-Spec stack. Detects your OS and reports which prerequisite tools (Git, Node, pnpm, Docker, uv) are installed, their versions, and what each is needed for. Installs nothing.
spec-implement
Step 5 of the Vibe-Spec workflow. Promote a phase plan to detailed, implement it following the vibe-spec references, then update the docs so the spec reflects reality.
spec-refine
Step 2 of the Vibe-Spec workflow. Critique the V0 spec, fill gaps with clarifying questions, then promote it to a V1 spec that maps each piece of functionality to concrete stack tools using the vibe-spec references.