Skip to content
skillsafebeta
← Report library
Purpose / Development

Git Workflow And Versioning Skill Security Audit

What the author says it does (original text)

Structures git workflow practices. Use when making any code change. Use when committing, branching, resolving conflicts, opening or reviewing a pull request (PR), pushing to a remote, or when you need to organize work across multiple parallel streams. Use when cutting a release, choosing a semantic version bump, tagging, or writing a changelog.

Independent security check

Do not install or run it yet

Files checked
1
Risks found
5
Could it run dangerous commands?Looks for programs run straight after downloading, remote control of your computer, and hidden commands.Risks found: 1
Medium risk

Mandatory npm commands execute repository-controlled code with the user’s privileges

Source references: 2
What we found

`npm test` and `npm run lint` execute scripts defined by the current repository’s `package.json`, which this Skill neither shows nor constrains. `npx tsc` may also resolve or obtain an executable package. Requiring these before every commit therefore runs code from a potentially unreviewed project.

Why this matters

A malicious or compromised project script could read or change files and credentials accessible to the user and, where permitted, use the network or launch other programs.

The “before every commit” instructions run `npm test` and `npm run lint`, which execute scripts defined by the current repository's package.json; those scripts are absent from the evidence. A malicious or compromised repository could thereby read or modify files or access credentials available to the agent's user. `npx` may also obtain and execute a package when no local command exists. Users can permit only reviewed, locked scripts in a restricted environment.

SKILL.md:211In the instructionsOpen original file
## Pre-Commit HygieneBefore every commit:```bash# 1. Check what you're about to commitgit diff --staged# 2. Ensure no secretsgit diff --staged | grep -i "password\|secret\|api_key\|token"# 3. Run testsnpm test# 4. Run lintingnpm run lint# 5. Run type checkingnpx tsc --noEmit```
Show 1 other places
SKILL.md:222In the instructionsOpen original file
# 3. Run testsnpm test# 4. Run lintingnpm run lint# 5. Run type checkingnpx tsc --noEmit```
Could it expose your files or keys?Looks for uploads of files containing passwords or keys, and keys written directly in the code.Risks found: 1
Medium risk

A narrow keyword search is presented as ensuring no secrets, which can wrongly approve exposed credentials

Source references: 2
What we found

The check searches only staged diff text for four English labels. It will miss keys with different names, unlabeled, encoded, or multiline values, and files not currently staged; nevertheless, the final checklist asks the agent to affirm that the diff contains no secrets, encouraging overconfidence.

Why this matters

Unmatched API keys, tokens, private keys, or passwords may enter a commit and become available to repository members or the public if later pushed.

The source labels a grep matching only `password|secret|api_key|token` as “Ensure no secrets,” then asks the checklist user to affirm that the diff contains none. It examines only staged text and can miss differently named, unlabeled, encoded, binary, or split credentials, creating false confidence. Users can require a dedicated secret scanner plus manual inspection of the complete staged diff before committing.

