git-workflow · diff
v1.0.0 to git:20260209.f77aa76
44 added, 30 removed. Audit A to A.
---
name: git-workflow
- description: Git Collaboration Standards - Commit conventions, PR requirements, Code Review for Solidity projects
- author: 0xlayerghost
- version: 1.0.0
- triggers:
- - "commit"
- - "git"
- - "PR"
- - "pull request"
- - "code review"
+ description: Enforce Git collaboration standards for Solidity/Foundry projects. Use when committing code, creating PRs, or reviewing changes — covers Conventional Commits, PR templates, review requirements, and AI-assisted development rules.
---
# 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 Conventions
+ ## Commit Rules
- Use Conventional Commits:
+ Use Conventional Commits format: `<type>: <short description>`
- | Prefix | Usage |
- |--------|-------|
- | `feat:` | New feature |
+ | Type | When to use |
+ |------|------------|
+ | `feat:` | New feature or contract |
| `fix:` | Bug fix |
- | `refactor:` | Refactoring (no functionality change) |
- | `test:` | Test related |
- | `docs:` | Documentation update |
- | `chore:` | Build/toolchain changes |
+ | `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 |
- - Run `git diff` before committing to confirm changes
- - Only commit, do not push unless explicitly requested
- - Never push directly to main/master branch
+ ### Commit Workflow
+ 1. Run `git diff` to review all changes before staging
+ 2. Stage specific files — avoid `git add .` to prevent committing `.env` or artifacts
+ 3. Write concise commit message describing the **why**, not the **what**
+ 4. **Only commit** — never `git push` unless explicitly requested
+ 5. **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:
- - **Change description**: What was done and why
- - **Test results**: `forge test` output
- - **Deployment impact**: Whether it affects deployed contracts
- - **Review focus**: Areas that need special attention
- ## Code Review
+ | 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 |
- - At least 1 maintainer must approve
- - Security-related changes require 2 maintainer approvals
- - AI-generated code must pass manual 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
- - Output should include code snippets, file references, and test cases
+ - 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