aldengolab/git-workflow
skills/git-workflow/SKILL.md
Enforces conventional commit format and a comprehensive PR workflow across all git repositories. Invoke this skill whenever the user wants to commit changes, create a pull request, push to a branch, or finish a feature for merging — even if they don't use those exact words. Triggers include: commit, create a PR, open a PR, push my changes, make a commit, commit and push, submit a PR, merge this, ready to merge, open a pull request. This skill handles conventional commit formatting, automatic breaking-change detection, doc and Makefile updates, and structured PR descriptions with honest test plans. Use it for every commit and PR action, no exceptions.
development
Updated Apr 10, 2026
$ install --global
skillsauthnpx skillsauth add aldengolab/lorist 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 10, 2026, 3:31 AM10.5s5 files scanned
SKILL.md
- name:
- git-workflow
- description:
- >-
- even if they don't use those exact words. Triggers include:
- commit, create a
Git Workflow
This skill governs how to commit code and create pull requests. The goal is consistency, clarity for collaborators, and honest documentation — especially around testing.
Conventional Commit Format
All commit messages and PR titles must use this format: <type>[(scope)][!]: <description>
| Type | When to use |
|------|-------------|
| feat | New feature |
| fix | Bug fix |
| docs | Documentation-only changes |
| style | Formatting, whitespace (no logic change) |
| refactor | Code restructuring without feature/fix |
| test | Adding or modifying tests |
| chore | Build process, dependency updates, tooling |
| ci / perf / build | CI changes / performance / build system |
Scope: Optional but recommended — module or file area affected. E.g. (auth), (api), (cli).
Description: Lowercase imperative mood ("add feature"), no trailing period, under 72 characters total.
Breaking Change Detection
Before writing any commit title or PR title, check whether the diff includes:
- Removing or renaming a public API, function, endpoint, CLI argument, or config key
- Changing the expected behavior of an existing interface in a way that breaks callers
- Requiring consumers of this code to update their own code or config
If any of these apply, mark it as breaking:
- Add
!after the type/scope in the title:feat(api)!: rename /users to /accounts - Add a
BREAKING CHANGE:footer in the commit body explaining what changed and how to migrate
When in doubt, flag it. False positives are cheap; missed breaking changes cause real pain downstream.
Tool Preference: MCP Git Server
When a git MCP server is available (e.g., lorist-git or similar), prefer its tools over raw Bash git/gh commands. MCP git tools typically provide structured input/output, enforce conventional commit format automatically, and gate destructive operations behind a write flag.
Look for MCP tools that cover: status, diff, log, add, commit, push, branch, PR creation/viewing/editing, and review thread operations. If commit or PR creation tools accept structured parameters like commit_type, scope, and description, use them — they build the conventional commit message for you.
Fall back to Bash only when no MCP server is available or for operations it doesn't cover (e.g., git stash).
Committing Changes
- Verify you are on the correct branch. Before staging or committing, run
git branch --show-current(or the MCP equivalent). Confirm the current branch matches the feature/fix you are working on. If the branch is wrong — e.g., you are onmainwhen you should be on a feature branch, or on a branch whose PR has already been merged — create or switch to the correct branch before committing. Never commit a fix to a branch that has already been merged or that doesn't match the scope of the change. - Check status and review diffs for all changed files (via MCP tools if available, otherwise
git statusandgit diffvia Bash). - Run auto-formatters and the test suite. Check the Makefile (or equivalent) for formatting targets and run them first — names vary across repos (e.g.
make format-py,make fmt,make lint-fix). Stage any formatting changes. Then run the test suite (make testor equivalent). Fix any failures before proceeding. - Choose the appropriate type and optional scope
- Check for breaking changes (see above)
- Stage files (via MCP or
git add) - Commit using the conventional commit format — when the motivation isn't obvious, include a body explaining why, not just what
- If a breaking change, pass the migration instructions via the
breaking_changeparameter
PR Coherence: PRs are logical units. Before adding a commit to an existing branch, check whether it belongs there. If the changes are not logically related to the PR's existing scope, create a new branch and PR for them by default — do not bundle unrelated work into an existing PR unless the user explicitly asks you to.
Detailed Reference
Read the relevant reference file when needed:
- Creating a pull request (Steps 1–6, PR body format, rebase check, accuracy verification):
Read skills/git-workflow/references/pr-workflow.md - Updating a PR when adding commits to a branch with an open PR:
Read skills/git-workflow/references/open-pr-updates.md - Writing the test plan (Cases A, B, C):
Read skills/git-workflow/references/test-plan-guide.md - Sensitive content checks before committing (infrastructure details, OPSEC, credentials):
Read skills/git-workflow/references/sensitive-content-prevention.md
Related Skills
aldengolab/ubuntu-secureboot-pxe-netboot
development
VerifiedTrustedCommunity
Build a UEFI Secure Boot PXE netboot server for Ubuntu autoinstall. Use when: designing or implementing network boot infrastructure for automated Ubuntu provisioning with Secure Boot enabled. Covers the complete chain: signed shim+GRUB selection, TFTP layout, kernel parameters, autoinstall config requirements, and post-install bootstrapping scripts. Also applicable when debugging an existing PXE setup that uses the wrong GRUB binary or config paths.
SKILL.mdUpdated Apr 10, 2026
aldengolab/pxe-grub-persistent-server-pattern
development
VerifiedTrustedCommunity
Design pattern for running a persistent PXE/TFTP server that safely coexists with already-installed nodes. Use when: building PXE infrastructure that should stay always-on, designing automated bare-metal provisioning in GitOps/Kubernetes environments, or any PXE setup where UEFI boot order has network boot first. Eliminates boot loops without requiring UEFI firmware changes.
SKILL.mdUpdated Apr 10, 2026
aldengolab/orwell-clear-writing
development
VerifiedTrustedCommunity
This skill governs all prose output — Claude's own responses, documentation, PR descriptions, commit messages, README content, comments, and any text the user asks to draft or edit. It should also be used when the user asks to "review my writing", "edit this for clarity", "make this clearer", "simplify this text", "rewrite this", "check my prose", "tighten this up", or "make this more concise". Based on George Orwell's "Politics and the English Language" (1946).
SKILL.mdUpdated Apr 10, 2026
aldengolab/k8s-hostnetwork-port-conflict
development
VerifiedTrustedCommunity
Debug Kubernetes pods using hostNetwork: true that crash with "Address already in use" or "failed to create listening socket for port N". Use when: (1) a hostNetwork pod container is in CrashLoopBackOff and logs show a port bind failure, (2) the port works fine in non-hostNetwork pods but fails with hostNetwork, (3) you need to identify which host-level process holds a port from within Kubernetes (no SSH). Covers /proc/net/udp inspection and kubectl debug node with nsenter.
SKILL.mdUpdated Apr 10, 2026