How do I install the Brahma skill?

Run npx skillmds@latest add arjuncrevathi/brahma in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Brahma safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Brahma?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Brahma free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Brahma?

arjuncrevathi (@arjuncrevathi) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Brahma by arjuncrevathi — Agent Skill

Name: Brahma
Author: arjuncrevathi

Brahma

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.

File contents

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 dependencies (actions/cache for pip/uv, setup-node built-in cache for npm/pnpm).
Deploys run only from main (or tags), gated behind passing tests.
Fail fast: put the cheapest checks (lint) first in the pipeline.

AI-native specifics

LLM eval suites run in CI on PRs that touch prompts or model config (see agni).
Prompt templates are code: version them in the repo, review changes via PR.

Before every push — checklist

No secrets or .env in the diff (git diff --staged and check)
Lint, typecheck, tests pass locally
Commit messages follow Conventional Commits
Branch is rebased on latest main

---name: brahmadescription: 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.---# 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 dependencies (`actions/cache` for pip/uv, `setup-node` built-in cache for npm/pnpm).- Deploys run only from `main` (or tags), gated behind passing tests.- Fail fast: put the cheapest checks (lint) first in the pipeline.## AI-native specifics- LLM eval suites run in CI on PRs that touch prompts or model config (see `agni`).- Prompt templates are code: version them in the repo, review changes via PR.## Before every push — checklist- [ ] No secrets or `.env` in the diff (`git diff --staged` and check)- [ ] Lint, typecheck, tests pass locally- [ ] Commit messages follow Conventional Commits- [ ] Branch is rebased on latest `main`

Frequently asked questions