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/bostonaholic/team/git-commitnpx skills add bostonaholic/team --skill git-commitgit clone --depth 1 https://github.com/bostonaholic/teamWhat 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.00048 | $0.01362 |
| Opus 5 | $0.00024 | $0.00681 |
| Sonnet 5 | $0.00010 | $0.00272 |
| Haiku 4.5 | $0.00005 | $0.00136 |
Grade A, and why
git-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 — 163 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Git Commit Methodology
A commit is the permanent record of a decision. A well-formed commit answers three questions: what changed, why it changed, and how to understand the change in isolation. Every commit should be correct on its own — readable without surrounding context, reversible without side effects, and meaningful in the project history.
Write the prose this skill governs at a seventh-grade reading level, in
STE-flavored mode — short sentences, common words, no unexplained jargon.
Full methodology: writing-prose. Before
you finalize prose this skill governs, call the Skill tool with
writing-prose and apply its ## Self-lint checklist.
The 50/72 Rule
Subject Line (50 characters)
The subject line is what appears in git log --oneline, GitHub PR titles,
and email notifications. Keep it under 50 characters.
- Imperative mood. "Add user authentication" not "Added user authentication" or "Adds user authentication". Write as if completing the sentence "This commit will..."
- No period at the end. The subject is a title, not a sentence.
- Capitalize the first word (after the type prefix in Conventional Commits).
- Be specific. "Fix bug" is not useful. "Fix null dereference in token parser" is useful.
Body (72 characters per line)
The body explains the why, not the what. The diff shows what changed. The body answers questions the diff cannot answer.
- Separate from subject with a blank line. This is how git distinguishes subject from body.
- Wrap at 72 characters. Many tools display git output in 80-column terminals. Leaving 8 characters of margin prevents ugly wrapping.
- Explain motivation. Why was this change necessary? What problem does it solve? What would happen if this commit did not exist?
- Note non-obvious consequences. If this commit changes behavior that callers depend on, say so. If it requires a migration, say so. If it intentionally breaks something to fix something else, say so.
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 · 163 lines · 48 tokens per session scan A 04e5f00900da
git-commit is a skill published in the GitHub repository bostonaholic/team (11 stars, last pushed 2d ago), licensed MIT. It adds 48 tokens to every session and 1,362 once invoked, about $0.0002 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
tutti-workspace-app-factory
Create, convert, or repair one Tutti workspace app as either a self-contained publishable package under package/ or a Chrome-style local debug app under .tutti/dev-app/. Use for mention://workspace-app-factory/create handoffs, mention://workspace-app-factory handoffs, standalone app generation, adapting existing…
analyze-performance-traces
Analyze Chrome, Chromium, Electron, React DevTools, or Perfetto-compatible JSON traces and audit user-reported profiling findings without loading large artifacts into context; prove trigger-to-render/layout chains, separate measured facts from source inference, find exact code choke points, classify forced layout and…
tutti-app-release
Set up, review, run, or debug external repositories that publish a Tutti workspace app through the reusable Tutti App Release GitHub Actions workflow. Use for caller workflows, tutti.app.json manifests, @tutti-os/app-release-tools, S3/CloudFront release hosting, latest.json, versions.json, catalog.json, catalog-only…
tutti-record-agent-session-replay
From a Tutti checkout, run, audit, freshly replay, publish, or diagnose Session Replay cassettes that are driven by case-repository scenario scripts (CDP), not by interactive UI recording. Use for real-Provider capture while a scenario.mjs executes, cassette transport or semantic-state mismatches, fresh replay…
tutti-ui-system
Use when working with @tutti-os/ui-system components, replacing local UI with shared components, querying component ids or metadata, promoting UI into shared base or business components, or maintaining UI-system storyboard inventory.
tutti-architecture-review
Review tutti git diffs for project structure, layering, module ownership, and duplicate event-center infrastructure by planning focused architecture review tasks, then having the main agent orchestrate sub-agents for only the changed areas.