菜单
Select the smallest correct validation commands for this repo based on touched paths, while distinguishing lint, build/type, and runtime confidence.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Safely modify `packages/extension-chat/*` without regressing the original extension in `packages/extension/*`. Use when working on chat side panel UX, background worker behavior, manifest wiring, or chat-only scripts/views.
Safely modify the classic/core extension in `packages/extension/*` without regressing chat extension behavior in `packages/extension-chat/*`. Use when working on core side panel, overlay, worker logic, manifest wiring, or extension scripts/views.
Debug and validate LWC OSS issues in this repo with a minimal, path-based command strategy (lint vs build vs e2e) and clear baseline-vs-regression classification.
Safely implement or refactor LWC OSS code in this repo (LWR + Rollup targets) while preserving cross-target behavior across core extension, chat extension, and shared runtime modules.
Safely modify shared runtime layers (`packages/lwc/main/*`, `packages/lwc/extension/*`, `packages/lwc/shared/*`) without regressing either core extension (`packages/extension/*`) or chat extension (`packages/extension-chat/*`).
Scaffold a new manifest-driven Workbench application under `packages/lwc/applications/<id>/`. Use when the user asks to create, add, or scaffold a new app, tool, utility, or extension in the Workbench monorepo — e.g. "add a new application", "create a workbench app called X", "scaffold a utility under applications", "new SOQL-style tool". Walks the user through the manifest schema, `host-api/*` bootstrap pattern, tsconfig/rollup wiring, and `generate_application_manifest.js` validation so the first build passes.
| name | repo-validation-selector |
| description | Select the smallest correct validation commands for this repo based on touched paths, while distinguishing lint, build/type, and runtime confidence. |
Use this skill after code changes to choose minimal, sufficient verification.
Prevent both:
Lint, build/type, and runtime/e2e are different signals. Report them separately.
When changes are only under packages/extension-chat/*:
npx eslint <changed chat .js/.ts files>
npx prettier --check <changed chat .html/.css/.js/.ts files>
npm run build:extension:chat:main
Optional (if requested): extension Playwright subset.
When changes are only under packages/extension/*:
npx eslint <changed core .js/.ts files>
npx prettier --check <changed core .html/.css/.js/.ts files>
npm run build:extension:main
When touching packages/lwc/main/*, packages/lwc/extension/*, or packages/lwc/shared/*:
npx eslint <changed .js/.ts files>
npx prettier --check <changed .html/.css/.js/.ts files>
npm run build:extension:main
npm run build:extension:chat:main
Also run npm run build:shared if:
When touching:
packages/lwc/applications/*tools/scripts/generate_application_manifest.jsRun:
npm run build:shared
npm run build:extension:main
Include chat build too when shared lwc files changed.
Only run Playwright when requested or when runtime confidence is needed.
Baseline commands:
npm run test:e2e:ext
If known baseline failures exist, classify as baseline vs new regression and, when useful, run targeted specs.
Always report verification in this structure:
npm run validate unless explicitly requested.