SKILL.md:216In the instructionsOpen original file
```bash# 1. Check what you're about to commitgit diff --staged# 2. Ensure no secretsgit diff --staged | grep -i "password\|secret\|api_key\|token"
Show 1 other places
SKILL.md:342In the instructionsOpen original file
For every commit:- [ ] Commit does one logical thing- [ ] Message explains the why, follows type conventions- [ ] Tests pass before committing- [ ] No secrets in the diff- [ ] No formatting-only changes mixed with behavior changes
Could it delete files or keep running?Looks for broad file deletion, disk overwrites, and programs set to start automatically.Risks found: 2
High risk

Recommended hard reset after a failed test can permanently discard the user’s uncommitted work

Source references: 2
What we found

The workflow prescribes reverting after test failure and explicitly recommends `git reset --hard HEAD`. That command overwrites the index and tracked working tree, removing uncommitted changes made after the current commit—including work belonging to the user or another tool, not merely the Skill’s latest increment.

Why this matters

Uncommitted changes to tracked files may become unrecoverable through normal Git operations, destroying work in progress.

This is active workflow guidance: failed tests lead to a revert, followed by an explicit recommendation of `git reset --hard HEAD`. If the index or working tree contains uncommitted changes to tracked files from the user, another tool, or parallel work, that command discards them; the source requires no ownership check or backup. Users should forbid hard reset unless the affected diff is shown and explicit approval is obtained.

SKILL.md:178In the instructionsOpen original file
    │    ├── Makes a change    │   ├── Test passes? → Commit → Continue    │   └── Test fails? → Revert to last commit → Investigate    │    ├── Makes another change    │   ├── Test passes? → Commit → Continue    │   └── Test fails? → Revert to last commit → Investigate    │
Show 1 other places
SKILL.md:189In the instructionsOpen original file
This pattern means you never lose more than one increment of work. If an agent goes off the rails, `git reset --hard HEAD` takes you back to the last successful state.
Medium risk

Broad automatic-commit rules may alter repository history without user authorization

Source references: 4
What we found

The Skill says it applies to every code change and requires each successful increment to be committed. A request to edit code does not necessarily authorize creating commits; a commit permanently records file content, identity metadata, and a message, and may include changes the user had already staged.

Why this matters

The repository can gain unwanted commits, incorrectly attributed or unrelated staged work can enter history, and later review, rebasing, or release work can be disrupted.

The Skill declares itself applicable to every code change and directs every successful increment to be committed, although an ordinary editing request may not authorize commits. A commit can include unrelated changes already staged by the user and record author identity and a message. Local commits are generally reversible, but they still alter repository history. Users can require explicit approval for commits and a full staged-diff review first.

SKILL.md:14In the instructionsOpen original file
Always. Every code change flows through git.
Show 3 other places
SKILL.md:34In the instructionsOpen original file
### 1. Commit Early, Commit OftenEach successful increment gets its own commit. Don't accumulate large uncommitted changes.```Work pattern:  Implement slice → Test → Verify → Commit → Next slice
SKILL.md:12In the instructionsOpen original file
## When to UseAlways. Every code change flows through git.
SKILL.md:38In the instructionsOpen original file
```Work pattern:  Implement slice → Test → Verify → Commit → Next slice
Could it bypass safety checks?Looks for skipped website security checks, excessive file access, or actions that skip your approval.Risks found: 1
Low risk

The install command does not pin a dependency version

Source references: 3
What we found

The installation command does not specify dependency versions. The same command may download different code later, so what you install can differ from what was checked.

Why this matters

A later install may download different code even though the command and this report have not changed.

What this evidence establishes

`npx tsc --noEmit` does not pin a version. If no suitable local binary exists, some npm/npx configurations may obtain and execute a package from a registry. The supplied source does not show the dependency lockfile, npm version, or an actual installation, so downloading is not established. Users can require a locked local TypeScript dependency and disable npx fetching of missing packages.

This assessment concerns the code and conditions shown, not proof that harm has occurred.
SKILL.md:229In the instructionsOpen original file
# 5. Run type checkingnpx tsc --noEmit```
Show 2 other places
SKILL.md:213In the instructionsOpen original file
Before every commit:
SKILL.md:228In the instructionsOpen original file
# 5. Run type checkingnpx tsc --noEmit```
Could it mislead the AI or hide text?Checks the skill instructions for requests to ignore you, influence the report, or hide text in invisible characters.No risks found
Could it change links or payment recipients without asking?Looks for forced referral or payment changes combined with instructions to hide the change.No risks found

Inside this skill

8 instruction sections

The Skill claims to apply to every code change and defines a recurring “implement, test, verify, commit” workflow, rather than limiting commits to cases where the user explicitly requested one.

