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/nklofy/code-agent-skills/git-workflownpx skills add nklofy/code-agent-skills --skill git-workflowgit clone --depth 1 https://github.com/nklofy/code-agent-skillsWrote 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/nklofy/code-agent-skills/git-workflow)<a href="https://agentmods.dev/skills/nklofy/code-agent-skills/git-workflow"><img src="https://agentmods.dev/badge/skills/nklofy/code-agent-skills/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.03886 |
| Opus 5 | $0.00016 | $0.01943 |
| Sonnet 5 | $0.00007 | $0.00777 |
| Haiku 4.5 | $0.00003 | $0.00389 |
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
92% identical to git-workflow — 28 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 — 717 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 · 717 lines · 33 tokens per session scan A 707999138b92
git-workflow is a skill published in the GitHub repository nklofy/code-agent-skills (18 stars, last pushed 2mo ago), licensed Apache-2.0. It adds 33 tokens to every session and 3,886 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. It is 92% identical to git-workflow, differing in 28 lines, and is treated as a copy.
Other skills, from other repositories
github-automation
GitHub workflow automation, PR management, issue tracking, and code review coordination. Integrates with GitHub Actions and repository management. Use when: PR creation, code review, issue management, release automation, workflow setup. Skip when: local-only changes, non-GitHub repositories.
crew-commit
Canonical commit workflow for Gas Town crew members: pre-flight checks, branch creation, gt commit with agent identity, push, and PR creation. Use when ready to commit and submit work for review.
cherry-pick
Cherry-pick a commit from main to a Sui release branch, create the release PR, and report the PR URL.
task-snapshot
Create a commit or tag snapshot only when explicitly requested for a milestone, reproducibility checkpoint, handoff, or pinned artifact.
mflux-pr
Make a clean PR in mflux (inspect diff, quick verification, commit, push, open PR) using repo conventions.
comet-safe-delivery
在保护无关脏改动、关联 worktree、子模块和用户明确边界的前提下，提交、推送、合并或完成范围明确的 Comet 变更。用户要求提交、推送、合并回目标分支、清理 worktree 或交付已准备好的改动时使用。.