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/cosmix/loom/loom-git-workflownpx skills add cosmix/loom --skill loom-git-workflowgit clone --depth 1 https://github.com/cosmix/loomWhat 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.00040 | $0.02140 |
| Opus 5 | $0.00020 | $0.01070 |
| Sonnet 5 | $0.00008 | $0.00428 |
| Haiku 4.5 | $0.00004 | $0.00214 |
Grade A, and why
loom-git-workflow 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 3d 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 — 174 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Git Workflow
Overview
Git operations with an eye to a clean, bisectable history and safe collaboration. Canonical home for commit hygiene and conventional commits (referenced by /loom-code-review and /loom-refactoring).
The golden rule
Never rewrite history that others have based work on. rebase, commit --amend, reset --hard, and push --force on a shared/public branch orphan collaborators' commits and force painful recovery. Rewrite freely on your own un-pushed / unshared branch; treat anything pushed to a shared branch as immutable.
- Force-push only your own feature branch, and prefer
--force-with-lease(aborts if someone else pushed since your last fetch) over--force. - Never force-push
main/master/release/*— protect them server-side.
Commit hygiene (conventional commits)
Format: type(scope): description — feat, fix, docs, refactor, test, chore (+ perf, build, ci, style). ! or a BREAKING CHANGE: footer marks an incompatible change.
- Atomic: one logical change per commit. It should build and pass tests on its own — a green history is a bisectable history.
- Separate refactor from behavior change (see
/loom-refactoring): arefactor:commit is a runtime no-op; afix:commit changes behavior. Mixing them hides the fix from reviewers and poisonsgit bisect. - Message = what + why, not how. The diff shows how. Body explains motivation, tradeoffs, and links issues.
- Group by concern: 5 files across 3 concerns → 3 commits (module / its tests / wiring), not 1 monolith or 5 fragments.
git commit -m "fix(cart): resolve race in quantity update
Rapid add/remove let the count go negative via unsynchronized state.
Guard with an atomic compare-and-swap.
Fixes #234"
⚠ Loom stages: never git add -A / git add . — that stages the .work/ symlink. Stage specific files only.
Rebase vs. merge — pick deliberately
| Situation | Use | Why |
|---|---|---|
Update your local feature branch with main |
rebase |
Linear history; your commits replay on top, no merge noise |
Integrate a reviewed feature into main |
merge (often --no-ff) |
Preserves the branch as a reviewable unit; never rewrites shared history |
| Branch already pushed & others pulled it | merge (NOT rebase) |
Golden rule — rebasing rewrites shared commits |
| Clean up messy local WIP commits before a PR | rebase -i (before pushing) |
Squash/reorder/reword while still private |
| Long-lived branch, want to record integration points | merge |
Merge commits document when integration happened |
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.
- 3d ago First seen · 174 lines · 40 tokens per session scan A 8f636e425b8d
loom-git-workflow is a skill published in the GitHub repository cosmix/loom (54 stars, last pushed 4d ago), licensed MIT. It adds 40 tokens to every session and 2,140 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
git-commit-helper
Generate conventional commit messages automatically. Use when user runs git commit, stages changes, or asks for commit message help. Analyzes git diff to create clear, descriptive conventional commit messages. Triggers on git commit, staged changes, commit message requests.
conventional-commit
Generer conventional commit-meldinger med Nav-relevante scopes og breaking change-format.
execute-phase
Implement all remaining phases of a planned feature/fix by default, or one explicit P , with frozen acceptance, phase-local gates, commits, recovery, and final PR close-out. Use --fix for fix SPECs; --force is user-only.
git-commit
Run git commit using Angular conventional commit format. Use when the user asks to commit, create a commit, /git-commit, or save changes to git. Also trigger on "snapshot this", "save my work", "check in changes", "wrap up", "ship this locally", or whenever the user finishes a logical unit of work and the tree is…
landing
End-of-session ritual. Close finished beads, file new ones for remaining work, run verify, commit in logical groupings, push. Work is not complete until git push succeeds.
conventional-commits
Formats commit messages using the Conventional Commits specification. Use when creating commits, writing commit messages, or when the user mentions commits, git commits, or commit messages. Ensures commits follow the standard format for automated tooling, changelog generation, and semantic versioning.