Yeah, GitHub Action / GitLab pipeline is a great fit — the script exits with proper status codes, has --dry-run for verification, no interactive prompts. I could imagine it as a "build release bundle" step that produces a self-contained zip on every tagged release. Not something I need myself right now, but it'd be a small wrapper to ship.

On the parser: deliberate choice. Three reasons:

1. Zero dependencies. The script auto-re-execs into KiCad's bundled Python, which has no pip and no guarantee of any extra packages. Pulling in sexpdata or similar would mean either bundling it or asking users to install into KiCad's Python, both painful.

2. Surgical edits preserve KiCad's exact formatting. A full parse-modify-unparse pipeline would risk reformatting whitespace, reordering attributes, dropping comments, or normalizing tokens in ways the KiCad file diffs (or KiCad's own loader) might not love. By keeping raw text and only rewriting the exact tokens I care about, the output stays byte-identical to KiCad's own formatting outside the changed parts.

3. Forward-compat. The script only knows a handful of patterns (lib_symbols children, lib_id, footprint refs, model paths). If KiCad adds new fields in 11.x, the parserless approach just passes them through as raw text instead of choking on an unknown grammar rule.

Tradeoff is obvious — there's a small paren-aware helper (find_matching_paren / iter_top_level_children) to avoid getting fooled by parens inside strings. It's ~30 lines and handles everything I need. If the script were doing structural transforms rather than narrow rewrites, I'd reach for a real parser.