Branching
Portable engineering policies for coding agents — git, testing, logging, and language conventions written once and referenced everywhere
npx -y skills add andr-ca/agentharness --skill branchingAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 25 days oldThe repository was created 25 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 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
Use when creating a branch, naming it, deciding whether to use a worktree, or handling secrets accidentally committed to history — branch naming convention, trunk protection, and secrets-removal procedure.
SKILL.md
3.2 KB, as published. Nobody here has run it
Branching
Full reference: .github/BRANCHING_STRATEGY.md (worktree deep-dive,
.gitignore policy, lifecycle walkthrough). This skill is the actionable
summary.
The core rule
Never commit directly to main/master/trunk/develop/production/
release/*. Always: branch → commit → push → PR → merge. This repo
enforces it locally via git config core.hooksPath .github/hooks
(already set here) — don't rely on the admin bypass.
Branch naming
{type}/{description}, lowercase, hyphens not underscores, short and
specific.
| Type | Purpose |
|---|---|
feature/ | New feature or enhancement |
fix/ | Bug fix |
refactor/ | No behavior change |
test/ | Testing improvements |
docs/ | Documentation only |
chore/ | Maintenance, deps, config |
perf/ | Performance improvement |
ci/ | CI/CD changes |
Good: feature/user-authentication, fix/email-validation-crash.
Bad: update, Feature/UserAuth, fix_everything.
Worktrees
A worktree is a second working directory backed by the same repo, so you can have several branches checked out at once without stashing or re-cloning.
Reach for one when:
- Running long tests/builds on one branch while you keep coding another.
- Reviewing a PR branch without disturbing your in-progress work.
- Running agents in parallel — give each agent/task its own worktree so concurrent runs never fight over one working tree or index. This is the highest-value case for an agent harness.
Skip it for a single quick edit — a plain branch switch is cheaper.
The rules that bite:
- One branch per worktree — git refuses to check the same branch out in two worktrees at once.
- Keep them in
.worktrees/{branch-name}/(gitignored — it's in.github/.gitignore.template), not scattered sibling directories. - Hooks are shared by default — worktrees share one
.gitconfig andcore.hooksPath, so trunk protection and the pre-push hook apply in all of them; you won't accidentally sidestep them by moving to a worktree (short of deliberately enabling per-worktree config). - Remove with git, not
rm -rf—git worktree remove <dir>(orgit worktree pruneif you already deleted it by hand), so git's bookkeeping stays consistent.
Full mechanics (submodule caveat, cleanup): .github/BRANCHING_STRATEGY.md.
If a secret was committed
Act immediately — rotate the secret regardless of whether history cleanup succeeds; treat anything that touched git history as compromised.
- Preferred: BFG Repo Cleaner
on a fresh mirror clone:
bfg --delete-files .envthengit push --force. See.github/BRANCHING_STRATEGY.mdfor the full command sequence. - Fallback:
git filter-repo --path .env --invert-paths(the modern, maintained replacement forfilter-branch). - Rotate the secret. Tell everyone with a clone to re-clone, not pull.