/common-git-collaboration
Enforce version control best practices for commits, branching, pull requests, and repository security. Use when writing commits, creating branches, merging, or opening pull requests.
$ npx -y skills add hoangnguyen0403/agent-skills-standard --skill common-git-collaboration --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/common-git-collaboration
Context preview
The summary Claude sees to decide when to auto-load this skill.
Enforce version control best practices for commits, branching, pull requests, and repository security. Use when writing commits, creating branches, merging, or opening pull requests.
SKILL.md
common-git-collaboration.SKILL.mdname: common-git-collaboration
description: Enforce version control best practices for commits, branching, pull requests, and repository security. Use when writing commits, creating branches, merging, or opening pull requests.
metadata:
triggers:
keywords:
- commit
- branch
- merge
- pull-request
- gitGit & Collaboration
**Priority: P0 (CRITICAL)**
1. Write Conventional Commits
- Format: `<type>(<scope>): <description>` (e.g., `feat(auth): add login validation`).
- Types: `feat`, `fix`, `docs`, `style`, `refactor`, `perf`, `test`, `chore`.
- Use imperative mood: "add feature" not "added feature".
- One commit = one logical change — no mega-commits.
See [implementation examples](references/implementation.md) for conventional commit examples.
2. Manage Branches
- Name with prefixes: `feat/`, `fix/`, `hotfix/`, `refactor/`, `docs/`.
- Create new branch for every task to keep main stable and deployable.
- Never push directly to `main` or `develop` — use Pull Requests.
- Pull before you push to resolve conflicts locally.
- Prefer `git rebase` over merge for linear history on feature branches.
- Use `git rebase -i` to squash messy commits before pushing.
3. Submit Quality Pull Requests
- Limit to < 300 lines of code for effective review.
- State what changed, why, and how to test. Link issues (`Closes #123`).
- Self-review for obvious errors before requesting peers.
- PRs must pass all CI checks (lint, test, build) before merging.
4. Protect Secrets and Metadata
- Never commit `.env`, keys, or certificates — use `.gitignore` strictly.
- Use `husky` or `lefthook` for local Git Hooks enforcement.
- Tag releases with SemVer (`vX.Y.Z`) and update `CHANGELOG.md`.
Anti-Patterns
- **No direct push to main**: All changes via PR, no exceptions.
- **No mega-commits**: One commit = one logical change. Split large ones.
- **No secrets in history**: Use `git filter-repo` to purge; rotate secret.
References
- [Clean Linear History & Rebase Examples](references/CLEAN_HISTORY.md)
Read more
name: common-git-collaboration
description: Enforce version control best practices for commits, branching, pull requests, and repository security. Use when writing commits, creating branches, merging, or opening pull requests.
metadata:
triggers:
keywords:
- commit
- branch
- merge
- pull-request
- gitGit & Collaboration
**Priority: P0 (CRITICAL)**
1. Write Conventional Commits
- Format: `<type>(<scope>): <description>` (e.g., `feat(auth): add login validation`).
- Types: `feat`, `fix`, `docs`, `style`, `refactor`, `perf`, `test`, `chore`.
- Use imperative mood: "add feature" not "added feature".
- One commit = one logical change — no mega-commits.
See [implementation examples](references/implementation.md) for conventional commit examples.
2. Manage Branches
- Name with prefixes: `feat/`, `fix/`, `hotfix/`, `refactor/`, `docs/`.
- Create new branch for every task to keep main stable and deployable.
- Never push directly to `main` or `develop` — use Pull Requests.
- Pull before you push to resolve conflicts locally.
- Prefer `git rebase` over merge for linear history on feature branches.
- Use `git rebase -i` to squash messy commits before pushing.
3. Submit Quality Pull Requests
- Limit to < 300 lines of code for effective review.
- State what changed, why, and how to test. Link issues (`Closes #123`).
- Self-review for obvious errors before requesting peers.
- PRs must pass all CI checks (lint, test, build) before merging.
4. Protect Secrets and Metadata
- Never commit `.env`, keys, or certificates — use `.gitignore` strictly.
- Use `husky` or `lefthook` for local Git Hooks enforcement.
- Tag releases with SemVer (`vX.Y.Z`) and update `CHANGELOG.md`.
Anti-Patterns
- **No direct push to main**: All changes via PR, no exceptions.
- **No mega-commits**: One commit = one logical change. Split large ones.
- **No secrets in history**: Use `git filter-repo` to purge; rotate secret.
References
- [Clean Linear History & Rebase Examples](references/CLEAN_HISTORY.md)
The portable SDLC standards layer for AI coding agents. Sync once, then work in your own runtime.
Repo: hoangnguyen0403/agent-skills-standard
Other skills on agent-skills-standard.
- /android-agp-upgrade
Upgrade an Android project to Android Gradle Plugin (AGP) 9. Use when migrating to AGP 9, updating Gradle build files, migrating to built-in Kotlin, or adopting the new AGP DSL.
Open skill - /android-architecture
Apply Clean Architecture layering, modularization, and Unidirectional Data Flow in Android projects. Use when setting up project structure, placing code in layers, configuring feature/core modules, or implementing UDF patterns; defer Compose state and ViewModel/StateFlow
Open skill - /android-background-work
Implement WorkManager and background processing correctly on Android. Use when creating Worker classes, scheduling tasks, choosing between WorkManager and Foreground Services, or setting up Hilt in workers; defer FCM and notification delivery to android-notifications.
Open skill - /android-compose-migration
Migrate an Android XML View to Jetpack Compose following a structured 10-step workflow. Use when converting XML layouts to Compose, setting up Compose in an existing View-based project, or incrementally adopting Compose.
Open skill - /android-compose
Build high-performance declarative UI with Jetpack Compose. Use when writing Composable functions, optimizing recomposition, hoisting state, or working with LazyColumn and side effects; defer deep-link and navigation routing to android-navigation.
Open skill - /android-concurrency
Write correct coroutine scopes, lifecycle collection, and dispatcher injection in Android production code. Use for suspend functions, coroutine scopes, and dispatcher mechanics; defer ViewModel StateFlow/LiveData architecture, Fragment lifecycle recipes,
Open skill

