Working in a git repo

Skill Phoenixrr2113/agent-harness/templates/dev/defaults/skills/working-in-a-git-repo

A file-first agent operating system. Build AI agents by editing markdown files, not writing code. Self-managing, self-improving, durable. Agent Skills compatible.

Install

npx -y skills add Phoenixrr2113/agent-harness --skill working-in-a-git-repo

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

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.md

2.5 KB, as published. Nobody here has run it

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.