git-integration
Skill0 starsChanged 52 days agoMITView on GitHub
How an ArcheFlow run uses git (run branch, Maker worktree, integrate, merge, rollback, cleanup): reference for archeflow-git.sh and its config.
In this repository29 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- .cursor/rules/archeflow.mdcCursor rule
- archeflow-reviewSkill
- archeflow-runSkill
- archeflow-sprintSkill
- act-phaseSkill
- autonomous-modeSkill
- check-phaseSkill
- cost-trackingSkill
- custom-archetypesSkill
- dagSkill
- domainsSkill
- initSkill
- memorySkill
- multi-projectSkill
- presenceSkill
- progressSkill
- replaySkill
- reportSkill
- reviewSkill
- runSkill
- scanSkill
- scoreSkill
- shadow-detectionSkill
- sprintSkill
- statusSkill
- templatesSkill
- using-archeflowSkill
- workflow-designSkill
The file
We split this skill into the rules it gives an agent
2 rules. About 0 are common, 1 is distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- could be automatic: a setting could enforce it
- Very specific: line 10
All git operations of a run go through <archeflow-root>/lib/archeflow-git.sh.
- Distinctive: line 76
Never force-push; never rewrite the base branch.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Git Integration
All git operations of a run go through <archeflow-root>/lib/archeflow-git.sh. The script
never prompts without a terminal (destructive operations need --yes), never force-pushes, and
never rewrites the base branch's history.
Branches
<base> (the branch the run started from, e.g. main or master)
└── archeflow/<run_id> run branch: created by init, merged by merge
└── archeflow/<run_id>-maker Maker branch, in .archeflow/worktrees/<run_id>/
(created by worktree, merged back and removed by integrate)Commands (in the order a run uses them)
| Step | Command | Effect |
| run start | init <run_id> | refuses on uncommitted changes to tracked files (never stashes); creates and switches to the run branch; records the base branch in .archeflow/runs/<run_id>/base-branch |
| Do | worktree <run_id> | creates the Maker worktree from the run branch, prints its absolute path (idempotent) |
| Do | integrate <run_id> | merges the Maker's commits into the run branch (--no-ff), writes do-maker.diff and do-maker-files.txt (diff against the base), removes worktree and Maker branch; refuses if the Maker left uncommitted changes or made no commits |
| merge | merge <run_id> [--no-ff|--squash|--rebase] | must be run on the run branch; refuses while Maker work is not integrated; merges into the recorded base and leaves you on it; on conflict aborts and returns to the run branch |
| after merge | cleanup <run_id> [--yes] | deletes the run branch (squash-merged counts as merged) and .archeflow/runs/<run_id>/; an unmerged branch needs --yes |
| any time | status <run_id> | commits ahead of base, current phase, Maker worktree |
| manual only | commit <run_id> <phase> "<msg>" [files], phase-commit <run_id> <phase>, rollback <run_id> --to <phase> [--yes] | low-level tools a run does not use: commit files on the run branch yourself, and reset the run branch to such a commit |
The merge commit subject is archeflow: merge run <run_id> (a neutral type: the run may be a fix,
a feature or a refactor). archeflow-rollback.sh reverts only a HEAD commit with exactly that
subject, or the subject older versions wrote, feat: archeflow run <run_id> complete.
Configuration (.archeflow/config.yaml)
git:
enabled: true # false: no branch, no worktree; the Maker edits the working tree
branch_prefix: "archeflow/" # letters, digits, . _ / - ; must not start with + or -
merge_strategy: no-ff # no-ff (default, revertable merge commit) | squash | rebase
auto_merge: false # true: merge without asking once all reviewers approve
commit_style: conventional # conventional | simple
auto_push: false # push the run branch (explicit refspec, never forced)
signing_key: null # SSH key for signed commits
test_command: "npm test" # top level; run after the merge by archeflow-rollback.shKeys are read from the git: block; a top-level key of the same name is accepted as a
fallback. enabled and auto_merge are read by the agent following archeflow:run; the
others by the script.
Merging into the base branch
The run merges only after every reviewer approved, and only with the user's yes unless
git.auto_merge: true. The reviewers are language models reviewing code another model wrote;
the confirmation keeps a person in the loop before anything reaches the base branch. After the
merge, test_command (if set) runs through archeflow-rollback.sh <run_id>: exit 0 pass,
exit 1 failed and the merge commit was reverted, exit 3 failed and nothing was reverted (HEAD was
not this run's merge commit), exit 2 no test command.
Run state and artifacts
.archeflow/artifacts/, .archeflow/events/, .archeflow/runs/ and .archeflow/worktrees/
are run state, not source. A run commits nothing under .archeflow/, so a merge brings only the
Maker's changes into the base branch, and the .archeflow/.gitignore written by
/archeflow:init keeps run state out of your own commits. The audit trail is the event log
(.archeflow/events/<run_id>.jsonl), not git history.
Safety rules
- Never force-push; never rewrite the base branch.
- A failed run keeps its branch for inspection.
- Merge conflicts are reported, never force-resolved.
- The Maker works only in its worktree; the orchestrator's checkout stays on the run branch.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

