git-safety

Critical safety guardrails for protected branches: never commit, push, or force-push directly to main, latest, or release branches; no destructive history…

npx skills add https://github.com/redis/redisinsight --skill git-safety

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

More skills from redis

docs-sync
redis
Analyze master branch implementation and configuration to find missing, incorrect, or outdated documentation in docs/, README.md, and per-package READMEs. Use…
official
implement-command
redis
Add a new Redis command (or command variant) to node-redis end-to-end — the `<NAME>.ts` Command file, its registration with JSDoc in the package…
official
maintainer-review
redis
Review a GitHub issue or pull request URL as a node-redis maintainer, with a staged assessment of whether the claim is real, practically important, already…
official
pr-draft-summary
redis
Create the required PR-ready summary block, branch suggestion, title, and draft description for node-redis. Must be used before the final response whenever the…
official
runtime-behavior-probe
redis
Plan and execute runtime-behavior investigations with temporary TypeScript probe scripts, validation matrices, state controls, and findings-first reports. Use…
official
backend
redis
NestJS backend development patterns for the RedisInsight API: module structure, services, controllers, DTOs, dependency injection, and error handling. Use when…
official
branches
redis
Use lowercase kebab-case with type prefix and issue/ticket identifier. Branch names must match GitHub Actions workflow rules (see .github/workflows/enforce-branch-name-rules.yml ).
official
code-quality
redis
Code-quality standards for RedisInsight: TypeScript strictness, naming conventions (camelCase, PascalCase, UPPER_SNAKE_CASE), linting rules, no `any` without…
official