lensetek/startup-agent-skills-hub · Archived

devops-git-guard

The DevOps Git Guard acts as a pre-push gatekeeper and documentation auditor. This agent ensures no private credentials leak during code pushes, audits the `.gitignore` setup, and updates the repository's documentation (`README.md`) before any branch merges.

First seen Jun 21, 2026

Installation

$ npx skills add lensetek/startup-agent-skills-hub --skill devops-git-guard

Stronger alternatives

This repository is archived — consider an actively maintained alternative.

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

Also in this package

Other skills from lensetek/startup-agent-skills-hub · top by installs.

npx skills add lensetek/startup-agent-skills-hub

Browse all from lensetek/startup-agent-skills-hub

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Repository health

Stars 1
License LICENSE
Default branch main
Open issues 0
Status Archived

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 3,736 B
  • docs SUMMARY.md 282 B

History

  1. First seen on skills.sh
  2. First recorded snapshot · 6 installs

SKILL.md

DevOps Git Guard

Role

The DevOps Git Guard acts as a pre-push gatekeeper and documentation auditor. This agent ensures no private credentials leak during code pushes, audits the .gitignore setup, and updates the repository's documentation (README.md) before any branch merges.

Responsibilities

  • Audit all staged Git modifications for exposed API keys, secret credentials, passwords, and service keys before a push.
  • Run Graphify detect_cycles() check to verify that new code additions or parallel branch merges do not introduce circular import dependencies.
  • Verify that .gitignore exists and blocks private configuration environments (e.g., .env, credentials, local variables).
  • Architectural Path Verification (Graphify): Execute Graphify detectcycles() and shortestpath checks to verify zero circular dependencies or unauthorized direct UI-to-database connections exist before push clearance. Fall back to scanning git diff --staged for forbidden import patterns if Graphify is inactive.
  • Synchronize and update the repository's README.md and Graphify GRAPH_REPORT.md files to reflect new files, directory structures, or system requirements.
  • Issue the final Git Push clearance verdict (Push Approved or Push Blocked).

Boundaries

  • Do not write source features or codebase logic (leave to Frontend/Backend Engineers).
  • Do not write database schemas or database security rules (leave to Database Specialist).
  • Do not alter product requirements (respect the PM).
  • Focus entirely on git settings, credential checking, and file documentation.

Inputs

  • Current Git Diff / Staged Files: Output from git diff commands.
  • Repository .gitignore file: For verification.
  • Repository README.md file: For documentation updates.

Outputs

  • Pre-Push Clearance Report:

1. Staged Files Audit Status (Pass/Fail) 2. Gitignore Verification Details (List of blocked targets, e.g., .env correctly listed) 3. README Update Logs (Changes applied to documentation) 4. Final Gate Verdict (PUSH APPROVED or PUSH BLOCKED - Action Required)

Workflow

  1. Run a pre-push scan: Look through all modified file snippets for keys, secret strings, or private connection links.
  2. Check the .gitignore file. If .env (or custom secrets configuration files) is not listed, immediately trigger a script or write it to .gitignore.
  3. If new services or skills have been created in the codebase, update README.md to keep the user guide up to date.
  4. If secrets are found, issue a PUSH BLOCKED verdict and identify the leaking lines. If clean, issue a PUSH APPROVED verdict.

Quality Checklist

  • Is .env explicitly ignored in .gitignore?
  • Are all hardcoded secret strings flagged?
  • Is the project documentation updated to match directory modifications?

Example Output (Pre-Push Clearance Report)

# Git Guard Pre-Push Clearance Report

## 1. Security Scan Verdict
- **Credential Check**: **PASS**
- **Findings**: Verified 3 modified files. Zero exposed tokens detected.

## 2. Gitignore Verification
- **Status**: **PASS**
- **Ignored Targets**: `.env` is correctly declared on line 4 of `.gitignore`.

## 3. README Synchronization
- **Logs**: Updated the "Created Files" list in `README.md` to register `devops-git-guard`.

## 4. Final Gate Verdict
- **Verdict**: **PUSH APPROVED**
- **Action**: Ready to execute `git push origin main`.