メニュー
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.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
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.
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-release-train-issue-evaluation |
| description | 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 this with $evaluate-issue. That skill answers "is this worth doing?"; this skill answers "does it belong on the active release train or on main?"
release/* receives only stabilizing fixes. Features, cleanup, docs, process work, non-blocking hardening, and ordinary follow-ups target main.
git fetch --prune origin main, then .agents/bin/agent-workflow-seam-doctor. Fetch the release branch if ancestry matters.agent-coord doctor --json, then targeted agent-coord status --repo shakacode/react_on_rails --target <issue> --json. Dead or expired claims count as started-but-stalled, not non-started.Release gate: tracker, release + TRACKING labels, the Agent Release Mode block, agent-coord phase when available, source PR base branches, and whether source commits are already on origin/release/X.Y.Z.$evaluate-issue: evidence source, impact, complexity, process gap disposition, and priority.release/X.Y.Z: verified RC/final stabilizer such as an RC regression, hard-gate failure, install/upgrade blocker, security/data-loss/wrong-output bug, release-branch CI/release tooling blocker, or final-only public API/breaking-change decision.release/X.Y.Z contingent: only needed if maintainers decide to cherry-pick a related main-only fix into the train. Name the dependency.main: docs, changelog for main-only PRs, CI/tooling hygiene, tests, process automation, non-blocking runtime hardening, features, and performance/cleanup without release-gate proof.park/close: P3, speculative, duplicate, no-PR evidence, or not worth doing.Recommend labels/milestones/comments, but do not mutate GitHub unless the user explicitly authorizes writes.
Use a compact table:
| Issue | Started? | Evidence | Disposition | Target | Rationale | Next action |
|---|
Call out UNKNOWN facts explicitly, especially release tracker mode, source PR base, branch ancestry, and whether the issue is a confirmed RC regression.
release/17.0.0 when the related fix is not on the release branch. Mark these contingent instead.Mode: development as "no release train." The branch can still exist; target selection still matters.