How do I install the Git & Collaboration Standards skill?

Run npx skillmds@latest add fierzone/git-collaboration-standards in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

What does the Git & Collaboration Standards skill do?

Universal standards for version control, branching, and team collaboration. It is listed under Coding & Dev Tools, AI & ML on SkillMD.

Is Git & Collaboration Standards safe to use?

This skill has not completed SkillMD's automated safety review yet. Capability flags: docs only. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Git & Collaboration Standards?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Git & Collaboration Standards free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Git & Collaboration Standards?

fierzone (@fierzone) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Git & Collaboration Standards by fierzone

Name: Git & Collaboration Standards
Rating: 4.5 (4 reviews)
Author: fierzone

File contents

Git & Collaboration - High-Density Standards

Universal standards for version control, branching, and team collaboration.

Priority: P0 (OPERATIONAL)

Universal standards for effective version control, branching strategies, and team collaboration.

📝 Commit Messages (Conventional Commits)

Format: <type>(<scope>): <description> (e.g., feat(auth): add login validation).
Types: feat (new feature), fix (bug fix), docs, style, refactor, perf, test, chore.
Atomic Commits: One commit = One logical change. Avoid "mega-commits".
Imperative Mood: Use "add feature" instead of "added feature" or "adds feature".

🌿 Branching & History Management

Naming: Use prefixes: feat/, fix/, hotfix/, refactor/, docs/.
Branch for Everything: Create a new branch for every task to keep the main branch stable and deployable.
Main Branch Protection: Never push directly to main or develop. Use Pull Requests.
Sync Early: "Pull Before You Push" to identify and resolve merge conflicts locally.
Prefer Rebase: Use git rebase (instead of merge) to keep a linear history when updating local branches from develop or main.
Interactive Rebase: Use git rebase -i to squash or fixup small, messy commits before pushing to a shared branch.
No Merge Commits: Avoid "Merge branch 'main' into..." commits in feature branches. Always rebase onto the latest upstream.

🤝 Pull Request (PR) Standards

Small PRs: Limit to < 300 lines of code for effective review.
Commit Atomicness: Each commit should represent a single, complete logical change.
Description: State what changed, why, and how to test. Link issues (Closes #123).
Self-Review: Review your own code for obvious errors/formatting before requesting peers.
CI/CD: PRs must pass all automated checks (lint, test, build) before merging.

🛡 Security & Metadata

No Secrets: Never commit .env, keys, or certificates. Use .gitignore strictly.
Git Hooks: Use tools like husky or lefthook to enforce standards locally.
Tags: Use SemVer (vX.Y.Z) for releases. Update CHANGELOG.md accordingly.

📚 References

Clean Linear History & Rebase Examples

---name: git-collaboration-standardsdescription: Universal standards for version control, branching, and team collaboration.---# Git & Collaboration - High-Density StandardsUniversal standards for version control, branching, and team collaboration.## **Priority: P0 (OPERATIONAL)**Universal standards for effective version control, branching strategies, and team collaboration.## 📝 Commit Messages (Conventional Commits)- **Format**: `<type>(<scope>): <description>` (e.g., `feat(auth): add login validation`).- **Types**: `feat` (new feature), `fix` (bug fix), `docs`, `style`, `refactor`, `perf`, `test`, `chore`.- **Atomic Commits**: One commit = One logical change. Avoid "mega-commits".- **Imperative Mood**: Use "add feature" instead of "added feature" or "adds feature".## 🌿 Branching & History Management- **Naming**: Use prefixes: `feat/`, `fix/`, `hotfix/`, `refactor/`, `docs/`.- **Branch for Everything**: Create a new branch for every task to keep the main branch stable and deployable.- **Main Branch Protection**: Never push directly to `main` or `develop`. Use Pull Requests.- **Sync Early**: "Pull Before You Push" to identify and resolve merge conflicts locally.- **Prefer Rebase**: Use `git rebase` (instead of merge) to keep a linear history when updating local branches from `develop` or `main`.- **Interactive Rebase**: Use `git rebase -i` to squash or fixup small, messy commits before pushing to a shared branch.- **No Merge Commits**: Avoid "Merge branch 'main' into..." commits in feature branches. Always rebase onto the latest upstream.## 🤝 Pull Request (PR) Standards- **Small PRs**: Limit to < 300 lines of code for effective review.- **Commit Atomicness**: Each commit should represent a single, complete logical change.- **Description**: State what changed, why, and how to test. Link issues (`Closes #123`).- **Self-Review**: Review your own code for obvious errors/formatting before requesting peers.- **CI/CD**: PRs must pass all automated checks (lint, test, build) before merging.## 🛡 Security & Metadata- **No Secrets**: Never commit `.env`, keys, or certificates. Use `.gitignore` strictly.- **Git Hooks**: Use tools like `husky` or `lefthook` to enforce standards locally.- **Tags**: Use SemVer (`vX.Y.Z`) for releases. Update `CHANGELOG.md` accordingly.## 📚 References- [Clean Linear History & Rebase Examples](references/CLEAN_HISTORY.md)

Frequently asked questions

Git & Collaboration Standards