git-workflow 100/100 — SaferSkills

Is git-workflow safe to install?

SaferSkills independently audited git-workflow (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.

CategoryWeightCategory scoreContribution

Securityprompt, exec, net, exfil, eval

35%

100

35.0 pts

Supply chainhash, typosquat, maintainer, lockfile

20%

100

20.0 pts

Maintenancestaleness, pinning, CI

15%

100

15.0 pts

TransparencySKILL.md, perms, README

15%

100

15.0 pts

Communityinstalls, verify, response

15%

100

15.0 pts

Findings & checks · 0 flagged

Securityscore 100 · 0 findings

✓—All security checks passedNo findings in this category for the latest scan.pass

Supply chainscore 100 · 0 findings

✓—All supply chain checks passedNo findings in this category for the latest scan.pass

Maintenancescore 100 · 0 findings

✓—All maintenance checks passedNo findings in this category for the latest scan.pass

Transparencyscore 100 · 0 findings

✓—All transparency checks passedNo findings in this category for the latest scan.pass

Communityscore 100 · 0 findings

✓—All community checks passedNo findings in this category for the latest scan.pass

The primary manifest — the file an agent reads to learn what this artifact does.

skills/git-workflow/SKILL.md · 1 file

skills/git-workflow/SKILL.md2.6 KB · Markdown

name: git-workflow

description: Trunk-based development with atomic commits, clean history, and meaningful commit messages. Every commit should be deployable.

category: ship

applies-to: [claude, gemini, cursor, copilot, any]

version: 1.0.0

Overview

Git is not just a backup system — it's a communication tool. Clean git history enables fast debugging (git bisect), clear attribution, and safe reverts. This skill enforces atomic commits, meaningful messages, and trunk-based development.

When to Use

Before making any commit
When reviewing a PR's git history
When setting up a new project

Process

Step 1: Atomic Commits

Each commit should represent ONE logical change — not a day's worth of work.
A commit should be: independently deployable, independently revertable.
Never commit "WIP" or partial implementations.

Verify: You could revert this commit without affecting adjacent functionality.

Step 2: Commit Message Format

Follow Conventional Commits:

   type(scope): short summary (max 72 chars)
   
   Body: what changed and WHY (not how — the diff shows how).
   
   Closes: #issue-number

Types: feat, fix, docs, style, refactor, test, chore
The summary is imperative mood: "Add feature" not "Added feature"

Verify: Message passes: feat|fix|docs|...(<scope>): <summary> format.

Step 3: Trunk-Based Development

Work directly on main for small changes (<1 day of work).
For larger features: short-lived feature branches (max 2 days), frequent merges to main.
Never let a branch live more than 3 days without merging or rebasing.
Use feature flags for incomplete features, not long-lived branches.

Verify: No branch is more than 2 days old without a merge/rebase plan.

Step 4: Pre-Commit Gates

Before every commit: tests pass, linter passes, no secrets in diff.
Use pre-commit hooks to enforce automatically.

Common Rationalizations (and Rebuttals)

Excuse	Rebuttal
"I'll clean up the commits later"	You won't. Clean as you go.
"The commit message doesn't matter"	It matters in 6 months when you're bisecting a production bug.
"Feature branches protect main"	Long-lived branches cause merge nightmares. Trunk-based is safer.

Verification

[ ] Commits are atomic and independently deployable
[ ] Commit messages follow Conventional Commits format
[ ] No long-lived branches (> 3 days)
[ ] Pre-commit hooks in place

git-workflow— agent skill

Is git-workflow safe to install?

Overview

When to Use

Process

Step 1: Atomic Commits

Step 2: Commit Message Format

Step 3: Trunk-Based Development

Step 4: Pre-Commit Gates

Common Rationalizations (and Rebuttals)

Verification

References

Audit the pieces. Scan the whole. Decide.