git-standards
Skill0 starsChanged 7 months agoMITView on GitHub
Conventional Commits and branch-naming reference for CWE-managed projects. Enforced via PreToolUse hooks on git commit and git checkout -b (not via free-text routing). Consulted when writing commit messages, creating branches, or preparing releases.
In this repository17 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- agent-detectionSkill
- auto-delegationSkill
- bookstackSkill
- delegatorSkill
- faceswapSkill
- headswapSkill
- health-dashboardSkill
- imageSkill
- motionSkill
- multi-terminalSkill
- project-docsSkill
- quality-gatesSkill
- safety-gateSkill
- upscaleSkill
- videoSkill
- web-researchSkill
The file
We split this skill into the rules it gives an agent
1 rule. About 0 are common, 0 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈0
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 105
Create git tag v<VERSION>
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Git Standards
Consistent git practices for all CWE-managed projects.
Conventional Commits
Format
<type>(<scope>): <subject>
<body>
<footer>Types
| Type | When |
feat | New feature |
fix | Bug fix |
chore | Maintenance, tooling |
docs | Documentation only |
style | Formatting, no logic change |
refactor | Code change, no feature/fix |
test | Adding/fixing tests |
perf | Performance improvement |
ci | CI/CD configuration |
build | Build system changes |
revert | Reverting previous commit |
Rules
- Type is required — must be one of the types above
- Scope is optional — module/component name in parentheses
- Subject is required — imperative mood, lowercase, no period
- Body is optional — explain "why", not "what"
- Breaking changes — add
!after type/scope:feat!: remove v1 API - Footer —
BREAKING CHANGE:,Closes #123,Co-Authored-By:
Examples
feat(auth): add JWT token refresh
fix: prevent crash when user has no profile
docs: update API endpoint documentation
refactor(api): extract validation middleware
chore: update dependencies to latest versions
feat!: drop Node.js 16 supportBranch Naming
Patterns
| Pattern | Purpose |
main | Production branch |
develop | Integration branch |
feature/<ticket>-<description> | New features |
fix/<ticket>-<description> | Bug fixes |
hotfix/<description> | Urgent production fixes |
chore/<description> | Maintenance |
release/<version> | Release preparation |
Rules
- All lowercase
- Hyphens for word separation (not underscores)
- Prefix required (feature/, fix/, etc.) except for main/develop
- Short, descriptive slug after prefix
Examples
feature/123-user-authentication
fix/456-login-crash
hotfix/session-timeout
chore/update-dependencies
release/0.4.2Auto-Generated Release Notes
Triggered by /cwe:devops release:
- Parse commits since last git tag
- Group by type:
- Features (feat)
- Bug Fixes (fix)
- Performance (perf)
- Breaking Changes (feat!, fix!, BREAKING CHANGE)
- Other (chore, docs, style, refactor, test, ci, build)
- Generate CHANGELOG.md entry
- Create git tag
v<VERSION>
Enforcement
- Commit format: PreToolUse hook validates on
git commit - Branch naming: PreToolUse hook validates on
git checkout -b/git switch -c - Bypass:
--no-verifyfor emergencies (gets logged)
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

