skills/electron-chromium-upgrade/electron-chromium-upgrade/SKILL.md
Guide for performing Chromium version upgrades in the Electron project. Use when working on the roller/chromium/main branch to fix patch conflicts during `e sync --3`. Covers the patch application workflow, conflict resolution, analyzing upstream Chromium changes, and proper commit formatting for patch fixes.
npx skillsauth add aiagentskills/skills electron-chromium-upgradeInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Run e sync --3 repeatedly, fixing patch conflicts as they arise, until it succeeds. Then run e patches all and commit changes atomically.
Phase One is complete when:
e sync --3 exits with code 0 (no patch failures)e patches all has been run to export all changesDo not stop until these criteria are met.
CRITICAL Do not delete or skip patches unless 100% certain the patch is no longer needed. Complicated conflicts or hard to resolve issues should be presented to the user after you have exhausted all other options. Do not delete the patch just because you can't solve it.
The roller/chromium/main branch is created by automation to update Electron's Chromium dependency SHA. No work has been done to handle breaking changes between the old and new versions.
Key directories:
e commands here).. (parent): Chromium repo (where most patches apply)patches/: Patch files organized by targetdocs/development/patches.md: Patch system documentation.git/rr-cache in both the electron and .. folder to ensure no accidental rerere replays occur from before this upgrade phase attempt startede sync --3 (the --3 flag enables 3-way merge, always required)git am --continue in affected repogit am --continue succeeds you MUST run e patches {target} to export fixese sync --3 succeeds, run e patches allreferences/phase-one-commit-guidelines.md NOW, then commit changes following those instructions exactly.Before committing any Phase One changes, you MUST read references/phase-one-commit-guidelines.md and follow its instructions exactly.
| Command | Purpose |
|---------|---------|
| e sync --3 | Clone deps and apply patches with 3-way merge |
| git am --continue | Continue after resolving conflict (run in target repo) |
| e patches {target} | Export commits from target repo to patch files |
| e patches all | Export all patches from all targets |
| e patches --list-targets | List targets and config paths |
patches/{target}/*.patch → [e sync --3] → target repo commits
← [e patches] ←
| Situation | Action |
|-----------|--------|
| During active git am conflict | Fix in target repo, then git am --continue |
| Modifying patch outside conflict | Edit .patch file directly |
| Creating new patch (rare, avoid) | Commit in target repo, then e patches {target} |
Fix existing patches 99% of the time rather than creating new ones.
From: field)TODO(name) must retain original nameDCHECK → CHECK_IS_TEST), update patch commit message to reflect current stateAfter Phase One, write a summary of every change: what was fixed, why, reasoning, and Chromium CL links.
Run e build -k 999 repeatedly, fixing build issues as they arise, until it succeeds. Then run e start --version to validate Electron launches and commit changes atomically.
Run Phase Two immediately after Phase One is complete.
Phase Two is complete when:
e build -k 999 exits with code 0 (no build failures)e start --version has been run to check Electron launchesDo not stop until these criteria are met. Do not delete code or features, never comment out code in order to take short cut. Make all existing code, logic and intention work.
The roller/chromium/main branch is created by automation to update Electron's Chromium dependency SHA. No work has been done to handle breaking changes between the old and new versions. Chromium APIs frequently are renamed or refactored. In every case the code in Electron must be updated to account for the change in Chromium, strongly avoid making changes to the code in chromium to fix Electrons build.
Key directories:
e commands here).. (parent): Chromium repo (do not touch this code to fix build issues, just read it to obtain context)e build -k 999 (the -k 999 flag is a flag to ninja to say "do not stop until you find that many errors" it is an attempt to get as much error
context as possible for each time we run build)e build -t {target_that_failed}.o to build just the failed target we were specifically fixing
FAILED: 2e506007-8d5d-4f38-bdd1-b5cd77999a77 "./obj/electron/chromium_src/chrome/process_singleton_posix.o" CXX obj/electron/chromium_src/chrome/process_singleton_posix.o the target name is obj/electron/chromium_src/chrome/process_singleton_posix.oreferences/phase-two-commit-guidelines.md NOW, then commit changes following those instructions exactly.git status in the electron repo
.patch files that only have index/hunk header changesgit commit -am "chore: update patch hunk headers"e build succeeds, run e start --versiongit status
Before committing any Phase Two changes, you MUST read references/phase-two-commit-guidelines.md and follow its instructions exactly.
When monitoring e build -k 999 output, filter for errors using this regex pattern:
error:|FAILED:|fatal:|subcommand failed|build finished
The build output is extremely verbose. Filtering is essential to catch errors quickly.
| Command | Purpose |
|---------|---------|
| e build -k 999 | Builds Electron and won't stop until either all targets attempted or 999 errors found |
| e build -t {target}.o | Build just one specific target to verify a fix |
| e start --version | Validate Electron launches after successful build |
When the error is in a file that Electron patches (check with grep -l "filename" patches/chromium/*.patch):
/src/chrome/browser/...)cd .. # to chromium repo
git add <modified-file>
git commit --fixup=<original-patch-commit-hash>
GIT_SEQUENCE_EDITOR=: git rebase --autosquash --autostash -i <commit>^
references/phase-one-commit-guidelines.md, then commit changes following those instructions exactly. READ THESE GUIDELINES BEFORE COMMITTING THESE CHANGESTo find the original patch commit to fixup: git log --oneline | grep -i "keyword from patch name"
The base commit for rebase is the Chromium commit before patches were applied. Find it by checking the refs/patches/upstream-head ref.
B. Electron Code Fixes (for files in shell/, electron/, etc.)
When the error is in Electron's own source code:
Dependent Patch Updates
IMPORTANT: When you modify a patch, other patches that apply to the same file may have their hunk headers invalidated. After committing a patch fix:
references/phase-one-commit-guidelines.mdreferences/phase-two-commit-guidelines.mdThis skill has additional reference files in references/:
Read these when referenced in the workflow steps.
documentation
Guides using bun.sys for system calls and file I/O in Zig. Use when implementing file operations instead of std.fs or std.posix.
development
Comprehensive spreadsheet creation, editing, and analysis with support for formulas, formatting, data analysis, and visualization. When Claude needs to work with spreadsheets (.xlsx, .xlsm, .csv, .tsv, etc) for: (1) Creating new spreadsheets with formulas and formatting, (2) Reading or analyzing data, (3) Modify existing spreadsheets while preserving formulas, (4) Data analysis and visualization in spreadsheets, or (5) Recalculating formulas
development
Comprehensive spreadsheet creation, editing, and analysis with support for formulas, formatting, data analysis, and visualization. When Claude needs to work with spreadsheets (.xlsx, .xlsm, .csv, .tsv, etc) for: (1) Creating new spreadsheets with formulas and formatting, (2) Reading or analyzing data, (3) Modify existing spreadsheets while preserving formulas, (4) Data analysis and visualization in spreadsheets, or (5) Recalculating formulas
development
Guides writing HMR/Dev Server tests in test/bake/. Use when creating or modifying dev server, hot reloading, or bundling tests.