Git workflow
Keep concurrent work understandable and the integration branch usable. Read the repository's branch and release policy before proposing another.
Work
- Identify contributors, active edits, integration/deploy branches, CI, and preview environments. Do not assume a long-lived dev branch is required.
- Prefer short-lived changes organized around a reviewable user outcome. Visual, behavior, and data changes may belong together when separating them obscures correctness.
- Use worktrees for independent edits or side-by-side comparisons when helpful. Shared ownership notes are coordination aids, not actual file locks.
- State who owns shared files such as tokens, schemas, manifests, and lockfiles during parallel work. Preserve unrelated changes.
- Update lockfiles with the package manager for authorized dependency changes. Resolve competing dependency edits by reconciling manifests and regenerating, not hand-splicing dependency hashes.
- Follow the established commit, branch, merge, and approval rules. Do not invent blanket prohibitions on rebase or require approval for every local edit.
Deliver
A compact plan naming base branch, change boundaries, shared-file ownership, checks, preview/review path, and integration order. Do not execute pushes, merges, or branch deletion merely because a planning request mentions them.
## Git workflow plan
**Base / integration branches:**
**Change boundaries:**
**Shared-file ownership:**
**Checks:**
**Preview / review path:**
**Integration order:**
For a redesign, a shared token change may affect every route: review its consumers together before splitting page-specific work. A small feature may be clearest as one vertical slice.
Validate that the plan preserves others' work and lets a reviewer reproduce the relevant behavior. Use $context only if the resulting conventions need durable documentation.
Worked example
Git workflow plan
Base / integration branches: Detected from repo policy; preserved, no new long-lived branch proposed
Change boundaries: Token change separate from behavior/data; small demoable work ships as one short-lived change
Shared-file ownership: Design lead owns tokens during redesign; each agent states scope in review; regenerate lockfile via package manager
Checks: Detected lint plus smoke on touched flow
Preview / review path: Per-change preview; merge after human review; integration branch stays deployable
Integration order: Shared token change first with consumer review, then page-specific work
Gotchas
- Read the repo branch and release policy first; do not assume a long-lived dev branch is required.
- Prefer short-lived changes around reviewable outcomes; do not prescribe fixed branch names.
- Plan only; do not push, merge, or delete branches on a planning request.
- Update lockfiles through the package manager; do not hand-edit hashes.
- State shared-file ownership explicitly; do not treat coordination notes as file locks.
- Follow established merge and approval rules; do not invent blanket rebase or approval bans.
Boundaries
- Do not use for a solo throwaway prototype — keep git trivial with no branch or review policy.
- Do not use to write context-file content — use
$context for AGENTS.md or CLAUDE.md.
1---2name: git3description: Plan or refine Git collaboration, reviewable changes, worktrees, and dependency-update ownership. Use when planning branches, slicing reviewable PRs, coordinating parallel agents, or assigning lockfile ownership.4---56# Git workflow78Keep concurrent work understandable and the integration branch usable. Read the repository's branch and release policy before proposing another.910## Work1112- Identify contributors, active edits, integration/deploy branches, CI, and preview environments. Do not assume a long-lived dev branch is required.13- Prefer short-lived changes organized around a reviewable user outcome. Visual, behavior, and data changes may belong together when separating them obscures correctness.14- Use worktrees for independent edits or side-by-side comparisons when helpful. Shared ownership notes are coordination aids, not actual file locks.15- State who owns shared files such as tokens, schemas, manifests, and lockfiles during parallel work. Preserve unrelated changes.16- Update lockfiles with the package manager for authorized dependency changes. Resolve competing dependency edits by reconciling manifests and regenerating, not hand-splicing dependency hashes.17- Follow the established commit, branch, merge, and approval rules. Do not invent blanket prohibitions on rebase or require approval for every local edit.1819## Deliver2021A compact plan naming base branch, change boundaries, shared-file ownership, checks, preview/review path, and integration order. Do not execute pushes, merges, or branch deletion merely because a planning request mentions them.2223```markdown24## Git workflow plan2526**Base / integration branches:**27**Change boundaries:**28**Shared-file ownership:**29**Checks:**30**Preview / review path:**31**Integration order:**32```3334For a redesign, a shared token change may affect every route: review its consumers together before splitting page-specific work. A small feature may be clearest as one vertical slice.3536Validate that the plan preserves others' work and lets a reviewer reproduce the relevant behavior. Use `$context` only if the resulting conventions need durable documentation.3738## Worked example3940## Git workflow plan4142**Base / integration branches:** Detected from repo policy; preserved, no new long-lived branch proposed43**Change boundaries:** Token change separate from behavior/data; small demoable work ships as one short-lived change44**Shared-file ownership:** Design lead owns tokens during redesign; each agent states scope in review; regenerate lockfile via package manager45**Checks:** Detected lint plus smoke on touched flow46**Preview / review path:** Per-change preview; merge after human review; integration branch stays deployable47**Integration order:** Shared token change first with consumer review, then page-specific work4849## Gotchas5051- Read the repo branch and release policy first; do not assume a long-lived dev branch is required.52- Prefer short-lived changes around reviewable outcomes; do not prescribe fixed branch names.53- Plan only; do not push, merge, or delete branches on a planning request.54- Update lockfiles through the package manager; do not hand-edit hashes.55- State shared-file ownership explicitly; do not treat coordination notes as file locks.56- Follow established merge and approval rules; do not invent blanket rebase or approval bans.5758## Boundaries5960- Do not use for a solo throwaway prototype — keep git trivial with no branch or review policy.61- Do not use to write context-file content — use `$context` for AGENTS.md or CLAUDE.md.
mattjmdesign