القائمة
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.