Sync
Invoke as $sync.
Pull the latest changes from the remote repository and report status.
Workflow
- Check current state:
- Run
git status to check for uncommitted changes.
- If there are uncommitted changes, stash them first, pull, then pop the stash. Warn the user about the stash.
- Pull from remote:
- Run
git pull --rebase origin <current-branch>.
- If rebase conflicts occur, abort the rebase, try
git pull --no-rebase instead, and report any merge conflicts for the user to resolve.
- Check for outstanding work:
- Check if
tasks/roadmap.md exists for the full plan, and tasks/todo.md for the current phase.
- If
tasks/todo.md exists, read it and look for unchecked items (- [ ]).
- If there are incomplete items, summarise: which phase is current, what the next step is, and how many steps/phases remain.
- If
tasks/manual-todo.md exists, count unchecked manual tasks and include in the summary.
- If
tasks/record-todo.md or tasks/recurring-todo.md exists, count unchecked advisory items and include those counts separately. Do not treat them as active plan steps.
- If all items are checked, report that the plan is complete.
- If neither file exists, note that there is no active plan.
- Check provisioning version:
- If
CLAUDE.md or AGENTS.md contains <!-- provision-agentic-config vX.Y -->, extract the version.
- Read
~/.codex/skills/provision-agentic-config/SKILL.md (or ~/.claude/skills/provision-agentic-config/SKILL.md as fallback) and extract the version: field from the YAML frontmatter.
- If the installed skill version is newer than the provisioned version in either file, warn:
⚠ CLAUDE.md provisioned with vX.Y but provision-agentic-config is at vX.Y — consider re-running $provision-agentic-config
- If the version comment is missing from
CLAUDE.md or AGENTS.md, note: ℹ No provision version found in CLAUDE.md/AGENTS.md — run $provision-agentic-config to add version tracking
- If neither skill file exists, skip this check silently.
- Report status:
- Branch name
- Commits pulled (if any) — show short log of new commits
- Whether stashed changes were re-applied
- Any conflicts that need manual resolution
- Current
git status
- Outstanding work — summary from step 3 (next step, current phase, remaining work, pending manual tasks) or "No active plan"
- Advisory tasks — pending record/recurring counts, if those files exist
- Post-sync actions:
a) Check if
sync.md exists at the project root.
b) If sync.md exists — parse and execute it:
- Read
sync.md and identify sections by H2 headings.
- Dependencies (aliases: "Deps", "Dependency Management"): Execute shell commands in fenced code blocks. Report output briefly.
- Conflict Resolution (aliases: "Conflicts"): If the pull introduced merge conflicts (from step 2), apply the guidance in this section. If no conflicts, skip silently.
- Custom (aliases: "Project-Specific", "Scripts", "Setup"): Execute shell commands in fenced code blocks in order. Report output briefly.
- Notifications (aliases: "Awareness", "Alerts", "Watch"): For each bullet, check if the mentioned file/directory was modified in pulled commits (
git diff --name-only against pre-pull HEAD). If any match, print a prominent alert.
- Unrecognised headings: skip with a note.
- Report a summary of all post-sync actions taken.
c) If
sync.md does not exist — suggest creating one:
- Analyse the project to detect: package manager (look for lockfiles), common scripts (package.json, Makefile, Justfile), config templates (.env.example, docker-compose.yml).
- Present a suggested
sync.md following the format below.
- Ask: "Would you like me to create this
sync.md?"
- Only create the file if the user approves.
sync.md format
The sync.md file lives at the project root. H2 sections are categories. Shell commands go in fenced code blocks; prose guidance goes in bullet points.
# Post-Sync Actions
## Dependencies
```sh
npm install
Conflict Resolution
- Always accept theirs for
package-lock.json
Custom
npm run codegen
Notifications
.env.example — check for new environment variables
CLAUDE.md — review if project conventions were updated
## Constraints
- Do not force-push or rewrite history.
- Do not auto-resolve merge conflicts — report them and let the user decide. However, if `sync.md` has a Conflict Resolution section, follow its guidance for the specific files/patterns it covers.
- If stash pop fails due to conflicts, leave the stash intact and report it.
- Post-sync commands from `sync.md` run in the project root directory.
- If any post-sync command fails, report the error and continue with remaining actions.
- Never auto-create `sync.md` without explicit user approval.
- Do not execute commented-out sections (`<!-- ... -->`).
## Default Shipping Contract
Follow the shared shipping contract convention in CLAUDE.md.
1---2name: sync-33description: Pull latest changes from remote and report status4---5
6# Sync
7
8Invoke as `$sync`.
9
10Pull the latest changes from the remote repository and report status.
11
12## Workflow
13
141. Check current state:
15 - Run `git status` to check for uncommitted changes.
16 - If there are uncommitted changes, stash them first, pull, then pop the stash. Warn the user about the stash.
172. Pull from remote:
18 - Run `git pull --rebase origin <current-branch>`.
19 - If rebase conflicts occur, abort the rebase, try `git pull --no-rebase` instead, and report any merge conflicts for the user to resolve.
203. Check for outstanding work:
21 - Check if `tasks/roadmap.md` exists for the full plan, and `tasks/todo.md` for the current phase.
22 - If `tasks/todo.md` exists, read it and look for unchecked items (`- [ ]`).
23 - If there are incomplete items, summarise: which phase is current, what the next step is, and how many steps/phases remain.
24 - If `tasks/manual-todo.md` exists, count unchecked manual tasks and include in the summary.
25 - If `tasks/record-todo.md` or `tasks/recurring-todo.md` exists, count unchecked advisory items and include those counts separately. Do not treat them as active plan steps.
26 - If all items are checked, report that the plan is complete.
27 - If neither file exists, note that there is no active plan.
284. Check provisioning version:
29 - If `CLAUDE.md` or `AGENTS.md` contains `<!-- provision-agentic-config vX.Y -->`, extract the version.
30 - Read `~/.codex/skills/provision-agentic-config/SKILL.md` (or `~/.claude/skills/provision-agentic-config/SKILL.md` as fallback) and extract the `version:` field from the YAML frontmatter.
31 - If the installed skill version is newer than the provisioned version in either file, warn: `⚠ CLAUDE.md provisioned with vX.Y but provision-agentic-config is at vX.Y — consider re-running $provision-agentic-config`
32 - If the version comment is missing from `CLAUDE.md` or `AGENTS.md`, note: `ℹ No provision version found in CLAUDE.md/AGENTS.md — run $provision-agentic-config to add version tracking`
33 - If neither skill file exists, skip this check silently.
345. Report status:
35 - Branch name
36 - Commits pulled (if any) — show short log of new commits
37 - Whether stashed changes were re-applied
38 - Any conflicts that need manual resolution
39 - Current `git status`
40 - **Outstanding work** — summary from step 3 (next step, current phase, remaining work, pending manual tasks) or "No active plan"
41 - **Advisory tasks** — pending record/recurring counts, if those files exist
426. Post-sync actions:
43 a) Check if `sync.md` exists at the project root.
44 b) **If `sync.md` exists** — parse and execute it:
45 - Read `sync.md` and identify sections by H2 headings.
46 - **Dependencies** (aliases: "Deps", "Dependency Management"): Execute shell commands in fenced code blocks. Report output briefly.
47 - **Conflict Resolution** (aliases: "Conflicts"): If the pull introduced merge conflicts (from step 2), apply the guidance in this section. If no conflicts, skip silently.
48 - **Custom** (aliases: "Project-Specific", "Scripts", "Setup"): Execute shell commands in fenced code blocks in order. Report output briefly.
49 - **Notifications** (aliases: "Awareness", "Alerts", "Watch"): For each bullet, check if the mentioned file/directory was modified in pulled commits (`git diff --name-only` against pre-pull HEAD). If any match, print a prominent alert.
50 - Unrecognised headings: skip with a note.
51 - Report a summary of all post-sync actions taken.
52 c) **If `sync.md` does not exist** — suggest creating one:
53 - Analyse the project to detect: package manager (look for lockfiles), common scripts (package.json, Makefile, Justfile), config templates (.env.example, docker-compose.yml).
54 - Present a suggested `sync.md` following the format below.
55 - Ask: "Would you like me to create this `sync.md`?"
56 - **Only create the file if the user approves.**
57
58## sync.md format
59
60The `sync.md` file lives at the project root. H2 sections are categories. Shell commands go in fenced code blocks; prose guidance goes in bullet points.
61
62```markdown
63# Post-Sync Actions
64
65## Dependencies
66
67```sh
68npm install
69```
70
71## Conflict Resolution
72
73- Always accept theirs for `package-lock.json`
74
75## Custom
76
77```sh
78npm run codegen
79```
80
81## Notifications
82
83- `.env.example` — check for new environment variables
84- `CLAUDE.md` — review if project conventions were updated
85```
86
87## Constraints
88
89- Do not force-push or rewrite history.
90- Do not auto-resolve merge conflicts — report them and let the user decide. However, if `sync.md` has a Conflict Resolution section, follow its guidance for the specific files/patterns it covers.
91- If stash pop fails due to conflicts, leave the stash intact and report it.
92- Post-sync commands from `sync.md` run in the project root directory.
93- If any post-sync command fails, report the error and continue with remaining actions.
94- Never auto-create `sync.md` without explicit user approval.
95- Do not execute commented-out sections (`<!-- ... -->`).
96
97
98## Default Shipping Contract
99
100Follow the shared shipping contract convention in CLAUDE.md.