Staying up to date

This page is how to bring base changes into your own copy when the base ships a new version. You need this flow when a new skill got added to the base, an automation hook improved, or the domain rules the AI reads (AI_AUTOMATION.md) got updated.

The reason to pull is one line. The base is the starting point your tests stack on top of from the moment you bought in, but the base itself keeps getting better — and if you do not pull the improvements, only your copy stays frozen in time. You do not need to pull every time. Once a month or so, or when the base side sends word like “a new skill is out,” pull then.

This flow is built so a non-developer can run it directly. You do not have to memorize commands like git rebase. Just tell Claude Code or Codex “pull the base update.”

First time only — register the base repo

This registration happens once. If you took route B in Clone and install (git clone, then git remote rename origin base), it is already registered, so skip this section. If you took route A (GitHub Template), registration is needed.

Open a terminal and run this in your folder.

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

Nothing prints when the command finishes. That is normal. To confirm the registration took, run:

git remote -v

If you see two lines each for base and origin, four in all, you are done. If the base is not registered the first time you call /update-from-base, the tool guides you through the command above and offers to run it for you.

If you see fatal: remote base already exists, it is already registered, so move on to the next section.

Pulling an update

Once registered, every time after that is one line. Type one of these into the Claude Code or Codex prompt.

/update-from-base

Or in natural language, “pull the base update.” Both produce the same result.

When the call goes through, the tool walks the following sequence. For each step, what you should see when it is healthy is noted alongside, so follow those lines as you go.

1. Check for unsaved changes

It first checks whether your work has any uncommitted changes. If it does, it asks “it’s safer to commit or set these aside first. Shall I tuck them away with git stash for a moment?” Answer yes and it sets them aside briefly, then restores them once the update finishes. It is the safe route, so yes is generally the recommendation.

2. A summary of the base’s changes

The tool pulls the new commits from the base repo, then shows you which parts of your copy are affected, grouped by area.

Base update summary (new changes since the last sync)

Newly added skills (can be applied automatically)
- 2

Updated base files (can be applied automatically)
- .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 pulls the auto-applicable areas in one pass. These are the seats the base is responsible for (skills, agents, hooks, AI_AUTOMATION.md), so overwriting them does not make your tests disappear. show-diff shows you in detail which lines change. For the first run or two, looking once with show-diff and then moving on with yes is the comfortable flow.

3. Your tests are never touched

There is a seat to relax at here. The update never overwrites anything you wrote.

Every test in the tests/ folder, track config like playwright.config.ts or .maestro/, .env.test.local, docs/design/e2e-spec.md, and the decision records in docs/adr/ are all your territory. The base update does not touch them. What gets updated automatically is only the automation assets the base made.

CLAUDE.md and README.md are seats the base may have changed and you may have added notes to, so they are not overwritten automatically — it asks file by file. You pick one of three: overwrite wholesale with the base version, merge just the changed parts, or leave it for now. If you have never touched that file, option one (overwrite wholesale) is the right answer.

4. Wrap-up after applying

The tool checks the applied files once more. If a hook file got updated, it re-attaches the execute permission; if a new skill came in, it lists, one line each, which keyword calls that skill. At the end it asks whether to pin it down with a commit. yes commits automatically.

When to pause before pulling

You do not need to pull every time. Pause at these seats.

If you have ever edited a base skill directly, pause. If you edited a base skill’s body by hand, the auto-update overwrites that edit. Rather than editing a base skill directly, the recommended route is to make your own under your own directory (for example, .claude/skills/my-team-{name}/) with the same keyword.

If you are mid-task with changes about to be committed, finish those first, then pull. If work you tucked away touches the same lines as a base change, you get a conflict — and that conflict is the hardest seat for a non-developer to resolve. When you can, pull at a point where your work is stable.

When something breaks

If the build breaks after an update, or a command stops working, look at Troubleshooting first. The base may have started requiring a new tool version.

If that does not resolve it, revert the applied change wholesale.

git revert HEAD

This command creates a new commit that reverses what the update brought in. Your tests stay alive as they are, and the base can be pulled again on the next call.

When you want to lay base patterns onto an app that already has tests

This is a different seat from update. When you did not fork the base, but want to fit the base’s patterns (track structure, auth reuse, CI) into an app repo that already has some e2e tests, call /adopt.

/adopt

This command looks at the tools, directory structure, auth method, and CI already in your repo, points out where they differ from the base patterns, and builds a prioritized migration plan. It does not change everything at once — it sets the order of where to start. The fuller flow is in the updates page of the Expert manual.

Next

Once the update is done, run a lap with /run-suite from Run and read the report to confirm your tests still run cleanly. If the update touched a security seat of the base, run a cycle on staging before moving on.