メニュー
Validate follow-up Companion module releases that add Yarn 4 metadata, ensuring the committed lockfile is actually immutable and the advertised lint/build scripts run in a clean checkout.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Verify a Companion module matches the official JS/TS template — required files, config-file parity, package.json/manifest.json fields, LICENSE, HELP.md, husky. Run scripts/validate-template.ps1 for the deterministic checks, then use this skill to interpret findings and judge the non-deterministic items. Use at the start of every module review.
Compliance checks for Companion modules on @companion-module/base v2.x (Companion 4.3+) — class-based export, removed runEntrypoint/parseVariablesInString, setVariableDefinitions object form, checkAllFeedbacks, manifest type connection. Use only when package.json resolves @companion-module/base to ^2.x. For 1.x modules use companion-v1-api-compliance instead.
Review a Bitfocus Companion module for release approval and produce a ranked review report. Use when the user says "review the next module", "review a/the (next) companion module", "review companion-module-X", "start a module review", or names a module. Supports a review scope — "just the tag/the changes" (tag), "the whole module / a full review" (module), or "both" — defaulting to tag. Runs the deterministic scripts, dispatches parallel review subagents, and assembles one review markdown — REPORT ONLY (never modifies the module).
Compliance checks for Companion modules on @companion-module/base v1.x (v1.5–v1.14, Companion 3.1–4.2). Use only when package.json resolves @companion-module/base to ^1.x or ~1.x. For 2.x modules use companion-v2-api-compliance instead.
Defines the standard scorecard and table of contents format for Companion module reviews. Use when assembling the final review file to generate the 📊 Scorecard section (issue counts by severity with New vs. Existing columns) and 📋 Table of Contents section (clickable anchor links to each finding).
Teaches the multi-file action pattern used in split-file Companion modules. Use when asked to add a new action category, create an action file, register actions in an aggregator, or extend the actions layer of a Companion module that splits actions across multiple files with a GetActions aggregator.
| name | review-yarn4-lockfile-validation |
| description | Validate follow-up Companion module releases that add Yarn 4 metadata, ensuring the committed lockfile is actually immutable and the advertised lint/build scripts run in a clean checkout. |
packageManager: "yarn@4.x"yarn.locklint / build scripts@companion-module/toolsSeeing yarn.lock in the tree is not enough. A follow-up patch can add the file but still fail reproducible installs if the lockfile was generated with the wrong Yarn version or would be rewritten immediately on first install.
Extract or check out the submitted tag in an isolated scratch copy.
Run:
COREPACK_ENABLE_DOWNLOAD_PROMPT=0 corepack yarn install --immutable
If Yarn fails with YN0028: The lockfile would have been modified, treat the prior lockfile/reproducibility finding as still open.
If install succeeds, run the declared validation scripts from the tag:
corepack yarn build
corepack yarn lint
If yarn lint fails with command not found: eslint, surface a new delta issue: the follow-up added lint wiring without the actual lint runtime dependency.
yarn.lock finding fixed just because the file now exists.main fix does not rescue the published release; the tagged artifact is still broken until that corrected lockfile is retagged and resubmitted.