.github/workflows/upstream-release-docs.yml is 1667 lines across 41 steps, including 960 lines of inline bash. The size is concentrated in four steps:
| Step |
Inline bash lines |
| Augment PR body (marker-delimited section) |
313 |
| Assign reviewers and prepare contributor mentions |
121 |
| Resolve release owner and contributors |
99 |
| Capture skill signal files |
74 |
| remaining 37 steps |
353 (avg 9) |
Two reasons to extract the big ones:
- Nothing lints the inline bash. There is no shellcheck or actionlint in CI, so checking a change today means hand-extracting
steps[].run from the YAML, stubbing ${{ }}, and piping it to shellcheck.
scripts/upstream-release/ already holds five .mjs files and this workflow already invokes one, so a script there inherits Prettier and ESLint from existing CI with no new tooling.
Augment PR body is the best first candidate: its only I/O is roughly 25 env vars in and one gh pr edit --body-file out, and the PR body is the artifact reviewers actually read.
Scope
In:
Augment PR body to scripts/upstream-release/render-pr-body.mjs
Assign reviewers and Resolve release owner and contributors as separate follow-ups if the first goes cleanly
Out:
- The two Claude step prompts (88 lines). Their content is almost entirely interpolated run context, and the durable instructions already live in the
upstream-release-docs skill.
Capture skill signal files, mostly file reads and GITHUB_OUTPUT heredocs.
- The 37 short steps, which belong inline.
Sequencing
After #1111 has run live on two or three release PRs. That change is unvalidated, and stacking a refactor on it means a live failure has two candidate causes instead of one.
#1111 and this refactor touch the same steps, so if #1111 needs iteration, extract Augment PR body first (#1111 only added two table rows and two sections to it) and leave the reviewer steps until after validation.
Verification
Behavior-preserving: render the extracted script against the env of a real past run and diff the output against that run's actual PR body.
.github/workflows/upstream-release-docs.ymlis 1667 lines across 41 steps, including 960 lines of inline bash. The size is concentrated in four steps:Two reasons to extract the big ones:
steps[].runfrom the YAML, stubbing${{ }}, and piping it to shellcheck.scripts/upstream-release/already holds five.mjsfiles and this workflow already invokes one, so a script there inherits Prettier and ESLint from existing CI with no new tooling.Augment PR bodyis the best first candidate: its only I/O is roughly 25 env vars in and onegh pr edit --body-fileout, and the PR body is the artifact reviewers actually read.Scope
In:
Augment PR bodytoscripts/upstream-release/render-pr-body.mjsAssign reviewersandResolve release owner and contributorsas separate follow-ups if the first goes cleanlyOut:
upstream-release-docsskill.Capture skill signal files, mostly file reads andGITHUB_OUTPUTheredocs.Sequencing
After #1111 has run live on two or three release PRs. That change is unvalidated, and stacking a refactor on it means a live failure has two candidate causes instead of one.
#1111 and this refactor touch the same steps, so if #1111 needs iteration, extract
Augment PR bodyfirst (#1111 only added two table rows and two sections to it) and leave the reviewer steps until after validation.Verification
Behavior-preserving: render the extracted script against the env of a real past run and diff the output against that run's actual PR body.