git-safety

द्वारा redis

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

redis की और Skills

docs-sync
redis
मास्टर ब्रांच के कार्यान्वयन और कॉन्फ़िगरेशन का विश्लेषण करें ताकि docs/, README.md, और प्रति-पैकेज README में गायब, गलत, या पुराने दस्तावेज़ का पता लगाया जा सके। उपयोग करें…
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
GitHub issue या pull request URL की समीक्षा node-redis अनुरक्षक के रूप में करें, जिसमें यह चरणबद्ध मूल्यांकन हो कि दावा वास्तविक है, व्यावहारिक रूप से महत्वपूर्ण है, पहले से...
official
pr-draft-summary
redis
node-redis के लिए आवश्यक PR-तैयार सारांश ब्लॉक, शाखा सुझाव, शीर्षक और ड्राफ्ट विवरण बनाएं। इसका उपयोग अंतिम प्रतिक्रिया से पहले किया जाना चाहिए जब भी...
official
runtime-behavior-probe
redis
रनटाइम व्यवहार जांच की योजना बनाएं और अस्थायी TypeScript प्रोब स्क्रिप्ट, सत्यापन मैट्रिक्स, स्थिति नियंत्रण और निष्कर्ष-प्रथम रिपोर्ट के साथ उन्हें क्रियान्वित करें। उपयोग करें…
official
backend
redis
NestJS बैकएंड विकास पैटर्न RedisInsight API के लिए: मॉड्यूल संरचना, सेवाएँ, नियंत्रक, DTO, निर्भरता इंजेक्शन, और त्रुटि प्रबंधन। उपयोग करें जब...
official
branches
redis
लोअरकेस केबब-केस का उपयोग करें, जिसमें टाइप प्रीफिक्स और इश्यू/टिकट आइडेंटिफायर हो। ब्रांच नाम GitHub Actions वर्कफ़्लो नियमों से मेल खाने चाहिए (.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