shakacode

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.

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".

Orchestrate a destructive demo-workspace QA stress test for React on Rails leakage, memory, performance, security, and framework edge cases. Use only when the user explicitly asks to run stress testing.

Legacy helper for emergency maintenance of the vendored react-server-dom-webpack runtime through scripts/react-upgrade/upgrade.js and the React fork cherry-pick workflow.

Refresh internal/docs/open-rsc-work-status.md from live react_on_rails_rsc GitHub issue and PR state, using UNKNOWN for facts that cannot be verified.

Update react-on-rails-rsc CHANGELOG.md and optional package version headers for npm release or prerelease workflows.

Manually verify a react-on-rails-rsc bug-fix PR by reproducing the failure before the fix and confirming the same RSC/plugin signal passes after.

Run downstream integration checks through scripts/e2e/downstream.sh when it exists, or report the current #59 blocker stub.

Run repo end-to-end checks through scripts/e2e/run.sh for webpack, rspack, or both bundlers.

Verify release packaging for react-on-rails-rsc with yarn verify:artifacts / scripts/verify-release.sh.

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".

Review/design guide for framework extension points in shaka-perf. When a primitive has variants (pipeline, stage, …), the variant must own its behaviour via mandatory factory options and the framework must call into it polymorphically. The only allowed name-keyed `switch` is the single deserialisation site that maps a persisted name back to a primitive instance. Use when adding a new pipeline/stage variant, adding an extension point, reviewing a PR that introduces variant-specific behaviour, or auditing a `switch (name)` that picks between behaviours.

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".

Generate, audit, or update project documentation to a professional open-source standard. Use this skill whenever the user mentions docs, documentation, README, API reference, guides, migration guides, troubleshooting, llms.txt, doc audit, or wants to improve any written developer-facing content in a repository. Also trigger when the user says things like "document this", "write docs for", "update the docs", "our docs need work", or compares documentation quality to other projects. Covers Ruby (YARD), TypeScript (TSDoc/JSDoc), Markdown guides, configuration references, and doc site structure.