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 Plazmodium/odin-workflow --skill git-workflow-and-versioninggit clone --depth 1 https://github.com/Plazmodium/odin-workflowWrote 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/plazmodium/odin-workflow/git-workflow-and-versioning)<a href="https://agentmods.dev/skills/plazmodium/odin-workflow/git-workflow-and-versioning"><img src="https://agentmods.dev/badge/skills/plazmodium/odin-workflow/git-workflow-and-versioning.svg" alt="Measured on agentmods" 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.00027 | $0.00321 |
| Opus 5 | $0.00014 | $0.00161 |
| Sonnet 5 | $0.00005 | $0.00064 |
| Haiku 4.5 | $0.00003 | $0.00032 |
Grade A, and why
git-workflow-and-versioning 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 6d 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.
What it actually says
git-workflow-and-versioning
When To Use
- Preparing or reviewing code changes.
- Creating commits, branches, tags, or release points when explicitly requested.
- Checking repository state before risky work.
Workflow
- Check for
.jj/before any VCS command; preferjjwhen colocated unless git is required. - Inspect status before staging or committing.
- Keep changes atomic: one purpose per diff or commit.
- Avoid mixing refactors, behavior changes, formatting, and generated output unless required.
- Do not rewrite history, force push, or delete branches without explicit approval.
- Use the repository's existing commit and branch conventions.
- Verify the working tree state after VCS operations.
Anti-Rationalization
| Excuse | Rebuttal |
|---|---|
| "I'll include nearby cleanup in the commit." | Mixed commits are hard to review and revert. |
| "Force push is quicker." | Destructive history changes require explicit approval. |
| "Status is unnecessary." | Dirty worktrees may contain user changes. Inspect first. |
Verification
- VCS status is checked before and after mutations.
- Only intended files are staged or committed.
- No destructive operation occurs without explicit approval.
Exit Criteria
- Repository history remains safe, atomic, and reviewable.
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.
- 6d ago First seen · 43 lines · 27 tokens per session scan A cc5ae75c74e7
git-workflow-and-versioning is a skill published in the GitHub repository Plazmodium/odin-workflow (0 stars, last pushed 3mo ago), licensed MIT. It adds 27 tokens to every session and 321 once invoked, about $0.0001 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-09-01.
Other skills, from other repositories
git-flow-pr
Executes the full PR-driven development workflow: create an isolated feature branch from the current work, commit all staged changes, rebase cleanly onto the selected base branch (skipping any ancestor commits already merged), push the branch, and open a GitHub pull request linked to a related issue. Includes guidance…
new-gh-issue-orchestration
Orchestrates a GitHub-issue-driven delivery workflow from issue intake to PR creation using reviewer-first then worker execution. Invoked when the user provides a GitHub issue link/number and asks to start end-to-end delivery.
git-worktree-workspaces
Sets up and uses Git worktrees for parallel task workspaces in the same repository clone, including safe cleanup of local worktrees. Invoked when the user asks to work on multiple branches at once, isolate tasks without extra clones, or create/remove worktrees.
hmem-release
Pre-publish checklist for hmem: skills synced, version bumped, tests green, nothing forgotten. Use before npm publish or when the user says 'release', 'publish', 'push a release', or 'neue Version'.
github-pr-sentinel
Monitor a GitHub pull request until it's merged, green, or blocked. Polls CI checks, review comments, and mergeability state continuously. Use this skill when the user asks to monitor a PR, watch CI, handle review comments, sentinel a PR, babysit a PR, or keep an eye on failures and feedback — even if they just say…
git-github-workflow
Orchestrates the full git-to-merge lifecycle: validate → commit → check issues → create PR → monitor ALL GitHub Actions (including pre-existing failures) → fix via swarm/web research → merge with strategy selection → post-merge validate. Use this skill when the user asks to ship changes end-to-end, manage a PR through…