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/majiang213/openclaw-mas/git-workflownpx skills add majiang213/OpenClaw-MAS --skill git-workflowgit clone --depth 1 https://github.com/majiang213/OpenClaw-MASWrote 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/majiang213/openclaw-mas/git-workflow)<a href="https://agentmods.dev/skills/majiang213/openclaw-mas/git-workflow"><img src="https://agentmods.dev/badge/skills/majiang213/openclaw-mas/git-workflow.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.00033 | $0.03883 |
| Opus 5 | $0.00016 | $0.01942 |
| Sonnet 5 | $0.00007 | $0.00777 |
| Haiku 4.5 | $0.00003 | $0.00388 |
Grade A, and why
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 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.
This is a copy
91% identical to git-workflow — 27 lines differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.
How it starts
The opening of the file, as written. The whole thing — 716 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Git Workflow Patterns
Best practices for Git version control, branching strategies, and collaborative development.
When to Activate
- Setting up Git workflow for a new project
- Deciding on branching strategy (GitFlow, trunk-based, GitHub flow)
- Writing commit messages and PR descriptions
- Resolving merge conflicts
- Managing releases and version tags
- Onboarding new team members to Git practices
Branching Strategies
GitHub Flow (Simple, Recommended for Most)
Best for continuous deployment and small-to-medium teams.
main (protected, always deployable)
│
├── feature/user-auth → PR → merge to main
├── feature/payment-flow → PR → merge to main
└── fix/login-bug → PR → merge to main
Rules:
mainis always deployable- Create feature branches from
main - Open Pull Request when ready for review
- After approval and CI passes, merge to
main - Deploy immediately after merge
Trunk-Based Development (High-Velocity Teams)
Best for teams with strong CI/CD and feature flags.
main (trunk)
│
├── short-lived feature (1-2 days max)
├── short-lived feature
└── short-lived feature
Rules:
- Everyone commits to
mainor very short-lived branches - Feature flags hide incomplete work
- CI must pass before merge
- Deploy multiple times per day
GitFlow (Complex, Release-Cycle Driven)
Best for scheduled releases and enterprise projects.
main (production releases)
│
└── develop (integration branch)
│
├── feature/user-auth
├── feature/payment
│
├── release/1.0.0 → merge to main and develop
│
└── hotfix/critical → merge to main and develop
Rules:
maincontains production-ready code onlydevelopis the integration branch- Feature branches from
develop, merge back todevelop - Release branches from
develop, merge tomainanddevelop - Hotfix branches from
main, merge to bothmainanddevelop
When to Use Which
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 · 716 lines · 33 tokens per session scan A a67d04fc9f1d
git-workflow is a skill published in the GitHub repository majiang213/OpenClaw-MAS (5 stars, last pushed 4mo ago), licensed MIT. It adds 33 tokens to every session and 3,883 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. It is 91% identical to git-workflow, differing in 27 lines, and is treated as a copy.
Other skills, from other repositories
app-store-changelog
Create user-facing App Store release notes by collecting and summarizing all user-impacting changes since the last git tag (or a specified ref). Use when asked to generate a comprehensive release changelog, App Store "What's New" text, or release notes based on git history or tags.
git-workflow-and-versioning
Structures git workflow practices. Use when making any code change. Use when committing, branching, resolving conflicts, opening or reviewing a pull request (PR), pushing to a remote, or when you need to organize work across multiple parallel streams. Use when cutting a release, choosing a semantic version bump…
ship
Commit and push the current work properly — lint, run the release gate, write a detailed commit message, push to GitHub. Use whenever work reaches a milestone or the user says ship it, commit, or push.
comet-safe-delivery
在保护无关脏改动、关联 worktree、子模块和用户明确边界的前提下，提交、推送、合并或完成范围明确的 Comet 变更。用户要求提交、推送、合并回目标分支、清理 worktree 或交付已准备好的改动时使用。.
git-ship
Use this skill whenever the user wants to commit, push, or ship changes in a git repository. Triggers include: "commit changes", "push my changes", "ship it", "commit and push", "create a branch and commit", "make a PR", "open a pull request", "create draft PR", or any variation of committing/pushing work. Always use…
writing-commits-and-prs
Apply the repository writing rules to commits, pull requests, branches, changelogs, and release notes.