/wednesday-git
Unified Git workflow. Manages the entire task lifecycle: branch creation (sprint), atomic commits (git-os), and PR opening (pr-create).
$ npx -y skills add wednesday-solutions/ai-agent-skills --skill wednesday-git --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/wednesday-git
Context preview
The summary Claude sees to decide when to auto-load this skill.
Unified Git workflow. Manages the entire task lifecycle: branch creation (sprint), atomic commits (git-os), and PR opening (pr-create).
SKILL.md
wednesday-git.SKILL.mdname: wednesday-git
description: Unified Git workflow. Manages the entire task lifecycle: branch creation (sprint), atomic commits (git-os), and PR opening (pr-create).
permissions:
allow:
- Bash(git *)
- Bash(gh *)
- Bash(npm run *)
- Bash(npx --no-install commitlint *)
- Read(.wednesday/config.json)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 <branch_name>)`
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**:
### Ticket Link
---
### Description
---
### Steps to Test
---
### GIFs (if applicable)
---- **Push & Create**:
1. `Bash(git push origin <branch>)` 2. `Bash(gh pr create --title "<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.
Read more
name: wednesday-git
description: Unified Git workflow. Manages the entire task lifecycle: branch creation (sprint), atomic commits (git-os), and PR opening (pr-create).
permissions:
allow:
- Bash(git *)
- Bash(gh *)
- Bash(npm run *)
- Bash(npx --no-install commitlint *)
- Read(.wednesday/config.json)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 <branch_name>)`
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**:
### Ticket Link
---
### Description
---
### Steps to Test
---
### GIFs (if applicable)
---- **Push & Create**:
1. `Bash(git push origin <branch>)` 2. `Bash(gh pr create --title "<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.
Transform any repository into an AI-aware, intelligent environment — a codebase that any AI agent can jump into on day one without making junior-level mistakes.
Repo: wednesday-solutions/ai-agent-skills
Other skills on ai-agent-skills.
- /module-audit
Use when asked to audit a module, check its health, or assess whether it should be refactored. Runs structural query, risk check, and test generation automatically.
Open skill - /onboard-dev
Use when a dev is new to the project, asks for an overview, or wants to get oriented quickly. Fills graph gaps then runs a guided codebase interview.
Open skill - /pr-review-agent
Full PR review orchestrator. Use when asked to review a PR or check if it is ready to merge. Runs blast radius + drift check on changed files, then hands off to pr-review for comment triage and fixes. Do NOT use pr-review directly for full reviews — use this.
Open skill - /brownfield-drift
Enforces architecture boundaries defined in PLAN.md. Use when a PR crosses module/service boundaries, when the dev asks "are we following the architecture?", or as a scheduled architecture health check. Not for querying what a module does — use brownfield-chat for that.
Open skill - /codebase-intel
Unified codebase intelligence. Handles all questions about structure, logic, risk, and dependencies. Combines natural-language Q&A with deterministic lookups and pre-edit blast radius checks.
Open skill - /deploy-checklist
Pre-deploy and post-deploy checklist skill. Ensures env vars, migrations, CI, rollback plan, smoke tests, and monitoring are verified before and after every deployment.
Open skill