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.
- License 许可
- MIT
- 最近更新
- 2026-04-30
- Stars
- ★ 1
- Forks
- 2
01 前言 Front Matter
- name
- working-in-a-git-repo
- metadata
- { "harness-tags": "skill, workflow, git, dev", "harness-author": "human", "harness-status": "active", "harness-created": "2026-04-21", "harness-updated": "2026-04-30" }
- description
- 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.
- allowed-tools
- Bash Read Edit
03 SKILL.md 正文
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$HOMEthat isn't in the worktree.
4. Commit discipline
- Branch name:
<type>/<slug>, kebab-case. - Commit message: follow project style.
git log --oneline -20to 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 statusshows 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.
04 同仓库更多 Skills
research
Conduct research.
{{NAME=null}=null}
Briefly describe what this skill does AND when to use it. Use imperative phrasing ("Use this skill when..."). Aim for 80-500 chars. Include keywords the model can pattern-match against the user's prompt.
test-runner
Runs the project's test suite (or a targeted subset), parses the output, and reports pass/fail with failing-test details. Use when you need to know test status; call with the test command to run, or leave blank for the project default.
reviewer
Reviews a diff or change set for bugs, security issues, test gaps, and style. Use when evaluating a code change, reviewing a pull request, or running a structured review pass before merge.
fix-failing-tests
Seven-step flow for diagnosing and fixing failing tests. Use when the user asks to fix failing tests, green the suite, or says 'tests are red' — works through reproduce → read → root-cause → propose → apply → verify → commit.
writing-plans
Use when you have a spec or requirements for a multi-step task, before touching code