Staying up to date with base

This page is about pulling new versions of the base into your own copy. You’ll need this flow when the base ships a new skill, improves an automation hook, or updates the domain rules in AI_AUTOMATION.md that the AI relies on.

The reason to do this in one line: the base keeps improving, and your fork only inherits that improvement if you actively pull it in. You don’t have to do this every day. Once a month, or whenever the base maintainer announces something like “new skill is out,” is enough.

The flow is built so a non-developer can run it directly. You don’t need to memorize git rebase or any other git command. You say “pull from base” to Claude Code or Codex.

First time only — register the base repo

This registration is a one-time step on your machine. Every later update call assumes it’s already done.

Open your terminal, move into your extension folder, and run:

git remote add base https://github.com/ddakit/chrome-ext-base.git

The command prints nothing on success. To confirm it stuck, run:

git remote -v

A healthy output looks like:

base    https://github.com/ddakit/chrome-ext-base.git (fetch)
base    https://github.com/ddakit/chrome-ext-base.git (push)
origin  ...your repo URL...

Four lines total: two for base, two for origin. That’s the whole setup. If this is your first time, you can also type /update-from-base and let the tool handle it. It detects a missing remote and offers to run the registration for you.

When this gets stuck

fatal: remote base already exists means it’s already registered. Move on to the next section.

Permission denied means your license has expired or you don’t have access to the base repo. Reach out to the base maintainer.

Pulling one update

Once the registration is in place, every later sync is a single instruction. In Claude Code or Codex, type one of:

/update-from-base

Or in natural language:

pull from base

Both produce the same result.

The tool then walks through the steps below. Each step has a “what’s normal” line so you can follow along visually.

1. Uncommitted-work check

It first looks for changes you haven’t committed yet. If there are any, you’ll see:

You have uncommitted changes. Let's set them aside before syncing.
Should I run git stash for you?

Saying yes parks them safely. After the update finishes, git stash pop brings them back. This is the safer path; default to yes.

2. Summary of what the base changed

The tool fetches the new commits from the base and groups the affected files by area. Output looks something like this:

Base update summary (since last sync)

New skills (auto-applicable)
- 2

Updated base files (auto-applicable)
- .claude/skills/ (3 updated)
- .claude/hooks/ (1 updated)
- AI_AUTOMATION.md (✓ updated)

Manual review needed (may conflict with your edits)
- CLAUDE.md
- README.md

Proceed? (yes / no / show-diff)

yes applies the auto-applicable bucket in one go. These files are areas the base owns, so overwriting them won’t lose your work.

show-diff prints the actual line-level changes. The first one or two times you run this, picking show-diff is a good way to see what the base is changing before saying yes.

no aborts. The same summary comes back on the next call.

3. Manual-review files — pick one of three

CLAUDE.md, README.md, and AGENTS.md can be edited by both the base and you, so the tool never auto-overwrites them. For each one it asks:

CLAUDE.md — base updated this, and you may have edited it too.
Pick one:

1. Take base version wholesale (your edits are lost)
2. Merge base changes into yours (3-way merge — you resolve conflicts by hand)
3. Skip for now (decide later)

For most first-timers, option 1 is the right answer. If you’ve never touched the file, the base version is the latest one anyway. If you have touched it, your edits are usually a short note or two that you can rewrite if needed.

Option 2 is for cases where your edits are substantial and you want to keep them. The auto-merge sometimes leaves conflict markers (<<<<<<<, =======, >>>>>>>) inside the file; the tool tells you where, and you decide which version to keep at each marker. This path is awkward for first-timers. Option 1 plus rewriting your note is usually faster than wrestling with a conflict.

Option 3 defers the decision. The same prompt comes back next time you run an update.

4. Post-apply checks

The tool double-checks the files it just applied. If hooks (.sh files) changed, it reapplies execute permissions. It validates settings.json to make sure it’s still parseable. If new skills landed, it lists each one’s trigger keywords so you know how to invoke them. The closing line looks like:

✓ Base sync complete
2 new skills, 7 files updated
commit hash: a3f9c21

That’s the end of the flow.

5. Commit

The last prompt is:

Commit these changes?
Suggested message: "chore(base): sync to a3f9c21 (7 files)"

yes makes the commit automatically. You can also say no and write your own message manually.

When to hold off

Updates aren’t something to run on every check-in. Two situations call for a pause.

If you’ve directly edited base code, pause. For instance, if you changed a base skill under .claude/skills/, an auto-update would overwrite that change. The tool detects this and reclassifies the file as mixed, but it’s safer to recognize the situation deliberately. The recommended pattern is to never edit base skills in place; create a parallel skill in your own directory (for example .claude/skills/my-team-{name}/) using the same trigger keywords.

If you’re in the middle of an active task with uncommitted work coming in the next hour, finish that work first. Stashing is an option, but when the stashed work returns it can collide with base changes that touched the same lines. Resolving that kind of conflict is the hardest part of this flow for non-developers, so try to time updates for moments when your branch is in a stable state.

When something breaks

If the build fails or commands stop working after an update, work through the following.

Start with the environment-setup section in 06-troubleshooting.md. The base may have started requiring a newer Node version or some other tool upgrade.

Next, roll back the update commit. The command is one line:

git revert HEAD

This creates a new commit that undoes the update commit. Your own work is untouched, and you can run the update again later.

Rare situations like a force-pushed base will halt the tool automatically with an explanatory notice. If that notice appears, don’t try to push past it. Forward the message to the base maintainer.

Next

After an update, confirm your extension still runs. Open chrome://extensions, click the reload button on your extension card, run one of its main actions, and check the console for red lines. If you get stuck, compare against the “what normal looks like” descriptions in 03-first-run.md.

If you’re already shipping to users and an update has been applied, run through the 09-distribution.md flow once more to send a fresh zip or upload a new build to the Web Store.