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 skills add jrjsmrtn/project-orchestration-skills --skill setup-git-hooksgit clone --depth 1 https://github.com/jrjsmrtn/project-orchestration-skillsWrote 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/jrjsmrtn/project-orchestration-skills/setup-git-hooks)<a href="https://agentmods.dev/skills/jrjsmrtn/project-orchestration-skills/setup-git-hooks"><img src="https://agentmods.dev/badge/skills/jrjsmrtn/project-orchestration-skills/setup-git-hooks/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/skills/jrjsmrtn/project-orchestration-skills/setup-git-hooks"><img src="https://agentmods.dev/badge/skills/jrjsmrtn/project-orchestration-skills/setup-git-hooks.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector warn
SkillSpector: 7 findings, up to high
These are SkillSpector’s own severities. On a checked sample its high-severity flags on skills were ~96% false positives — a documented command, a public API, a “never do X” rule — so we show them as a caution to read, not a verdict. Why →
- high Privilege Escalation · line 226 Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.Fix: Remove references to credential paths. Use environment variables or secrets managers. For docs, use placeholder paths (e.g., /path/to/config). Never load .env or token files in production code paths.
- high Privilege Escalation · line 234 Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.Fix: Remove references to credential paths. Use environment variables or secrets managers. For docs, use placeholder paths (e.g., /path/to/config). Never load .env or token files in production code paths.
- high Tool Misuse · line 799 Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).Fix: Validate all tool parameters against an allowlist. Reject dangerous parameter values (shell=True, --force, -rf /) and use safe defaults.
- high Tool Misuse · line 799 Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).Fix: Validate all tool parameters against an allowlist. Reject dangerous parameter values (shell=True, --force, -rf /) and use safe defaults.
- high Tool Misuse · line 876 Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).Fix: Validate all tool parameters against an allowlist. Reject dangerous parameter values (shell=True, --force, -rf /) and use safe defaults.
- high Tool Misuse · line 875 Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).Fix: Validate all tool parameters against an allowlist. Reject dangerous parameter values (shell=True, --force, -rf /) and use safe defaults.
- high Privilege Escalation · line 233 Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.Fix: Remove references to credential paths. Use environment variables or secrets managers. For docs, use placeholder paths (e.g., /path/to/config). Never load .env or token files in production code paths.
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.00062 | $0.07990 |
| Opus 5 | $0.00031 | $0.03995 |
| Sonnet 5 | $0.00012 | $0.01598 |
| Haiku 4.5 | $0.00006 | $0.00799 |
Grade A, and why
setup-git-hooks 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 9d 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 — 891 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Setup Git Hooks
Configure two-stage git hooks — fast checks on commit, thorough checks on push — using either pre-commit or lefthook as the hook manager.
When to Use
- After running
bootstrap-projectandsetup-adrsskills - When adding quality gates to an existing project
- When standardizing quality automation across projects
Required Inputs
- Technology stack (Elixir, Python, TypeScript, etc.)
- Quality tools preference (can use defaults for each ecosystem)
- Multi-remote strategy (if using private + public remotes)
Two-Stage Strategy
Stage 1: Pre-commit (Fast, <30 seconds)
- File hygiene (whitespace, line endings, merge conflicts)
- Secret detection (critical security gate)
- Code formatting check
Stage 2: Pre-push (Thorough, <3 minutes)
- Linting with strict rules
- Type checking
- Security audit (dependencies)
- Fast tests (exclude slow/integration)
Workflow
Step 0: Create Quality Configuration Reference
Before configuring tools, create the single source of truth: docs/reference/quality-configuration.md
# Quality Configuration
Single source of truth for all quality settings.
## Toolchain Versions
Three roles, and conflating them ships defects. Record all three even when two coincide today.
| Role | Version | Declared in | Meaning |
|------|---------|-------------|---------|
| **Floor** | [oldest supported] | [manifest] | the oldest a *consumer* needs — a compatibility claim |
| **Build** | [current] | [CI config] | what CI and releases are actually built with |
| **Inherited** | [if any] | [sub-module manifest] | a floor a dependency forces on you, not one you chose |
Per ecosystem, the floor lives in:
| Ecosystem | Floor | Build version |
|-----------|-------|---------------|
| Go | `go` directive in `go.mod` | `go-version:` in the workflow |
| Rust | `rust-version` (MSRV) in `Cargo.toml` | toolchain file / CI |
| Python | `requires-python` in `pyproject.toml` | `python-version:` in CI |
| Node | `engines.node` in `package.json` | `node-version:` in CI |
| Elixir | `elixir` requirement in `mix.exs` | CI matrix |
**Build with the current version, never the floor.** The floor states what a consumer needs;
building at it means building against the least-patched runtime. Released artifacts embed that
runtime — and if you publish an SBOM, they *record* it — so building at the floor can publish a
known-vulnerable runtime and document the fact in the accompanying BOM.
**Prove the floor separately.** One CI job builds and tests at exactly the declared floor, so the
compatibility claim is verified rather than aspirational. Do **not** run vulnerability scanning
there: an old toolchain has old advisories by definition, which is a reason not to *ship* it, not a
reason to stop supporting it.
**Record the per-call-site intent.** List every place a toolchain version is selected and why it
reads what it reads. A partial fix is the common failure — updating the two obvious workflows and
missing the scheduled scan.
**Record the maintenance obligation.** Pin the build *line* rather than tracking `latest`, so a new
major release cannot change what you ship without a commit; patch releases within the line still
arrive, which is how runtime security fixes reach you. Nothing automates the major bump — dependency
bots do not manage CI toolchain versions — so name it as a periodic, deliberate act. Its failure
mode is silent.
## Formatting Standards
| Setting | Value | Applies To |
|---------|-------|------------|
| Indent style | spaces | All files |
| Indent size | [2 or 4] | [Language-specific] |
| Line length | [80/100/120] | All code |
| End of line | lf | All files |
| Final newline | yes | All files |
| Trim trailing whitespace | yes | All files |
## Quality Checks by Stage
| Check | Pre-commit | Pre-push | CI | Notes |
|-------|------------|----------|-----|-------|
| Formatting | Yes | - | Yes | Auto-fix locally |
| Linting (fast) | Yes | - | Yes | Syntax, imports |
| Linting (slow) | - | Yes | Yes | Complex analysis |
| Type checking | - | Yes | Yes | Full type analysis |
| Unit tests | - | Yes | Yes | Fast tests locally |
| Integration tests | - | - | Yes | CI only |
| Security scanning | - | Yes | Yes | Secrets, deps |
| Coverage | - | - | Yes | CI only |
## Validation Checklist
Commands with expected output, not reminders — a reader or an agent should be able to run these
and compare. Substitute the ecosystem's own commands; the shape is what matters.
```bash
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.
- 9d ago First seen · 891 lines · 62 tokens per session scan A 40f30f3bf2ba
setup-git-hooks is a skill published in the GitHub repository jrjsmrtn/project-orchestration-skills (15 stars, last pushed 5d ago), licensed MIT. It adds 62 tokens to every session and 7,990 once invoked, about $0.0003 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-30.
Other skills, from other repositories
github-copilot-upgrader
Use this to update the Github Copilot CLI/SDK.
workflow-patterns
Use this skill when implementing tasks according to Conductor's TDD workflow, handling phase checkpoints, managing git commits for tasks, or understanding the verification protocol.
meta-pre-commit-quality-gate
Run three quality gates (ruff + mypy + pytest) in parallel over the staged diff, then arbitrate a single BLOCK/APPROVE verdict. Use before committing changes locally when you want a comprehensive pre-commit gate beyond per-file linting — exactly the same gate set CI enforces.
nw-quality-framework
Quality gates - 11 commit readiness gates, build/test protocol, validation checkpoints, and quality metrics.
strict-tdd
Strict RED->GREEN->REFACTOR test-driven development with enforcement. Never write production code before a failing test. Atomic commits per TDD cycle.
re0-git
Rewrite a finished commit's message into a clean, handoff-ready form in your own log style, so git log alone tells the story. User-invoked: run it after a commit.