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/abdullahkhawer/devops-skills/commit-codenpx skills add abdullahkhawer/devops-skills --skill commit-codegit clone --depth 1 https://github.com/abdullahkhawer/devops-skillsWhat 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.00018 | $0.00758 |
| Opus 5 | $0.00009 | $0.00379 |
| Sonnet 5 | $0.00004 | $0.00152 |
| Haiku 4.5 | $0.00002 | $0.00076 |
Grade A, and why
commit-code 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 — 114 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Commit Code Skill
Run this skill when asked to commit code changes, create a commit message, or push changes to a new branch.
Step 1 — Collect input
Ask the user the following question:
Kindly let me know:
1. Branch Name: What should I name the new branch? (name of the branch)
If the user has already provided the answer upfront, skip the question and use the provided value.
Step 2 — Create a new branch
git checkout -b <BRANCH_NAME>
Step 3 — Run pre-commit checks (if .pre-commit-config.yaml exists)
pre-commit run -a
If the command fails, try again only one more time. If it fails again, report the output to the user and stop. Do not continue until the user resolves any failures.
Step 4 — Run Terraform formatting (if Terraform files exist)
terraform fmt -recursive
Step 5 — Stage all changes, analyze them and commit
git add .
Before proceeding, list the staged files and check for potentially sensitive files (e.g. .env, *.pem, *.key, *credentials*, *secret*, *token*, *password*):
git diff --cached --name-only
If any staged file matches a sensitive pattern, pause and ask the user to confirm whether it should be included in the commit. Do not proceed until confirmed.
And then analyze the code changes in each staged file with the following command:
git diff --cached -- <FILE_PATH>
Then based on all the code changes, determine the appropriate conventional commit type, compose a single one-liner commit message, and commit the changes with the following command:
git commit -m "<TYPE>: <COMMIT_MESSAGE>"
Commit message rules
- Single line only — no multi-line messages.
- Must be descriptive and mention all relevant changes.
- First letter of
<COMMIT_MESSAGE>must be capitalized. - Reference: https://www.conventionalcommits.org/en/v1.0.0/
Conventional commit types
| Type | When to use |
|---|---|
feat |
A new feature |
fix |
A bug fix |
docs |
Documentation only changes |
style |
Formatting changes that do not affect code meaning |
refactor |
Code change that neither fixes a bug nor adds a feature |
perf |
Code change that improves performance |
test |
Adding or correcting tests |
chore |
Build process or auxiliary tool changes |
ci |
Changes to CI configuration files and scripts |
build |
Changes that affect the build system or external dependencies |
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 · 114 lines · 18 tokens per session scan A 886f34f02d86
commit-code is a skill published in the GitHub repository abdullahkhawer/devops-skills (7 stars, last pushed 3mo ago), licensed Apache-2.0. It adds 18 tokens to every session and 758 once invoked, about $0.0001 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-31.
Other skills, from other repositories
docs-manage
Manage the Grounded Docs MCP Server documentation index. Covers scraping and indexing documentation from URLs or local files, refreshing existing indexes with changed content, and removing libraries from the index. Use when you need to add, update, or delete indexed documentation.
docs-search
Search and query the Grounded Docs MCP Server documentation index. Covers listing indexed libraries, searching documentation content, and resolving library versions. Use when you need to look up API references, find code examples, or check which documentation is available in the local index.
fetch-url
Fetch a single URL and convert its content to Markdown. Use when you need to read a web page, documentation page, or API reference without indexing it. The content is returned as plain Markdown text on stdout.
lore
SpecStory Lore - mine your SpecStory coding histories (any agent - Claude Code, Codex, Cursor, Gemini, and more) into a persistent corpus, surface your reproducible workflows with corroborated evidence, and interactively forge the chosen ones into skills installed across all your agent harnesses. Use when the user…
workthreads
SpecStory Workthreads - a weekly work-thread rollup across a team's repos from SpecStory coding histories (any agent - Claude Code, Codex, Cursor, Gemini, and more). It groups the window's sessions into threads of work per project and labels each new / open / recently closed, so a lead sees what shipped, what is still…
live-exercise
Use whenever any UI-bearing work touches a running instance — building or fixing a feature, ship-gating, auditing, OR debugging visible bugs (flaky behavior, intermittent rendering, "sometimes does X" reports, hover/focus/animation glitches, layout overflow). Adaptive depth from tactical fix-loop to ship-gate audit.…