Stats
Actions
Tags
From chronicle
This skill should be used when the user asks to "write a commit message", "write good commits", "configure a branching strategy", "configure git workflow", "fix a merge conflict", "review merge strategies", "analyze branching strategies", "run parallel experiments in git", "build a multi-agent git workflow", "add version control to documents", "convert from svn to git", "review git best practices", "write commit messages for documents", or any question about managing change across code, documents, or content using git, jujutsu, subversion, or other version control tools.
How this skill is triggered — by the user, by Claude, or both
Slash command
/chronicle:chronicleThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Managing change well is not just about tracking history — it is about making that history navigable, reversible, and meaningful. This skill covers the full spectrum from daily commit craft to multi-agent experiment orchestration, with git as the primary tool and jujutsu as a modern alternative worth understanding.
Managing change well is not just about tracking history — it is about making that history navigable, reversible, and meaningful. This skill covers the full spectrum from daily commit craft to multi-agent experiment orchestration, with git as the primary tool and jujutsu as a modern alternative worth understanding.
Three principles underpin all good version control practice:
| Tool | Era | Still Relevant? | Notes |
|---|---|---|---|
| RCS | 1982 | Rarely | Single-file locking model; foundational concepts |
| CVS | 1990 | Legacy only | Centralized; first "directory" VCS |
| Subversion (SVN) | 2000 | Yes, in enterprises | Centralized; still common in regulated industries |
| Git | 2005 | Dominant | Distributed; default recommendation |
| Jujutsu (jj) | 2022 | Growing | Built on git's storage; paradigm shift worth learning |
For detailed history and non-code use cases, see references/vcs-history.md.
These are the opinionated defaults — understand the tradeoffs before departing from them.
Keep a single long-lived branch (main). Work in short-lived feature branches (hours to days, not weeks). Merge frequently. Use feature flags for incomplete work rather than long-lived branches.
When to deviate: Release management for versioned software, regulated environments requiring audit trails per-release, or open-source projects with async contribution patterns (use GitHub flow instead). See references/branching-strategies.md for the full decision tree.
Never rebase shared history. Once a commit has been pushed and others have based work on it, rewriting it creates divergence that is painful to untangle.
For the full decision tree with advanced strategies (cherry-pick, octopus merge, rerere), see references/merge-strategies.md.
<type>(<scope>): <imperative summary under 50 chars>
<body wrapped at 72 chars — the why, not the what>
<footer: issue refs, breaking change notices>
Types: feat, fix, docs, refactor, test, chore, perf
The summary line answers: "If applied, this commit will ___."
For conventional commits, signing, amend discipline, and non-code content, see references/commit-craft.md.
Git worktrees allow multiple working trees from the same repository simultaneously — each in a different directory, each on a different branch, sharing the same object store.
This makes worktrees ideal for parallel experimentation:
# Set up three parallel experiments
git worktree add ../experiment-a experiment/approach-a-$(date +%Y%m%d)
git worktree add ../experiment-b experiment/approach-b-$(date +%Y%m%d)
git worktree add ../experiment-c experiment/approach-c-$(date +%Y%m%d)
Each agent works in its own worktree independently. When experiments complete, evaluate results and integrate the best approach back to the parent branch using the appropriate merge strategy for the confidence level.
For full patterns including result evaluation, partial cherry-pick integration, and cleanup, see references/worktrees-experiments.md.
Jujutsu is a version control system built on git's storage layer, designed around first-class conflicts and an operation log that makes everything undoable. It eliminates the staging area and treats the working copy as a commit in progress.
Key mental model shift: in jj, there is no "detached HEAD" — you are always on a commit. Conflicts are stored in the repository and resolved lazily rather than halting your workflow.
# jj equivalent of git's common operations
jj new # start a new change (like git checkout -b)
jj describe # write a commit message for the current change
jj squash # fold current change into parent
jj rebase -d @- # rebase current change onto parent's parent
For a full jj workflow guide and git↔jj mental model mapping, see references/jujutsu.md.
Version control is not limited to source code. Any content where change matters — documents, configurations, data files, note vaults — benefits from the same principles:
git diffThe same atomic/descriptive/reversible philosophy applies. Commit message discipline matters even more when non-developers are reading the history.
Need to change something? →
Is the change complete and logical? → commit it atomically
Is it exploratory? → new branch or jj change
Need to integrate? →
Is the branch local/unshared? → rebase
Is it shared or reviewed? → merge commit
Is it small and noisy internally? → squash merge
Need to experiment in parallel? →
Use worktrees (see references/worktrees-experiments.md)
Choosing a branching model? →
Default: trunk-based
Complex release cadence: see references/branching-strategies.md
Want a different paradigm entirely? →
Evaluate jj (see references/jujutsu.md)
references/commit-craft.md — Atomic commits, message format, conventional commits, amend discipline, signing, non-code contentreferences/branching-strategies.md — Trunk-based, GitHub flow, git-flow, release branching — full decision treereferences/merge-strategies.md — merge/rebase/squash/cherry-pick/octopus — when each is appropriate with worked examplesreferences/worktrees-experiments.md — Multi-agent experiment patterns, parallel worktrees, evaluating and integrating resultsreferences/jujutsu.md — jj workflow, first-class conflicts, git↔jj mental model map, when to prefer jjreferences/vcs-history.md — RCS→CVS→SVN→Git lineage, non-code use cases, SVN in regulated environmentsnpx claudepluginhub totallygreg/claude-mp --plugin chronicleProvides Git workflow patterns including branching strategies, commit conventions, merge vs rebase, and conflict resolution for teams of all sizes.
Structures git workflow practices for committing, branching, resolving conflicts, and organizing work across parallel streams. Use when making any code change.
Guides Git branching strategies (GitHub Flow, trunk-based, GitFlow), commit conventions, merge vs rebase, conflict resolution, and collaborative development best practices.