القائمة
React on Rails release-train changelog updates, including target=release and release/X.Y.Z PR targeting while the portable update-changelog skill remains mainline-only.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use when evaluating React on Rails GitHub issues for release-train targeting, especially deciding whether new, follow-up, or non-started issues belong on release/17.0.0, another release/X.Y.Z branch, or main.
Use when planning, implementing, validating, or reviewing React Server Components (RSC) page performance optimization in React on Rails or React on Rails Pro work. Guides agents through clean baseline/control setup, one-change experiments, visual parity checks, performance measurement, package-stack discipline, artifact recording, and PR evidence for RSC static pages.
How to drive shaka-perf twin-servers (the control + experiment Docker pair) from an agent — which subcommand to use for build, start containers, start the app, stop, run a command inside a side, or sync code changes. Bare `shaka-perf servers` is for humans (interactive menu); agents must call subcommands directly. Use whenever you need to bring twin-servers up, restart them after a change, or run something inside a container. Triggers include "servers", "twin servers", "ab servers", "control/experiment server", "run X in container", "ab tests failing".
Audit existing .abtest.ts files plus the latest `shaka-perf audit` results for anti-patterns, false-positive PASSes (blank/high-whitespace screenshots), and coverage gaps. Use whenever the user wants to review, audit, improve, or "assess quality" of AB tests — phrasings like "are my visreg tests any good?", "check the ab tests", "why is this test passing?", or "make these tests more reliable".
Crawl a website and auto-generate .abtest.ts files for shaka-perf visreg visual regression testing. Use this skill whenever the user wants to discover, generate, or scaffold AB tests for a URL — even if they just say "set up tests for localhost:3020", "generate tests for this site", or "create visreg tests".
Set up shaka-perf twin-servers — the Docker A/B testing infrastructure that runs your app twice (control vs experiment) so visreg/perf can compare two branches. Use this skill whenever the user wants to set up, configure, or debug twin-servers, "dockerize" their app for shaka-perf, write the twin-servers Dockerfile/Procfile/docker-compose, fill in the `twinServers` config, or get `shaka-perf servers` building and running — even if they just say "set up twin servers", "get the A/B servers running", or "make my app run under shaka-perf for perf testing".
| name | react-on-rails-update-changelog |
| description | React on Rails release-train changelog updates, including target=release and release/X.Y.Z PR targeting while the portable update-changelog skill remains mainline-only. |
| argument-hint | [classification-sweep BASE_REF..TARGET_REF|release|rc|beta|version] [target=main|release|release/X.Y.Z] |
Use this repo-local skill only when React on Rails release-train targeting matters:
target=release or target=release/X.Y.Zrelease/X.Y.Zrelease/X.Y.ZFor ordinary mainline changelog entries on main, use the installed/shared
$update-changelog skill. This repo-local skill exists under a distinct name so
Codex does not show a duplicate update-changelog picker entry.
Before editing, read:
AGENTS.md changelog and release-train sections.internal/contributor-info/release-train-runbook.md when the target is a
release/* branch..agents/agent-workflow.yml for base_branch, changelog, and changelog
policy values.Resolve the shared helper directory explicitly; do not assume this checkout has a repo-local shared skill copy:
UPDATE_CHANGELOG_SKILL_DIR="${UPDATE_CHANGELOG_SKILL_DIR:-$(.agents/bin/shared-skill-dir update-changelog)}"
Use that helper for mechanical classification sweeps:
BASE_REF="${BASE_REF:?set BASE_REF, e.g. v17.0.0.rc.2}"
TARGET_REF="${TARGET_REF:?set TARGET_REF, e.g. origin/main or origin/release/17.0.0}"
"${UPDATE_CHANGELOG_SKILL_DIR}/bin/changelog-merged-prs" "${BASE_REF}..${TARGET_REF}"
Resolve the target before writing, stamping, branching, or creating a PR:
target=main: use the installed/shared $update-changelog flow against the
configured base branch.target=release/X.Y.Z: verify origin/release/X.Y.Z exists and target that
branch.target=release: use the current release/X.Y.Z branch when already on one;
otherwise list origin/release/*. If exactly one active release branch exists,
target it. If more than one exists, ask which branch to use.target= while on release/X.Y.Z: target the current release branch.target= while on main and exactly one active origin/release/* branch
exists: ask whether this changelog update should target release/X.Y.Z or
main. Default to main only when the user does not choose a release target.main.If a requested release target does not exist on origin, stop and report:
target=release requested but no matching origin/release/X.Y.Z branch exists.
Start the release line first, or use target=main.
For a resolved release/X.Y.Z target:
Fetch current release state:
git fetch --prune origin main '+refs/heads/release/*:refs/remotes/origin/release/*'
Require a clean worktree before changing branches or writing changelog entries.
Create a feature branch from the release branch tip, not from main:
git switch -c "changelog-<version-or-mode>" "origin/release/X.Y.Z"
Add or curate entries in CHANGELOG.md under ### [Unreleased], using the
classification taxonomy and entry format from AGENTS.md.
Run the repo's version-stamping task when requested:
bundle exec rake "update_changelog[rc]"
bundle exec rake "update_changelog[release]"
bundle exec rake "update_changelog[beta]"
bundle exec rake "update_changelog[17.0.0.rc.1]"
Keep compare-link anchoring consistent with the repo task. Release-target
entries intentionally keep the [unreleased] comparison anchored to main
because release-branch entries are forward-ported to main.
Commit only the changelog files, push the feature branch, and open the PR against the release branch:
git add CHANGELOG.md
git commit -m "Update changelog for <version-or-mode>"
git push -u origin "$(git branch --show-current)"
gh pr create --draft --base "release/X.Y.Z" --head "$(git branch --show-current)"
After the PR merges into release/X.Y.Z, follow the release-train runbook to
forward-port the changelog result to main when required.
Do not recreate .agents/skills/update-changelog/SKILL.md in this repo unless a
maintainer explicitly chooses to restore a same-name local override and accepts
the duplicate skill picker entry. Keep same-name shared workflow skills in the
installed shared pack.