CtrlK
BlogDocsLog inGet started
Tessl Logo

git-safety

Critical safety guardrails for protected branches: never commit, push, or force-push directly to main, latest, or release branches; no destructive history rewrites without explicit user approval. Use before any git operation that touches protected branches, before force-push, reset --hard, history rewrite, or branch deletion, or whenever the user asks about merging, pushing, or release branches.

68

Quality

83%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Passed

No findings from the security scan

SKILL.md
Quality
Evals
Security

Git Safety Rules for AI Agents

🚫 CRITICAL: Protected Branch Rules

AI agents must NEVER commit to or push to protected branches under any circumstances.

Protected Branches

  • main - Primary production branch
  • latest - Latest stable release
  • release/* - Release branches (e.g., release/v2.0.0)

This is a non-negotiable rule that applies to all scenarios:

Prohibited Actions

  • Direct commits - Never run git commit while on a protected branch
  • Direct pushes - Never run git push origin <protected-branch> or git push while on a protected branch
  • Force pushes - Never run git push --force or git push -f targeting protected branches
  • Merging into protected branches locally - Never run git merge <branch> while on a protected branch
  • Rebasing protected branches - Never run git rebase while on a protected branch
  • Resetting protected branches - Never run git reset while on a protected branch

Required Workflow

  1. Always create a feature branch before making any changes
  2. Verify current branch before any git operation using git branch --show-current
  3. Create Pull Requests for all changes - let the review process handle merging

Pre-Push Checklist

Before executing any push command, AI agents must:

  1. ✅ Confirm current branch is NOT a protected branch (main, latest, release/*)
  2. ✅ Verify the remote and branch target

Error Recovery

If accidentally on a protected branch with uncommitted changes:

  1. Stash changes: git stash
  2. Create new branch: git checkout -b <appropriate-branch-name>
  3. Apply changes: git stash pop
  4. Continue work on the new branch

Rationale

  • Protected branches represent production-ready or release code
  • All changes must go through code review via Pull Requests
  • Direct pushes bypass CI/CD checks and team review
  • Mistakes on protected branches can affect the entire team and deployment pipeline
Repository
redis/RedisInsight
Last updated
First committed

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.