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 rules/itsbrex/attio-mcp-server/git_conventionsgit clone --depth 1 https://github.com/itsbrex/attio-mcp-serverWhat 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.00009 | $0.01349 |
| Opus 5 | $0.00005 | $0.00674 |
| Sonnet 5 | $0.00002 | $0.00270 |
| Haiku 4.5 | $0.00001 | $0.00135 |
Grade A, and why
git_conventions 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 — 169 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Git Rules and Best Practices
Commit Message Standards
- Use gitmoji conventional commits format:
<emoji> <type>(<scope>): <description> - Types include: feat, fix, docs, style, refactor, test, chore
- Keep the first line under 72 characters
- Use the imperative mood ("Add feature" not "Added feature")
- Reference issue numbers when applicable
Emoji Reference
- 🎉 Initial commit or major new feature
- ✨ New feature
- 🐛 Bug fix
- 📝 Documentation update
- 🔧 Configuration changes
- 🚀 Performance improvements
- 💄 Style/UI updates
- ♻️ Refactoring code
- ✅ Adding or updating tests
- 🔒 Security fixes
- ⬆️ Upgrading dependencies
- ⬇️ Downgrading dependencies
- 🚨 Fixing linter warnings
- 🔀 Merging branches
Branch Naming Conventions
- Feature branches:
feature/<feature-name> - Bug fix branches:
fix/<bug-description> - Release branches:
release/<version> - Hotfix branches:
hotfix/<issue-description> - Use kebab-case for branch names
Git Workflow
- Always pull before starting new work
- Create feature branches from main/master
- Regularly commit small, logical changes
- Push branches regularly for backup
- Create pull requests for code review
- Squash commits when merging to main/master
Git Hooks
- Use pre-commit hooks for linting and formatting (biome, ruff)
- Use commit-msg hooks to enforce commit message standards (commitlint)
- Use pre-push hooks for running tests
Git Configuration
- Use
.gitignoreto exclude build artifacts, dependencies, and sensitive files - Configure
.gitattributesfor proper line endings and binary file handling - Use signed commits when possible
Example Commands
Commit Examples
# Feature commits
✨ feat(auth): add JWT authentication system
✨ feat(ui): implement responsive navigation component
✨ feat(api): add user profile endpoints
# Bug fix commits
🐛 fix(auth): resolve token expiration handling
🐛 fix(ui): correct button alignment on mobile devices
🐛 fix(api): handle null values in user data
# Documentation commits
📝 docs(readme): update installation instructions
📝 docs(api): add endpoint documentation
📝 docs: add contributing guidelines
# Configuration commits
🔧 config: update TypeScript compiler options
🔧 config(docker): optimize container build process
🔧 config(ci): add automated testing workflow
# Performance commits
🚀 perf(db): optimize database queries for user search
🚀 perf(ui): implement lazy loading for images
🚀 perf: reduce bundle size by 30%
# Refactoring commits
♻️ refactor(utils): extract common validation functions
♻️ refactor(components): convert to TypeScript
♻️ refactor: reorganize project structure
# Test commits
✅ test(auth): add unit tests for login flow
✅ test(api): increase coverage for user endpoints
✅ test: add e2e tests for checkout process
# Dependency commits
⬆️ deps: upgrade React to v19
⬇️ deps: downgrade axios to resolve compatibility issue
🔒 deps: update security vulnerable packages
# Multi-line commit example
✨ feat(payment): implement Stripe payment integration
- Add payment form component with validation
- Integrate Stripe SDK for secure processing
- Add error handling and success states
- Update user model to track payment history
Resolves: #123
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 · 169 lines · 9 tokens per session scan A 72b9a4c66786
git_conventions is a cursor rule published in the GitHub repository itsbrex/attio-mcp-server (7 stars, last pushed 1y ago), licensed MIT. It adds 9 tokens to every session and 1,349 once invoked, about $0.0000 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 cursor rules, from other repositories
commit
Rules for committing changes with skill-based validation.
no-cursor-coauthor-trailer
Keep Cursor's automatic Co-authored-by trailer out of commit messages, in line with project preference.
00-hard-rules
Canonical MUST/NEVER rules - single source of truth. No duplication elsewhere.
git-commit-attribution
Git commits must use the human developer identity only; never Cursor Agent co-authorship.
testing-strategy
Testing strategy focusing on API validation over automated tests. Use analyzefeature after implementation, fix errors, then test via API requests. Apply when: feature complete, post-implementation validation, API testing, avoiding unnecessary test file creation.
git-conventional-commits
Conventional commit messages and logical multi-commit workflow when working with Git.