How do I install the Git Workflow skill?

Run npx skillmds@latest add 0xlayerghost/git-workflow 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.

Is Git Workflow safe to use?

This skill has not completed SkillMD's automated safety review yet. Independent scanners report: SkillSpector: PASS, Skill Scanner: PASS. Capability flags: reads secrets. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Git Workflow?

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 Workflow free to use?

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

Who published Git Workflow?

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

Git Workflow by 0xlayerghost — Agent Skill

Name: Git Workflow
Rating: 4.5 (4 reviews)
Author: 0xlayerghost

Git Workflow

[AUTO-INVOKE] MUST be invoked BEFORE creating git commits, PRs, or code reviews. Covers Conventional Commits, PR templates, review requirements, and AI-assisted development rules. Trigger: any task involving git commit, git push, PR creation, or code review.

0xlayerghost Updated Sep 8, 2026

File contents

Git Collaboration Standards

Language Rule

Always respond in the same language the user is using. If the user asks in Chinese, respond in Chinese. If in English, respond in English.

Commit Rules

Use Conventional Commits format: <type>: <short description>

Type	When to use
`feat:`	New feature or contract
`fix:`	Bug fix
`refactor:`	Code restructure without behavior change
`test:`	Add or update tests
`docs:`	Documentation changes
`chore:`	Build config, dependency updates, toolchain
`security:`	Security fix or hardening

Commit Workflow

Run git diff to review all changes before staging
Stage specific files — avoid git add . to prevent committing .env or artifacts
Write concise commit message describing the why, not the what
Never add Co-Authored-By lines — commit messages should only contain the description
Only commit — never git push unless explicitly requested
Never push directly to main/master — always use feature branches

Branch Naming

Pattern	Example
`feat/<name>`	`feat/staking-pool`
`fix/<name>`	`fix/reentrancy-guard`
`refactor/<name>`	`refactor/token-structure`

PR Requirements

Every PR must include:

Section	Content
Change description	What was changed and why
Test results	`forge test` output (all pass)
Gas impact	`forge test --gas-report` diff for changed functions
Deployment impact	Does this affect deployed contracts? Migration needed?
Review focus	Specific areas that need careful review

Code Review Rules

Scenario	Requirement
Standard changes	Minimum 1 maintainer approval
Security-related changes	Minimum 2 maintainer approvals
AI-generated code	Must pass manual review + `forge test` before merge
Contract upgrades	Requires full team review + upgrade simulation on fork

AI Assistance Rules

AI-generated code must pass forge test before committing
Always review AI output for: correct import paths, proper access control, gas implications
Include relevant file paths and test cases in AI prompts for better results
Run forge fmt after AI generates code to ensure consistent formatting

---name: git-workflowdescription: [AUTO-INVOKE] MUST be invoked BEFORE creating git commits, PRs, or code reviews. Covers Conventional Commits, PR templates, review requirements, and AI-assisted development rules. Trigger: any task involving git commit, git push, PR creation, or code review.---# Git Collaboration Standards## Language Rule- **Always respond in the same language the user is using.** If the user asks in Chinese, respond in Chinese. If in English, respond in English.## Commit RulesUse Conventional Commits format: `<type>: <short description>`| Type | When to use ||------|------------|| `feat:` | New feature or contract || `fix:` | Bug fix || `refactor:` | Code restructure without behavior change || `test:` | Add or update tests || `docs:` | Documentation changes || `chore:` | Build config, dependency updates, toolchain || `security:` | Security fix or hardening |### Commit Workflow1. Run `git diff` to review all changes before staging2. Stage specific files — avoid `git add .` to prevent committing `.env` or artifacts3. Write concise commit message describing the **why**, not the **what**4. **Never add `Co-Authored-By` lines** — commit messages should only contain the description5. **Only commit** — never `git push` unless explicitly requested6. **Never push directly to main/master** — always use feature branches## Branch Naming| Pattern | Example ||---------|---------|| `feat/<name>` | `feat/staking-pool` || `fix/<name>` | `fix/reentrancy-guard` || `refactor/<name>` | `refactor/token-structure` |## PR RequirementsEvery PR must include:| Section | Content ||---------|---------|| Change description | What was changed and why || Test results | `forge test` output (all pass) || Gas impact | `forge test --gas-report` diff for changed functions || Deployment impact | Does this affect deployed contracts? Migration needed? || Review focus | Specific areas that need careful review |## Code Review Rules| Scenario | Requirement ||----------|------------|| Standard changes | Minimum 1 maintainer approval || Security-related changes | Minimum 2 maintainer approvals || AI-generated code | Must pass manual review + `forge test` before merge || Contract upgrades | Requires full team review + upgrade simulation on fork |## AI Assistance Rules- AI-generated code must pass `forge test` before committing- Always review AI output for: correct import paths, proper access control, gas implications- Include relevant file paths and test cases in AI prompts for better results- Run `forge fmt` after AI generates code to ensure consistent formatting

Frequently asked questions