How do I install the Main Sync skill?

Run npx skillmds@latest add seasonedcc/main-sync-2 in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Main Sync safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Main Sync?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Main Sync free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Main Sync?

seasonedcc (@seasonedcc) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Main Sync by seasonedcc — Agent Skill

Name: Main Sync
Author: seasonedcc

Main Sync

Sync a long-lived feature branch with its repo's advancing main — merge main in, judge the rule-set and capability deltas, and re-run the combined Definition of Done. Use when main gains commits under a goal or review-fixes feature branch, before merging origin/main into a feature branch, or when deciding whether a feature landed on main must be mirrored on the branch.

seasonedcc 5e137a9 3.5 KB Updated Sep 17, 2026

File contents

Main sync

A long-lived feature branch decays as its repo's main advances: new rules bind work the branch already did, new capabilities land that the branch's own promises may cover, and evidence measured before the sync no longer describes the merged tree. A sync is not a mechanical merge — it is a scoped review of everything main brought in. Merge main into the branch (a branch backing an open PR is public history — merge, never rebase it), then work the four obligations below before the sync lands.

1. Rule-set delta — both directions

Three rule-set sources govern the branch, and a sync can move all of them:

The workspace's own instructions and skills (CLAUDE.md, .claude/skills/).
The repo's contracts: its AGENTS.md and binding process docs (docs/process/ in product-monolith).
The branch's own contracts: its design docs, decision records, and the rulings made during its effort.

Diff the sync range for changes to the first two, and apply every rule change in BOTH directions: branch code written before a new rule complies with it now (sweep the branch, don't grandfather it), and the code main brought in complies with the branch's own contracts wherever it lands on a surface the branch owns. A new convention arriving from main re-judges the branch's entire diff, and the branch's own additions re-judge main's incoming commits: one such audit caught seven branch-owned writes violating a convention main had just added, and an API operation that, per the branch's own parity rule, had to follow a web flow main had just moved behind a new facade.

2. Capability delta — parity or out of scope

Enumerate what main added over the sync range (git log --no-merges, read against the diff). For each capability, decide its scope against the branch's own promises: a branch that promises parity with a surface must either mirror the new capability or document why it is out (a browser-only interaction, analytics-internal state). These are rulings, not chores — when the branch's contracts do not settle one, present it to the user with a recommendation, and record the outcome where the branch documents its deliberate gaps.

3. Combined Definition of Done

After the merge, run the FULL combined-DoD matrix — the union of every gate that governs the branch and every gate that governs what main brought in: the repo's own gates end to end, plus the branch-specific proofs (seeds, manifests, e2e journeys, browser QA) for every surface the sync touched. A sync that only re-runs the branch's usual gates ships main's regressions under the branch's name.

4. Evidence refresh

Any banked evidence measured before the sync — gate numbers, audit passes, QA screenshots, prose claims in the PR body — is stale for whatever the sync touched. Re-establish what the merge invalidated, and update the PR body where the sync changed what it describes.

The sync is a lane

The sync merge is a lane like any other: it gets its own code-review audit BEFORE it merges into the feature branch, and the standing rules hold — merging the feature branch itself into main remains the user's act.

---name: main-sync-2description: Sync a long-lived feature branch with its repo's advancing main — merge main in, judge the rule-set and capability deltas, and re-run the combined Definition of Done. Use when main gains commits under a goal or review-fixes feature branch, before merging origin/main into a feature branch, or when deciding whether a feature landed on main must be mirrored on the branch.---# Main syncA long-lived feature branch decays as its repo's `main` advances: new rules bind work the branch already did, new capabilities land that the branch's own promises may cover, and evidence measured before the sync no longer describes the merged tree. A sync is not a mechanical merge — it is a scoped review of everything `main` brought in. Merge `main` into the branch (a branch backing an open PR is public history — merge, never rebase it), then work the four obligations below before the sync lands.## 1. Rule-set delta — both directionsThree rule-set sources govern the branch, and a sync can move all of them:- The workspace's own instructions and skills (`CLAUDE.md`, `.claude/skills/`).- The repo's contracts: its `AGENTS.md` and binding process docs (`docs/process/` in product-monolith).- The branch's own contracts: its design docs, decision records, and the rulings made during its effort.Diff the sync range for changes to the first two, and apply every rule change in BOTH directions: branch code written before a new rule complies with it now (sweep the branch, don't grandfather it), and the code `main` brought in complies with the branch's own contracts wherever it lands on a surface the branch owns. A new convention arriving from `main` re-judges the branch's entire diff, and the branch's own additions re-judge main's incoming commits: one such audit caught seven branch-owned writes violating a convention `main` had just added, and an API operation that, per the branch's own parity rule, had to follow a web flow `main` had just moved behind a new facade.## 2. Capability delta — parity or out of scopeEnumerate what `main` added over the sync range (`git log --no-merges`, read against the diff). For each capability, decide its scope against the branch's own promises: a branch that promises parity with a surface must either mirror the new capability or document why it is out (a browser-only interaction, analytics-internal state). These are rulings, not chores — when the branch's contracts do not settle one, present it to the user with a recommendation, and record the outcome where the branch documents its deliberate gaps.## 3. Combined Definition of DoneAfter the merge, run the FULL combined-DoD matrix — the union of every gate that governs the branch and every gate that governs what `main` brought in: the repo's own gates end to end, plus the branch-specific proofs (seeds, manifests, e2e journeys, browser QA) for every surface the sync touched. A sync that only re-runs the branch's usual gates ships main's regressions under the branch's name.## 4. Evidence refreshAny banked evidence measured before the sync — gate numbers, audit passes, QA screenshots, prose claims in the PR body — is stale for whatever the sync touched. Re-establish what the merge invalidated, and update the PR body where the sync changed what it describes.## The sync is a laneThe sync merge is a lane like any other: it gets its own code-review audit BEFORE it merges into the feature branch, and the standing rules hold — merging the feature branch itself into `main` remains the user's act.

Frequently asked questions