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/wardawgmalvicious/agent-config/commitnpx skills add wardawgmalvicious/agent-config --skill commitgit clone --depth 1 https://github.com/wardawgmalvicious/agent-configWhat 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.00142 | $0.00962 |
| Opus 5 | $0.00071 | $0.00481 |
| Sonnet 5 | $0.00028 | $0.00192 |
| Haiku 4.5 | $0.00014 | $0.00096 |
Grade A, and why
commit 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 — 77 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Commit workflow
Turn the current working-tree changes into one or more well-formed commits. Committing only — pushing, amending, rebasing, and tagging happen only when explicitly requested, never as follow-through.
Survey first
git status --short— full picture of modified, renamed, untracked.git log --oneline -10— calibrate message style against this repo's actual history, not assumptions.- Read the diffs (
git diff,git diff --stat, plus untracked files) well enough to explain why each change exists, not just what it touches. Never commit content you haven't looked at.
Splitting into commits
- One logical unit per commit. A rename, a new feature, and a docs catch-up are three commits even when they touch the same file. Test: could each commit's subject line be written without "and"?
- Every commit must be self-consistent. No commit may reference a name, file, or skill that doesn't exist yet at that point in history, and none may leave the repo in a broken intermediate state. Order accordingly (e.g. a rename lands before anything citing the new name).
- When one file straddles commits, interactive
git add -pis unavailable in this harness — instead, step the file through intermediate states: edit it down to the first commit's portion, commit, restore the next portion, commit again. Verify the final state matches the intended end state exactly. - Stage explicit paths only. No
git add -A/git add .— they silently sweep in untracked or unrelated files. - Renames go through
git mv(or are staged so git detects the rename) so history follows the file.
Messages
- Subject:
<type>: <imperative summary>— types in this order of likelihood:docs,feat,refactor,fix,chore,test. Lowercase after the colon, no trailing period. - Body: explain motivation and non-obvious decisions — why the change exists, what prompted it, provenance ("derived from X, now deleted"), and any ordering or scoping rationale. Never restate the diff. Wrap near 72 columns. Trivial single-file changes may skip the body.
- Multi-line messages from PowerShell: single-quoted here-string
(
@'...'@, closing delimiter at column 0). From Bash: heredoc.
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 · 77 lines · 142 tokens per session scan A fd5f8dae6c44
commit is a skill published in the GitHub repository wardawgmalvicious/agent-config (2 stars, last pushed 2d ago), licensed MIT. It adds 142 tokens to every session and 962 once invoked, about $0.0007 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
git-commit-helper
Generate conventional commit messages automatically. Use when user runs git commit, stages changes, or asks for commit message help. Analyzes git diff to create clear, descriptive conventional commit messages. Triggers on git commit, staged changes, commit message requests.
lesson-close
Закрыть текущее занятие. Финализирует lesson/YYYY-MM-DD.md (frontmatter status, метаданные времени, длительность), делает commit + push в репо DS-personal-guide. Триггерит замкнутый контур доставки — после push → GitHub webhook → bot oauthserver.py:/webhook/github/workbook → synconeusertodt → ЦД обновляется в Neon.…
commit
ALWAYS use this skill when committing code changes — never commit directly without it. Creates commits following Sentry conventions with proper conventional commit format and issue references. Trigger on any commit, git commit, save changes, or commit message task.
git-pr-workflows-git-workflow
Orchestrate a comprehensive git workflow from code review through PR creation, leveraging specialized agents for quality assurance, testing, and deployment readiness. This workflow implements modern g.
git-hooks-automation
Master Git hooks setup with Husky, lint-staged, pre-commit framework, and commitlint. Automate code quality gates, formatting, linting, and commit message enforcement before code reaches CI.
git-workflow-and-versioning
Structures git workflow practices. Use when making any code change. Use when committing, branching, resolving conflicts, opening or reviewing a pull request (PR), pushing to a remote, or when you need to organize work across multiple parallel streams. Use when cutting a release, choosing a semantic version bump…