How do I install the Working In A Git Repo skill?

Run npx skillmds@latest add phoenixrr2113/working-in-a-git-repo 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 Working In A Git Repo 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 Working In A Git Repo?

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 Working In A Git Repo free to use?

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

Who published Working In A Git Repo?

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

Working In A Git Repo by phoenixrr2113

Name: Working In A Git Repo
Author: Phoenixrr2113

Working In A Git Repo

Operating manual for dev work: worktree discipline, build/test/lint commands, file ownership zones, commit style, and a verification checklist before reporting done. Use when starting any feature/fix work in this repo.

Phoenixrr2113 Updated Sep 17, 2026

File contents

Skill: Working in a Git Repo

I am a development agent. I never edit the main checkout directly. All work happens in a git worktree.

1. Always work in a git worktree

Before writing any code, ensure I have been given (or can create) a worktree:

cd <repo-root>
git worktree add -b <type>/<short-slug> \
  <repo-root>-worktrees/<short-slug> <base-branch>
cd <repo-root>-worktrees/<short-slug>

Branch type prefixes: fix/, feat/, chore/, docs/, test/.

First time in a worktree, run whatever setup the project needs (typically npm install, pnpm install, uv sync, bundle install, etc.).

2. Build, test, lint

Check the project's package.json / Makefile / justfile for the actual commands. Common patterns:

npm run build          # or: pnpm build, make build
npm test               # or: pnpm test, cargo test, pytest, go test ./...
npm run lint           # or: pnpm lint, ruff check, cargo clippy

Identify the commands from the project itself. Do not assume.

3. File ownership

Writable: anything inside my worktree, under source directories (src/, tests/, docs/, etc.) that the project treats as authored content.
Read-only: node_modules/, dist/, build/, .git/, vendored deps.
Forbidden: anything outside the worktree. Any .env* file. Any file in $HOME that isn't in the worktree.

4. Commit discipline

Branch name: <type>/<slug>, kebab-case.
Commit message: follow project style. git log --oneline -20 to see.
One commit per logical change.
Never --no-verify.
Never force-push.
Never amend a pushed commit.

5. Verification before reporting "done"

Before I tell the human a task is complete, all of these must be true:

Linter passes.
Full or targeted test suite passes.
git status shows only files I intended to change.
A commit exists on the feature branch. I know the SHA and branch name.

I report: branch name, commit SHA, list of files changed, one-line summary. I do NOT push. I do NOT open a PR. I do NOT merge. The human decides next.

---name: working-in-a-git-repodescription: Operating manual for dev work: worktree discipline, build/test/lint commands, file ownership zones, commit style, and a verification checklist before reporting done. Use when starting any feature/fix work in this repo.---# Skill: Working in a Git RepoI am a development agent. I never edit the main checkout directly. All workhappens in a git worktree.## 1. Always work in a git worktreeBefore writing any code, ensure I have been given (or can create) a worktree:```bashcd <repo-root>git worktree add -b <type>/<short-slug> \ <repo-root>-worktrees/<short-slug> <base-branch>cd <repo-root>-worktrees/<short-slug>```Branch type prefixes: `fix/`, `feat/`, `chore/`, `docs/`, `test/`.First time in a worktree, run whatever setup the project needs (typically`npm install`, `pnpm install`, `uv sync`, `bundle install`, etc.).## 2. Build, test, lintCheck the project's `package.json` / `Makefile` / `justfile` for the actualcommands. Common patterns:```bashnpm run build # or: pnpm build, make buildnpm test # or: pnpm test, cargo test, pytest, go test ./...npm run lint # or: pnpm lint, ruff check, cargo clippy```Identify the commands from the project itself. Do not assume.## 3. File ownership- **Writable:** anything inside my worktree, under source directories (`src/`, `tests/`, `docs/`, etc.) that the project treats as authored content.- **Read-only:** `node_modules/`, `dist/`, `build/`, `.git/`, vendored deps.- **Forbidden:** anything outside the worktree. Any `.env*` file. Any file in `$HOME` that isn't in the worktree.## 4. Commit discipline- Branch name: `<type>/<slug>`, kebab-case.- Commit message: follow project style. `git log --oneline -20` to see.- One commit per logical change.- Never `--no-verify`.- Never force-push.- Never amend a pushed commit.## 5. Verification before reporting "done"Before I tell the human a task is complete, all of these must be true:1. Linter passes.2. Full or targeted test suite passes.3. `git status` shows only files I intended to change.4. A commit exists on the feature branch. I know the SHA and branch name.I report: branch name, commit SHA, list of files changed, one-line summary.I do NOT push. I do NOT open a PR. I do NOT merge. The human decides next.

Frequently asked questions