Start here
Quickstart
Five minutes, in an existing Git repo. We'll initialise Heddle beside Git, start a task, capture a few changes, look at the resolved thread, and land it back to a Git commit. At the end your normal review process is unchanged, but the work that produced the commit is fully attributed and recoverable.
Before you start
You need heddle on your $PATH. If heddle --version doesn't return cleanly, go back to
the Install page.
Use any Git repo with at least one commit. The example here uses a fresh checkout of a real project. Change directory into yours and follow along.
1. Initialise Heddle
Inside the repo, run heddle init. Heddle writes a .heddle/ sidecar next to .git/ and runs
in Git-overlay mode: Git commits stay in .git,
Heddle metadata lives in .heddle. Your Git-tracked
files are left untouched.
Initialise beside an existing Git repo
bash$ cd my-repo$ heddle initInitialized Heddle data in /path/to/my-repo/.heddle for Git-overlay workflowsSide effects: - created Heddle sidecar for the existing Git repository - left Git-tracked files untouched If you want to see what Heddle thinks of your repo, run heddle status. It reports the current thread, the
bridged Git ref, and whether the working tree has uncommitted
changes.
2. Start a task
Heddle's unit of work is the task. Start one with a name that describes the goal, same shape as a good branch name, but in Heddle a task isn't a branch, it's a thread that will collect every capture, retry, abort, and conflict on the way to a merge.
Name the task
bash$ heddle start biscuit-authz --task "replace JWT auth with Biscuit capabilities"Started isolated thread 'biscuit-authz' Thread names use letters, digits, and _ - . / @ : + =,
no spaces. The human-readable goal goes in --task.
3. Capture as you work
Make changes the way you normally would. When something is worth recording, a passing test, a working prototype, the moment before a refactor, capture it. Captures are cheap. Capture often.
Snapshot the working tree into the thread
bash$ heddle capture -m "scaffold biscuit verifier"Captured state hd-rppffbae2jb2 (7efea517)$ heddle capture -m "wire datalog scope rules"Captured state hd-mts0jaw6666j (d82419fd)$ heddle capture -m "fix type error in handler"Captured state hd-q4k7zv1n8w0c (3b1f0a92)$ heddle capture -m "fix import path"Captured state hd-8e2hytr5pqxf (a5c4d017) Every capture is part of the same thread, false starts and fixes alike. Heddle keeps each one in the thread's record, so the messy middle stays recoverable while the merge surface reflects the path that actually worked.
4. Read the resolved thread
Anytime, ask Heddle to render the task as a single record. heddle thread show collapses the captures, retries,
and any conflicts into one reviewable surface.
Read the task as one record
bash$ heddle thread show biscuit-authzbiscuit-authz · anthropic/claude-opus-4-8 9 captures · 3 retries · 1 abort · 1 conflict · 1 test · pending merge state hd-rppffbae2jb2 · 2m 10s wall-clock 14:32:01 CAP scaffold biscuit verifier 14:32:08 CAP add Capability + Scope types 14:32:14 RET type error in handler ... 14:34:11 MRG sign merge · ed255195. Mark it ready
When the task is done, ask Heddle for its verdict. heddle
ready captures any outstanding work, checks conflicts,
blockers, freshness, and semantic risk, then marks the thread
ready or blocked and prints the next action. It never lands or
pushes; it's the go/no-go check before you integrate.
Get Heddle's integration verdict
bash$ heddle ready --thread biscuit-authzThread 'biscuit-authz' is ready to landNext: heddle land6. Land back to Git
Finally, hand the resolved task back to Git. heddle
land captures any outstanding work, refreshes against the
target when safe, lands the thread, and writes the Git checkpoint,
squashing the thread into a single commit by default. Pass --push to push in the same step. It fails closed if
conflicts or other blockers remain.
Integrate the thread and write the Git checkpoint
bash$ heddle land --thread biscuit-authzLanded 'biscuit-authz' · Git checkpoint f02d14ea That's the whole loop. Push the Git commit, open a PR the way you always have. Reviewers who want to see the messy middle can open the linked Heddle thread; reviewers who only care about the diff see only the diff.
Next
Now read about task threads, the pillar concept that makes the rest of Heddle make sense. Or skip to the CLI reference and look up a specific command.