View source
SKILL.md:3In the instructionsOpen original file
name: git-workflow-and-versioningdescription: Structures git workflow practices. Use when making any code change. Use when committing, branching, resolving conflicts, opening or reviewing a pull request (PR), pushing to a remote, or when you need to organize work across multiple parallel streams. Use when cutting a release, choosing a semantic version bump, tagging, or writing a changelog.---
SKILL.md:14In the instructionsOpen original file
Always. Every code change flows through git.
SKILL.md:36In the instructionsOpen original file
Each successful increment gets its own commit. Don't accumulate large uncommitted changes.
SKILL.md:39In the instructionsOpen original file
```Work pattern:  Implement slice → Test → Verify → Commit → Next slice

It recommends short-lived branches and Git worktrees in neighboring directories to isolate parallel work, followed by worktree removal.

View source
SKILL.md:149In the instructionsOpen original file
For parallel AI agent work, use git worktrees to run multiple branches simultaneously:```bash# Create a worktree for a feature branchgit worktree add ../project-feature-a feature/task-creationgit worktree add ../project-feature-b feature/user-settings
SKILL.md:163In the instructionsOpen original file
# When done, merge and clean upgit worktree remove ../project-feature-a```

Before every commit, it directs the agent to inspect staged changes, use a simple text match for secrets, and run project test, lint, and TypeScript commands.

View source
SKILL.md:213In the instructionsOpen original file
Before every commit:```bash# 1. Check what you're about to commitgit diff --staged# 2. Ensure no secretsgit diff --staged | grep -i "password\|secret\|api_key\|token"# 3. Run testsnpm test# 4. Run lintingnpm run lint# 5. Run type checkingnpx tsc --noEmit```

The release workflow includes creating an annotated Git tag and pushing it to origin, which changes remote repository state.

View source
SKILL.md:286In the instructionsOpen original file
### Tag the release, and let the tag be the source of truthA release is an immutable point in history, not a moving branch. Tag it so it can always be reproduced:```bashgit tag -a v1.4.0 -m "Release 1.4.0"git push origin v1.4.0```
Start here · InstructionsSKILL.md
git-workflow-and-versioning
Lines connect the instruction file to its sections, not an observed execution order. Select a section to read the source. 6 more sections are available in the original file.
Files and check records1 files

Coverage and gaps

Content covered in each file

These are the source ranges included in this check, not a guarantee that every issue has been resolved.

  • SKILL.mdFull text included

This report is for the version above. We read the available code and instructions without running the skill or checking extra packages it installs. This is not a promise of safety: a different version or setup may behave differently.

  • SKILL.mdInstructions

Operations mentioned in code and instructions

Run commands
SKILL.md:151In the instructionsOpen original file
```bash# Create a worktree for a feature branch
SKILL.md:215In the instructionsOpen original file
```bash# 1. Check what you're about to commit
SKILL.md:252In the instructionsOpen original file
```bash# Find which commit introduced a bug
Read keys or account settings
SKILL.md:220In the instructionsOpen original file
# 2. Ensure no secretsgit diff --staged | grep -i "password\|secret\|api_key\|token"
SKILL.md:247In the instructionsOpen original file
- **Commit generated files** only if the project expects them (e.g., `package-lock.json`, Prisma migrations)- **Don't commit** build output (`dist/`, `.next/`), environment files (`.env`), or IDE config (`.vscode/settings.json` unless shared)- **Have a `.gitignore`** that covers: `node_modules/`, `dist/`, `.env`, `.env.local`, `*.pem`
SKILL.md:248In the instructionsOpen original file
- **Don't commit** build output (`dist/`, `.next/`), environment files (`.env`), or IDE config (`.vscode/settings.json` unless shared)- **Have a `.gitignore`** that covers: `node_modules/`, `dist/`, `.env`, `.env.local`, `*.pem`
Install extra software packages
SKILL.md:229In the instructionsOpen original file
# 5. Run type checkingnpx tsc --noEmit```
Lines read
356
File checksum (to compare versions)
9777c444d65ec50adb4727cdbd8bdc32fda0a53b082469e35eb2bdc71f355afc