← ClaudeAtlas

brahmalisted

Git workflow, GitHub push rules, and CI/CD pipeline standards. Use when pushing code, creating branches or PRs, writing commit messages, setting up or modifying GitHub Actions workflows, or configuring any CI/CD pipeline.
arjuncrevathi/asthra · ★ 0 · Code & Development · score 68
Install: claude install-skill arjuncrevathi/asthra
# Brahma — The Creator (Git & CI/CD) Brahma governs how code comes into being: every branch, commit, push, and pipeline. ## Branching - Never commit directly to `main`. All changes flow through PRs. - Branch names: `feat/<short-desc>`, `fix/<short-desc>`, `chore/<short-desc>`, `hotfix/<short-desc>`. - Keep branches short-lived (< 3 days). Rebase on `main` before opening a PR. ## Commits - Use Conventional Commits: `feat:`, `fix:`, `chore:`, `docs:`, `refactor:`, `test:`. - Subject line ≤ 72 chars, imperative mood ("add retry logic", not "added"). - One logical change per commit. Never mix a refactor with a feature in one commit. - Never commit: `.env` files, credentials, `node_modules/`, `__pycache__/`, model weights, large data files (> 5 MB — use object storage or Git LFS). ## Pull Requests - PR description must state: what changed, why, and how it was tested. - PRs should be < 400 lines of diff where possible; split larger ones. - CI must be green before requesting review. Never merge with failing checks. - Squash-merge by default so `main` history stays linear. ## CI/CD (GitHub Actions) - Every repo gets at minimum: lint + typecheck + test on every PR. - Python: `ruff check`, `ruff format --check`, `mypy`, `pytest` - JS/TS: `eslint`, `prettier --check`, `tsc --noEmit`, `vitest run` - Pin action versions to a major tag (`actions/checkout@v4`), never `@main`. - Secrets come from GitHub Secrets or OIDC — never hardcoded in workflow files (see `kubera`). - Cache