popoffvg/git-workflow
.pi/agent/skills/git-workflow/SKILL.md
This skill should be used when asked about branching, committing, PRs, or the end-to-end Git development flow. Covers available commands (/smart-commit, /pr, /fix), branch naming conventions, and when to use each tool.
$ install --global
skillsauthnpx skillsauth add popoffvg/dotfiles git-workflowInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: Apr 16, 2026, 2:25 AM5.8s1 file scanned
SKILL.md
- name:
- git-workflow
- description:
- This skill should be used when asked about branching, committing, PRs, or the end-to-end Git development flow. Covers available commands (/smart-commit, /pr, /fix), branch naming conventions, and when to use each tool.
Git Workflow
Available Commands
| Command | When to use |
| --------------------------| -----------------------------------------------------------------------------------------------------------|
| /smart-commit | You have changes ready to commit — analyzes diff, proposes logical split, asks for approval, then commits |
| /pr | Branch is ready to merge — creates a GitHub PR with purpose + changes + tests description |
| /fix | You made a code change and want to fixup into the best existing local commit |
| commit-commands:commit | Quick single commit, no split needed |
End-to-End Flow
1. Create branch
git checkout -b <type>/<short-description>
2. Make changes
... code, tests ...
3. Commit
/smart-commit ← propose split, approve, commit
4. More changes? Repeat step 3.
5. Open PR
/pr ← push + create PR with structured description
Branch Naming
feat/<short-description> new feature
fix/<short-description> bug fix
refactor/<description> refactoring
chore/<description> maintenance, deps, config
Examples: feat/k8s-health-check, fix/auth-token-expiry, chore/update-deps
Conventional Commit Types
| Type | Use for |
|------|---------|
| feat | New feature or functionality |
| fix | Bug fix |
| test | Adding or updating tests |
| doc | Documentation (README, comments) |
| refactor | Code restructuring without behavior change |
| chore | Dependencies, config, build, CI |
| perf | Performance improvements |
| style | Formatting, linting (no logic change) |
Rules
- Never
git add .orgit add -A— always add specific files - Never skip hooks (
--no-verify) - Never amend already-pushed commits — create a new commit instead
- No "Co-Authored-By" AI lines in commits
- No "Generated with Claude Code" footers anywhere
When Things Go Wrong
Hook fails on commit → fix the issue, re-stage, create a NEW commit (not amend). Max 2 retries, then abort and report.
PR already exists → gh pr list to check, then gh pr edit to update instead of creating a new one.
Branch is stale → git fetch && git status to check, then rebase: git rebase origin/main.
Autoresearch rules
Eval checklist:
- Was the correct command recommended for the situation (/smart-commit vs /pr vs /fix)?
- Did branch naming follow the convention (<type>/<short-description>)?
- Were zero git operations performed without the user understanding what would happen?
- Was the end-to-end flow followed in order (branch → changes → commit → PR)?
Test inputs:
- "I have staged changes ready to commit"
- "My branch is ready for review, create a PR"
- "I need to fixup a typo into a previous commit"
Can change: command descriptions, flow documentation, branch naming examples, when-to-use guidance Cannot change: command names (/smart-commit, /pr, /fix), branch naming convention Min sessions before eval: 5 Runs per experiment: 3
Related Skills
popoffvg/improve-claude-local
tools
VerifiedTrustedCommunity
Improve a whole CLAUDE.local.md — the private, per-project rules captured from user corrections. Wraps each conditional rule in a <task-relevant> block so it only surfaces for matching work, merges duplicates, generalizes one-off facts, drops stale entries, and routes raw project facts to engram. Use when the user says "improve claude.local", "clean up the local rules", "claude.local is bloated", or after the Stop hook has appended many rules.
2SKILL.mdUpdated Jun 25, 2026
popoffvg/workflow
testing
VerifiedTrustedCommunity
WM pipeline and conventions shared across all phases. Agents must read this before spec, impl, or verify work.
2SKILL.mdUpdated Jun 19, 2026
popoffvg/code
development
VerifiedTrustedCommunity
One entry point for spec writing, implementation, and bug fixing. Default is new (write spec → grill loop → produce notes → author TODO bodies). Other subcommands: verify (audit), revise (sync to shipped), prototype (settle a decision), code-map (diagram), impl (execute one TODO), fix (analyze cause, correct thoughts, fix behavior), help (this page). Invoke as /code <subcommand>.
2SKILL.mdUpdated Jun 19, 2026
popoffvg/red-green-refactor
development
VerifiedTrustedCommunity
Red-Green-Refactor cycle for bug fixes. Before fixing a bug, first write a failing test that reproduces it (Red), then make the minimal change to pass (Green), then clean up the code (Refactor). Use on any bug fix, error correction, failing test repair, or when user says "fix this bug".
2SKILL.mdUpdated Jun 18, 2026