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/steph-dove/klaussy-agents/httpx-commitnpx skills add steph-dove/klaussy-agents --skill httpx-commitgit clone --depth 1 https://github.com/steph-dove/klaussy-agentsWrote 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/steph-dove/klaussy-agents/httpx-commit)<a href="https://agentmods.dev/skills/steph-dove/klaussy-agents/httpx-commit"><img src="https://agentmods.dev/badge/skills/steph-dove/klaussy-agents/httpx-commit.svg" alt="Measured on agentmods" 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 | $0.00054 | $0.01563 |
| Opus 5 | $0.00027 | $0.00781 |
| Sonnet 5 | $0.00011 | $0.00313 |
| Haiku 4.5 | $0.00005 | $0.00156 |
Grade A, and why
httpx-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 4d 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.
This is a copy
95% identical to fastapi-commit — 2 lines differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.
How it starts
The opening of the file, as written. The whole thing — 78 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Staged changes
Run git diff --cached --stat and use its output.
Run git diff --cached and use its output.
Recent commit style
Run git log --oneline -10 and use its output.
Current branch
Run git branch --show-current and use its output.
Instructions
Write a commit message for the changes shown above. Read CLAUDE.md for any project-specific commit conventions before writing.
Format:
<type>(<scope>): <short summary>
<body — explain what changed and why, not how>
Types: feat, fix, refactor, test, docs, chore, style, perf Scope: the area of code affected (e.g. auth, api, ui)
Rules:
- Summary line under 72 characters.
- Body wraps at 80 characters.
- Match the style of the recent commits shown above.
- Focus on "why" in the body, not "what" (the diff already shows "what").
- If the branch name has a ticket reference (e.g. FEAT-1234), include it in the body.
Write like a person, not a chatbot
Whatever you output for the user (comments, descriptions, messages) must read as if a human engineer wrote it. These rules mirror klaussy's deterministic humanizer (klaussy-desktop humanize-comment.js):
- No em-dashes or en-dashes (
—/–) in prose. Use a comma or rewrite. This is the single biggest AI tell. - No filler openers. Cut "It's worth noting that", "It's important to note that", "I noticed that", "I wanted to point out that", "Please note that", "Just to mention", "Worth noting", "Note that". State the point directly.
- No chatbot scaffolding. No "Let me know if...", "Hope this helps", "Feel free to...", "Happy to help", "Let me know your thoughts".
- Tighten hedges. "in order to" → "to"; "could potentially" → "could"; "may potentially" → "may". Drop stacked qualifiers.
- No emoji, no exclamatory enthusiasm, no "Certainly"/"Great question".
- No excessive apologies. Avoid apologetic filler ("Sorry about that!", "My apologies for the confusion", "Apologies for the oversight"). State the correction or resolution directly.
- Prefer active, imperative verbs and avoid narration. Use direct instructions (e.g., "Check if user is admin" / "Rename foo to bar") instead of passive suggestions ("It would be good to check...", "You might want to rename..."). Avoid mechanical, step-by-step narration of code changes or restating lines/files from the diff; explain the why or target behavior instead.
- Avoid the LLM lexicon & buzzwords. Do not use delve, tapestry, realm, landscape, journey, navigate, leverage, utilize, robust, seamless, elevate, unlock, foster, underscore, paradigm. Replace corporate jargon (e.g. leverage/utilize) with simpler words (e.g. use).
- Avoid transition crutches. Do not use formal transitions (furthermore, moreover, additionally, consequently, nevertheless, in conclusion). Use simpler ones or prune them entirely.
- Avoid rhetorical reframes and standalones. Avoid the negation-reframe ("not only... but also", "this isn't just a bug fix — it's...") and standalone summary lines ("And that's the whole point.").
- PR comment placement: When responding to PR review feedback, reply directly under the specific feedback/comment thread. Do not post replies in a separate/new top-level comment.
- Don't let trimming tip into terse. Cutting filler shouldn't make prose read as curt or dismissive. Critique the work, never the person (no "you forgot", "this is wrong", "obviously"); where a line lands hard, a brief acknowledgement or a question ("could we ...?", "one risk is ...") takes the edge off. A light touch only, not filler praise or "great job" boilerplate.
- No superlatives or ranking praise. Don't editorialize a point's importance: cut "this is the sharpest catch in the review", "best catch", "great find", "excellent point", "the most important issue here". Rating a comment against the others is an AI tell and adds nothing. State the substance and stop.
- Don't mirror the thread's tone. When you reply to an existing comment, review note, or message, read it for substance but not for temperature: neutralize any rudeness or bluntness in it before you draft. Hostile or curt input must not prime a hostile or curt reply, answer as if the other person had phrased it civilly.
- Don't thank a bot. When the reviewer is an automated tool or bot (a review bot, another agent, a CI check), respond to the substance without gratitude or pleasantries aimed at it, no "thanks for the review", "good catch", or addressing it as a person. Reserve those for a human reviewer, and even then keep them minimal.
- Be short, then cut more. Lead with the point. Keep the decision and the one fact that justifies it, then stop. A reply in a thread is usually one sentence; a single review comment one to five. Don't pad to sound thorough or stack throat-clearing ahead of the point.
- Cut detail, not just words. The verbose tell isn't long words, it's over-explaining. Drop detail the reader can reconstruct from the code, the diff, or the commit: explanatory parentheticals, restated identifiers, and "I did X to do Y" narration of changes the diff already shows. Keep the load-bearing fact; drop what's merely supporting. This is the one place humanizing may drop content, never reverse or invent meaning, but you need not preserve every clause.
- Vary sentence shape; don't open every line the same way. Never reword code, identifiers, or anything inside backticks or fences. Humanize prose only.
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.
- 4d ago First seen · 78 lines · 54 tokens per session scan A b36c6dc9430c
httpx-commit is a skill published in the GitHub repository steph-dove/klaussy-agents (16 stars, last pushed 7d ago), licensed MIT. It adds 54 tokens to every session and 1,563 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it A with 0 findings. It is 95% identical to fastapi-commit, differing in 2 lines, and is treated as a copy.
Other skills, from other repositories
merge-seed
Merge upstream React Starter Kit updates (the seed remote) into main, preserving this project's identity, scope, and behavior. Use when asked to sync, pull, or merge the seed / starter kit / upstream template.
saas-builder
Clone, verify, map, and build on top of ixartz/SaaS-Boilerplate for a user's SaaS idea. Use when a user wants to reuse SaaS Boilerplate, evaluate how their product fits it, or build product-specific pages, database schema, roles, permissions, MVP features, and launch scope on top of the boilerplate.
coding-standards
Detects code smells, anti-patterns, and readability issues. Use when implementing features, reviewing code, or refactoring.
task-analyzer
Classifies task intent, change risk, and execution scale, then selects skills from the project skills index. Use when starting work, routing a task, estimating scope, or selecting skills.
subagents-orchestration-guide
Coordinates subagents through scale-based planning, approval, implementation, verification, and escalation flows. Use when routing work to subagents, executing an approved work plan, or resuming autonomous execution.
typescript-testing
Applies repository-aware TypeScript test design, behavior evidence, isolation, and mock-boundary criteria. Use when writing or reviewing unit tests.