Borrowing it
Nothing to install: this file belongs to receptron/mulmoclaude. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/receptron/mulmoclaude/main/.claude/commands/precommit.mdgit clone --depth 1 https://github.com/receptron/mulmoclaudeWrote 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/commands/receptron/mulmoclaude/precommit)<a href="https://agentmods.dev/commands/receptron/mulmoclaude/precommit"><img src="https://agentmods.dev/badge/commands/receptron/mulmoclaude/precommit/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/commands/receptron/mulmoclaude/precommit"><img src="https://agentmods.dev/badge/commands/receptron/mulmoclaude/precommit.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.00000 | $0.02379 |
| Opus 5.5 | $0.00000 | $0.00952 |
| Sonnet 5.5 | $0.00000 | $0.00476 |
| Haiku 4.5 | $0.00000 | $0.00238 |
Grade C, and why
precommit scanned grade C with 1 finding 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 1mo 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.
Recursive force deletehighDestructive command
rm -rf with a variable or a broad path is one typo away from removing the wrong tree.
- [ ] No shell-specific syntax in npm scripts (`rm -rf`, `cp`). How it starts
The opening of the file, as written. The whole thing — 132 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Pre-Commit Review
Review ALL staged and unstaged changes against the project's coding standards before committing. This checklist covers everything the mechanical hook (yarn format/lint/typecheck/build/test) cannot catch.
Run git diff --stat and git diff first, then check every item below against the actual changes. Report violations with file:line references. If everything passes, say "All checks passed — ready to commit."
1. DRY — No Duplication & Small Functions
- No function or 3+ line block is copy-pasted across files. If the same logic appears twice, it MUST be extracted to a shared helper under
server/utils/orsrc/utils/. - Utility functions are grouped by concern: file ops →
utils/files/, dates →utils/date.ts, strings →utils/slug.ts, JSON →utils/json.ts, types →utils/types.ts, spawn →utils/spawn.ts, network →utils/fetch.ts, markdown →utils/markdown.ts, IDs →utils/id.ts, errors →utils/errors.ts. - No new
makeId(),isRecord(),formatSpawnFailure(),isValidSlug(),extractJsonObject(), or similar that already exists inserver/utils/. - Functions are as small as possible. Each function does one thing. If a function body exceeds ~20 lines, look for extractable sub-steps. Before writing a new helper, grep the codebase — it may already exist.
- Every new function MUST have a corresponding test. No exceptions. If it's exported, it has a test file. If it's private but contains non-trivial logic, extract it as a testable exported pure function.
2. Tests
- Every new exported function has at least one unit test (happy path + error case).
- Every new API endpoint has a route-level test in
test/routes/. - Every
.vuecomponent change that affects template bindings, event handlers, or reactive state has an E2E test or extends an existing one. - Test files mirror source layout:
server/utils/date.ts→test/utils/test_date.ts. - Tests use
node:test+node:assert/strict. External APIs are mocked — tests run without API keys. - Test coverage includes: happy path, edge cases, boundary values, empty/null inputs, error cases.
- No test relies on hardcoded POSIX paths — use
path.join(path.sep, ...)oros.tmpdir().
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.
- 1mo ago First seen · 132 lines · 0 tokens per session scan C e7cb463a24f1
precommit is a command published in the GitHub repository receptron/mulmoclaude (386 stars, last pushed 2d ago), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 2,379 tokens. A static security scan graded it C with 1 finding (recursive force delete). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other commands, from other repositories
commit-push-pr
An automated Git workflow that checks a project, synchronizes documentation, commits changes, and can create or merge a GitHub pull request. A pull request is a request for teammates to review and add changes to a shared codebase.
validate-pr-description
Use when validating a PR title and description for conventional commit format, issue linking keywords, and template compliance before submission.
quick-commit
A quick Git command for committing and pushing a small code change. Git is the tool that records code versions and sends them to a shared repository.
simplify-transform
Apply verified simplifications with user approval. Part of simplify- family.
fix-tests-execute
Phase 2 of fixing-tests: Fix Execution - investigate, classify, fix, verify, and commit each work item.
verify
Run verification commands and confirm output before making success claims. Use before committing, creating PRs, or claiming work is complete. Evidence before assertions, ALWAYS.