You're working in a shared repo. You don't want to accidentally overwrite someone else's work, commit to the wrong branch, or push something that breaks the team.
Zenith handles all of that. You describe what you want in plain English — it does the git operations safely.
/zenith start new feature for the login page
/zenith save my work "add input validation"
/zenith push
Alice is on the ML team. She edits her model training code and types:
/zenith push my changes
Zenith checks she's not on main. Confirms she only touched files in her folder. Syncs with the latest code from the team. Opens a PR. She never runs a git command.
Meanwhile, if she had accidentally edited a file in the payments team's folder, Zenith would have caught it and asked what to do before committing anything.
You can. But you'll end up doing this every time:
"Please commit my changes — but first check I'm not on main, make sure I haven't touched anything outside team-ml/recommendations, sync with the latest main, then push and open a PR."
And Claude might do it differently each session. It might forget the contamination check. It doesn't know your folder, your org, or your base branch unless you tell it.
Zenith is pre-configured with that context. It runs the same sequence every time, not based on how you phrase the request.
| Raw Claude Code | Zenith | |
|---|---|---|
| Knows your folder | You tell it each time | Pre-configured |
| Knows your repo/org | You tell it each time | Pre-configured |
| Safety checks | Run if you ask | Run every time |
| Push sequence | Depends on your prompt | Always: commit → check scope → sync → push → PR |
| Consistency | Varies by session | Deterministic |
| Catches commits to main | No | Yes — warns on startup |
| Catches shared file edits | No | Yes — contamination check |
| Catches large staged sets | No | Yes — pauses at >50 files |
| Learns your workflow patterns | No | Yes — nudges before operations you keep getting wrong |
| Catches hardcoded local paths | No | Yes — scans diff content |
| Catches root-level dep changes | No | Yes — flags regardless of project_folder |
/zenith push does the same thing every time. It's closer to a CLI command than a conversation.
→ How it works at the team level
Shared monorepos — multiple people in one repo, each owning a subfolder:
company-repo/
├── team-payments/
│ └── checkout-service/ ← Alice's work lives here
├── team-ml/
│ └── recommendations/ ← Bob's work lives here
└── platform/
└── infra/ ← Carol's work lives here
Zenith knows which folder is yours. It only commits your files, warns you if anything else changed, and blocks operations that could affect your teammates.
Solo or small-team repos — you own the whole thing, but you still want safe branching, automatic syncing, and PR workflows without thinking about git commands.
→ Full safety rules and what Zenith catches
- git 2.23 or later — run
git --versionto check - GitHub CLI (gh) — run
gh --versionto check; install withbrew install ghthengh auth login - A GitHub repo you have push access to
- macOS or Linux
- Claude Code — if using
/zenithin Claude Code - Cursor — if using
@zenithin Cursor (any model works)
Zenith follows the open agent skills standard. Any compatible runtime can install it with one command:
git clone https://github.com/kpatel513/zenith ~/.agents/skills/zenithThe runtime reads ZENITH.md from the cloned directory. No setup script required.
Run this from your terminal — anywhere:
curl -fsSL https://raw.githubusercontent.com/kpatel513/zenith/main/scripts/setup.sh | bashThis installs Zenith to ~/.zenith and asks two questions:
GitHub username: [your github username]
Install Cursor rule? [y/N]: [y if you use Cursor, N otherwise]
That's it. Zenith is installed globally. You don't configure repos here — that happens automatically the first time you use /zenith or @zenith in each repo.
Open Claude Code from inside any repo and run any /zenith command:
/zenith start new work
If this is the first time Zenith has been used in that repo, it detects there's no config and walks you through 4 quick questions before continuing:
first-time setup — no config found for this repo
│ detected: /Users/alice/code/company-repo
│ answering 4 questions configures Zenith for this repo permanently
│ your answers are saved locally and never committed to GitHub
Your project folder (or . for whole repo): team-ml/recommendations
GitHub organization: acme-corp
GitHub repository: company-repo
Base branch [main]: main
✓ config saved /Users/alice/code/company-repo/.agent-config
✓ gitignore .agent-config will not be committed
From that point on, /zenith in that repo reads the saved config and runs without asking again.
Adding a new repo later? Just open Claude Code in that repo and run any /zenith command — same first-time setup.
Verify it worked
Open Claude Code (from any directory) and run:
/zenith help
You'll see a table of everything Zenith can do.
What setup does
- Installs Zenith to
~/.zenithon your machine - Creates
~/.claude/commands/zenith.md— makes/zenithavailable in every Claude Code session - Creates
~/.cursor/rules/zenith.mdc(if you opt in) — makes@zenithavailable in every Cursor session - Writes
~/.zenith/.global-configwith your GitHub username — pre-fills it for every repo you configure - Installs a daily background update so you always have the latest version
New machine or reinstalling? The setup script is safe to re-run. To change your username after setup, edit ~/.zenith/.global-config directly.
Works via @zenith. Run setup.sh and answer y to the Cursor prompt — that's it. Already installed? One-liner to add Cursor support manually.
→ Full Cursor setup and model compatibility
You don't have to memorize exact phrases. Zenith understands intent.
| Say this | What happens |
|---|---|
start new feature |
Creates a branch from main, pushes it, tells you where to work |
continue my work |
Shows your recent branches, switches to the one you pick |
work on their branch |
Checks out a teammate's branch and shows recent activity |
what did I change |
Shows your uncommitted changes scoped to your folder |
scope check |
Verifies you haven't changed files outside your folder |
what's staged |
Shows what's queued for the next commit |
save my work |
Commits your changes after a safety check |
sync with main |
Brings your branch up to date with the team's latest code |
push |
Commits (if needed), syncs, pushes, and shows the PR link |
draft PR |
Pushes as a draft PR — starts CI without requesting review |
update my PR |
Adds new commits to an existing open PR |
CI failed |
Shows which step failed and links to the logs |
PR has conflicts |
Walks you through resolving a merge conflict blocking your PR |
how behind am I |
Lists commits on main you don't have yet |
what changed today |
Shows what teammates pushed to main recently |
status |
Shows your branch, PR state, and pending changes in one view |
undo last commit |
Removes the last commit, keeps your changes unstaged |
throw away changes |
Permanently discards all uncommitted changes |
forgot a file |
Adds a missed file to your last commit |
remove file from commit |
Removes a file from the last commit, leaves it unstaged |
fix commit message |
Corrects the message on your last commit |
split commits |
Separates staged changes into two commits |
unstage a file |
Removes a file from the staging area |
push failed |
Diagnoses why push was rejected and fixes it |
I merged the PR |
Syncs your branch after a PR is merged, retargets stacked branches |
clean up history |
Removes merge commits, replays your commits cleanly onto main |
move my commits |
Cherry-picks commits to the correct branch and removes them from this one |
unstash |
Restores changes saved by a previous stash |
clean up branches |
Deletes your old merged branches |
show my stack |
Shows every branch in your stack with PR status and CI state |
run checks |
Runs pre-commit hooks against your changed files and reports pass/fail per hook |
review my PR |
Three-pass review using git history, docs, config, and code structure (Layers 1–6) |
deep review my PR |
Same review with full context: adds PR history, open PR conflicts, past reviewer patterns (Layers 1–9) |
review PR 123 |
Three-pass review for a teammate's PR (Layers 1–6) |
deep review PR 123 |
Full-context review for a teammate's PR (Layers 1–9) |
check gitignore |
Audits .gitignore changes for rules that silently break other teams' folders |
cherry-pick a fix |
Safely applies a specific commit from another branch, scoped to your folder with contamination check |
find duplicates |
Searches the repo for similar filenames, classes, or functions before you build something that already exists |
blast radius |
Shows every file in the repo that imports or references what you changed — surface cross-team impact before you push |
conflict radar |
Shows open PRs that touch the same files as your current changes — surface conflicts before they happen |
open worktree |
Checks out a branch in a new directory so you can work on two branches simultaneously without stashing |
list worktrees |
Shows all active worktrees and their paths |
remove worktree |
Deletes a linked worktree directory (branch is not deleted) |
help |
Shows this table |
When change B depends on change A and both need separate PRs, use a stack. Run start new work from an existing feature branch — Zenith asks whether to branch from main or stack on top. The stack is managed locally and never committed.
Zenith runs a three-pass adversarial review — designed to behave like a skeptical principal engineer, not a helpful assistant. Two tiers:
review/review PR 123— Layers 1–6, fast, good for pre-submit checksdeep review/deep review PR 123— Layers 1–9, adds PR history, open PR conflicts, and past reviewer patterns
reviewing — feature/add-rate-limiter
│ CI: ✓ base: main +84 -12
── what it does ────────────────────────────────────────
│ • Adds a token bucket rate limiter to the API gateway
│ • Stores per-user token counts in Redis with a 60s TTL
│ • Returns 429 with Retry-After header when limit exceeded
── signals ─────────────────────────────────────────────
│ volatile src/middleware/auth.js — 18 commits, 2 reverts
│ duplicate RateLimiter already exists at src/utils/throttle.js
│ conflict PR #41 (bob) also touches src/middleware/auth.js
── concerns ────────────────────────────────────────────
│ P1 auth.js line 47: Redis client initialized per-request.
│ failure: Pool exhaustion under load.
│ alternative: Initialize once at module load.
│ question: What is the expected RPS?
verdict MERGE AFTER FIXES
→ Three-pass review details, signal definitions, and team context file
Zenith tracks your workflow events and surfaces nudges when a mistake recurs — before the operation that would repeat it. Nudges appear inline in the confirmation prompt and fade as your habits improve. Nothing to configure — it observes automatically.
→ How pattern tracking works, tracked patterns, and examples
Claude Code sees the whole codebase and makes reasonable calls — but it doesn't know your monorepo conventions. Zenith intercepts at commit and push time to catch scope violations, generated files, hardcoded paths, and conflict resolutions that silently discard correct code.
→ Full list of what Zenith catches from Claude Code
After first use in a repo, .agent-config lives at your repo root. It is never committed to GitHub — Zenith automatically adds it to .gitignore. Each team member gets their own private copy.
[repo]
github_org = "acme-corp"
github_repo = "company-repo"
base_branch = "main"
[user]
project_folder = "team-ml/recommendations"
github_username = "alice"Edit this file any time to update your settings.
Zenith updates itself. A background job runs once a day:
0 9 * * * cd ~/.zenith && git pull origin main --quiet
Nothing to maintain.
~/.zenith/scripts/uninstall.shThis removes the global symlink, the cron job, and the ~/.zenith directory. Your per-repo .agent-config files are not touched — remove them manually if you want:
rm /path/to/repo/.agent-config/zenith not recognized in Claude Code
Run ls ~/.claude/commands/zenith.md to check if the global symlink exists. If it's missing, re-run the install command.
@zenith not appearing in Cursor
Run ls ~/.cursor/rules/zenith.mdc to check if the rule is installed. If it's missing, run:
mkdir -p ~/.cursor/rules && ln -s ~/.zenith/.cursor/rules/zenith.mdc ~/.cursor/rules/zenith.mdcThen open Cursor Settings → Rules and confirm zenith appears with alwaysApply: false.
First-time setup not appearing
Make sure you're opening Claude Code from inside a git repository. Zenith detects the repo automatically — it won't run if there's no .git/ folder in the tree.
Push rejected
Run /zenith push failed. Zenith will diagnose and fix the most common causes.
Your folder warning on startup
If Zenith warns that your project_folder doesn't exist, edit .agent-config at your repo root and correct the path.
Open an issue for bugs or feature requests. PRs welcome.
MIT