Git workflow

Skill MoeenNehzati/famulus/skills/git-workflow

Use when a task will edit a Git repository or the user asks to inspect or change Git state. Do not use solely because a read-only task happens inside a repository.From its SKILL.md

Install

npx -y skills add MoeenNehzati/famulus --skill git-workflow

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

2.7 KB, as published. Nobody here has run it

Generated from blueprint.yaml. Do not edit this block by hand.

Catalog: software-development; topics: repository-workflow; visibility: listed Activation: user-request, skill-workflow; persistent modifier: no

Skill Version: 2

Uses Interfaces: none

Public Interfaces:

git-workflow.interface.default

Generated from blueprint.yaml. Do not edit this block by hand.

Instruction Interfaces:

These interfaces are documented prompt surfaces. They are not executed through dispatcher:

git-workflow.interface.default — Check branch and ownership boundaries first, then perform only explicitly authorized and exactly scoped Git mutations.

Branch safety (always check first)

Before editing files in any repo, verify it is on a named branch:

git symbolic-ref HEAD

If this fails, the repo is in detached HEAD — check out a named branch before doing anything. Do not edit and then discover the work can't land.

At session start: run this in both the skills repo and the CWD repo (if any). If either is detached, check out the default branch first.

Commit rules

Never create commits, amend, or push unless explicitly asked.
When a stable checkpoint is reached (completed subsection, resolved issue, passing tests, finished feature), note that it may be a good time to commit — but do not act without approval.
When approved: help with staging specific files, drafting the commit message, and exact steps.

Change ownership

Unless the user explicitly says otherwise, interpret "changes" as the changes made in the current assistant session.
Before staging, committing, restoring, stashing, or otherwise modifying git state, distinguish current-session changes from pre-existing or unrelated dirty work.
Tell the user when unrelated dirty state exists, including the affected paths or areas at a useful level of detail.
Do not stage, commit, restore, revert, stash, or otherwise touch unrelated dirty state unless the user explicitly asks for that scope.
If ownership is ambiguous, ask before acting on the ambiguous paths.

Commit hygiene

Stage specific files by name; avoid git add -A or git add . (risk of including .env, credentials, or large binaries).
Never use --no-verify or --no-gpg-sign unless explicitly asked.
Never force-push to main/master; warn if asked.
Prefer new commits over amending, especially after a hook failure.