" --body "<body>")` using the template above. --- ## 🚫 Never - **Direct Commits**: Never commit directly to `main` or `develop`. - **Dirty History**: Never bundle multiple concerns into one commit. - **Skip Checks**: Never open a PR without running the full pre-push checklist. - **AI Fingerprints**: Never use "AI-generated" descriptions or co-author tags. ## ⚠️ Safety Thresholds - **Risk > 80**: If the `codebase-intel` risk score is > 80, require explicit confirmation before pushing. - **Quality Gate**: If Sonar is enabled and the quality gate fails, STOP — do not push. ## 🛠 Tools - `Bash` for all `git` and `gh` operations. - `Read` for `package.json` and `.wednesday/config.json` to check for project-specific automation.

# Wednesday Git > Wednesday Git Workflow (GIT-OS) - Skill: `wednesday-solutions/wednesday-git` (Agent Skill) - Install (CLI): `npx skillmds@latest add wednesday-solutions/wednesday-git` - Raw SKILL.md: https://api.skillmd.com/api/skills/wednesday-solutions/wednesday-git/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Productivity - Author: wednesday-solutions (https://skillmd.com/u/wednesday-solutions) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/wednesday-solutions/wednesday-git --- # Wednesday Git Workflow (GIT-OS) This skill manages the complete lifecycle of a feature or fix. It ensures that every branch, commit, and PR follows the project's quality and automation standards. ## Lifecycle Phases ### 1. Starting a Task (`sprint`) When a dev provides a ticket and wants to start working: - **Action**: Create a branch following the `type/name` format (e.g., `feat/user-auth`). - **Rule**: Max 40 characters, kebab-case, no ticket numbers in the branch name. - **Tool**: `Bash(git checkout -b )` ### 2. Committing Changes (`git-os`) When code is ready for an atomic commit: - **Format**: `type(scope?): Description` (e.g., `feat(auth): Add login endpoint`). - **Types**: `feat`, `fix`, `refactor`, `perf`, `docs`, `style`, `test`, `chore`. - **Atomic Rule**: One logical change per commit. If you've done multiple things, split them into separate commits. - **Human-Authored**: NEVER include AI attribution or fingerprints. - **Linting**: Before committing, ensure `npx --no-install commitlint` would pass. ### 3. Opening a Pull Request (`pr-create`) When the task is finished and ready for review: - **Pre-Push Checklist**: Run `npm run lint`, `format:check`, `test`, and `build`. - **Validation**: - **Max 6 files per PR**: If the PR is larger, suggest splitting it. - **Conventional Title**: Title must match `type(scope): Description`. - **Metadata**: Extract ticket ID from branch name (e.g., `WED-142`). - **PR Description Template**: ```markdown ### Ticket Link --- ### Description --- ### Steps to Test --- ### GIFs (if applicable) --- ``` - **Push & Create**: 1. `Bash(git push origin )` 2. `Bash(gh pr create --title "" --body "<body>")` using the template above. --- ## 🚫 Never - **Direct Commits**: Never commit directly to `main` or `develop`. - **Dirty History**: Never bundle multiple concerns into one commit. - **Skip Checks**: Never open a PR without running the full pre-push checklist. - **AI Fingerprints**: Never use "AI-generated" descriptions or co-author tags. ## ⚠️ Safety Thresholds - **Risk > 80**: If the `codebase-intel` risk score is > 80, require explicit confirmation before pushing. - **Quality Gate**: If Sonar is enabled and the quality gate fails, STOP — do not push. ## 🛠 Tools - `Bash` for all `git` and `gh` operations. - `Read` for `package.json` and `.wednesday/config.json` to check for project-specific automation.